Рис. 1. Управляющая и управляемая системы.
Источник: http://www.niits.ru/public/2006/2006-035.pdf
Системные исследования принципов создания NGN, фрагменты которых изложены в первой части этой cтатьи, свидетельствуют о сложности построения сети. К этому следует добавить не менее актуальный вопрос: "Из чего строить сеть следующего поколения?". Множество красивых аббревиатур, новых технологий и оригинальных подходов на самом деле часто лишь скрывают непонимание. Для того чтобы создать действительно Сеть следующего поколения (или, как остроумно переводят термин "Next Generation Network" некоторые авторы, "Сеть ДЛЯ следующего поколения"), надо следовать не "букве" пока не созданных правил, а "духу" концепции.
Прежде чем перейти непосредственно к рассмотрению основных элементов, ассоциируемых с NGN, необходимо вспомнить об организациях, создающих идеологию этих сетей. Из первой части статьи читатель уже знает о семинарах, проводимых Международным союзом электросвязи (МСЭ) по NGN. Кроме того, в июне 2004 г. начала работу фокус-группа по NGN (Focus Group on NGN, FGNGN), в составе которой были организованы семь рабочих групп. Чуть позже к работам FGNGN присоединилась 13-я Исследовательская комиссия МСЭ (Study Group 13, SG13), взяв на себя руководство и координацию проводимых исследований. Параллельно шли работы в ETSI (Европейский институт телекоммуникационных стандартов) - проект TISPAN, создавались документы в консорциуме 3GPP, Форуме ATM, IPCC и в ряде других объединений.
В какой-то степени именно из-за параллельности работ развитие сетей NGN шло медленнее и сложнее, чем ожидалось. Часто появление новой идеи захватывало умы, и развитие "старых" идей останавливалось. Яркий пример - появление IMS (IP Multimedia Subsystem). Практически сразу большая часть производителей назвала свои NGN-решения IMS, консорциум IPCC был переименован в IMS Forum.
nbsp; Нечто подобное наблюдалось в начале текущего десятилетия, когда появилось понятие "Softswitch", а теперь происходит и с IMS. И этот пример не единственный. Что же это: дань моде или эволюция? Нам кажется, что правильный ответ на данный вопрос во многом определит и развитие NGN.
Этот раздел статьи в целом призван раскрыть технологические аспекты сценариев, изложенных в первой части статьи. Наивно полагать, что эти аспекты окажутся столь же конкретными: если сценарии первой части статьи более или менее четко описывают действия Оператора, то используемое оборудование может быть различным. Однако некоторые положения должны быть реализованы в обязательном порядке.
Каким бы ни был путь создания NGN, присутствие элемента, отвечающего за управление процессом установления соединения, неизбежно. Речь идет о классической связи между двумя системами: управляющей и управляемой (рис. 1).
Долгое время единственным кандидатом на роль управляющей системы был сигнальный коммутатор Softswitch. Сейчас у него появились конкуренты, основным из которых выступает уже упоминавшаяся технология IMS. Правда, являются ли они конкурентами на самом деле - вопрос спорный; ему посвящена отдельная статья [1]. А для объединения различных IP-сетей и доменов, которое обсуждается в первой части статьи, необходим граничный контроллер сессий - SBC (Session Border Controller).
Напомним, что термин "Softswitch" используется не только для идентификации одного из элементов сети. С ним связаны и сетевая архитектура, и даже в определенной степени сама идеология построения сети. Для нас же важны выполняемые коммутатором Softswitch функции и его способность решить ряд задач, присущих узлам с коммутацией каналов.
В первую очередь коммутатор Softswitch управляет обслуживанием вызовов, то есть установлением и разрушением соединений. Точно так, как это имеет место в традиционных АТС с коммутацией каналов, если соединение установлено, то эти функции гарантируют, что оно сохранится (с установленной вероятностью) до тех пор, пока не даст отбой вызвавший или вызванный абонент. В этом смысле коммутатор Softswitch можно рассматривать как управляющую систему.
Другой термин, часто ассоциируемый с Softswitch, - контроллер транспортного шлюза MGC. Это название подчеркивает факт управления транспортными шлюзами и шлюзами доступа по протоколу H.248 или другому. Softswitch координирует обмен сигнальными сообщениями между сетями, то есть поддерживает функциональность шлюза сигнализации - Signalling Gateway (SG). Он координирует действия, обеспечивающие соединение с логическими объектами в разных сетях, и преобразует информацию в сообщениях. Подобное преобразование необходимо, чтобы сигнальные сообщения были одинаково интерпретированы на обеих сторонах несходных сетей, обеспечивая с первого этапа модернизации работу с автоматическими телефонными станциями (АТС).
На рис. 2 показано место Softswitch в ЕСЭ РФ и его взаимодействие с различными существующими и перспективными элементами сетей общего пользования по соответствующим протоколам. Описание функциональной структуры Softswitch можно найти, например, в [2].
Эталонная же архитектура сетей на базе Softswitch, созданная уже упомянутым IPCC (ныне ISM Forum), состоит из четырех условных функциональных уровней (рис. 3).
1. Внизу архитектуры находится транспортный уровень (Transport Layer), отвечающий за перенос по VoIP-сети сигнальных сообщений и мультимедийной информации.
2. Уровень управления вызовами и сигнализации (Call Control & Signaling) управляет основными элементами VoIP-сети, особенно находящимися на транспортном уровне. На этом уровне находятся такие устройства, как контроллеры медиа-шлюзов (MGC, Call Agent, Call Controller), привратники (Gatekeeper) и LDAP-серверы.
3. Уровень услуг и приложений (Service & Application) обеспечивает управление, логику и выполнение некоторого числа услуг или приложений.
4. Уровень управления (Management) выполняет функции пользовательского обеспечения, поддержки операций и предоставления услуг, а также решает задачи биллинга и прочие задачи сетевого управления. Уровень управления может взаимодействовать с любым из трех перечисленных уровней, используя стандартные или внутрифирменные протоколы и программные интерфейсы API.
Как видно, деление довольно свободное и оставляющее пространство для маневра. Это, вероятно, вызвано желанием охватить многочисленные вариации оборудования Softswitch различных производителей. В центре каждого из таких решений находится сам Softswitch, который теоретически относится к уровню управления вызовами и сигнализации, но в практических решениях в той или иной степени захватывает функции остальных уровней архитектуры.
Таким образом, при фактическом соблюдении принципа функциональной декомпозиции шлюза можно наблюдать различные варианты его реализации. Первые Softswitch-решения представляли собой единый блок, то есть физической декомпозиции шлюза не было, но существовало разделение функций программных или аппаратных модулей. Иными словами, оборудование имело интегрированную архитектуру. В другом варианте физически отделялся лишь медиа-шлюз, а контроллер медиа-шлюзов и шлюз сигнализации составляли единый комплекс. Такое решение можно считать частичной физической декомпозицией.
Вместе с тем при всех достоинствах Softswitch оставалось несколько проблем, без решения которых дальнейшее развитие этой технологии существенно осложнялось. Основными из них стала реализация функции системы оперативно-розыскных мероприятий (СОРМ), отслеживание показателей QoS (особенно в случае заключения соглашений об уровне обслуживания SLA - Service Level Agreement) и преодоление межсетевых экранов. Появление контроллеров SBC стало решением этих проблем.
Традиционно провайдеры IP-телефонии взаимодействовали между собой, используя голосовые шлюзы (Media Gateway), подключенные к телефонным коммутаторам. Такая схема работы позволяет обеспечить безопасность соединения и предоставить всю необходимую биллинговую информацию. Правда, за счет дополнительного преобразования в кодеках снижается качество голоса и повышается стоимость пропуска трафика. К тому же такая схема не дает возможности пропускать трафик других мультимедиа приложений (таких, как Instant Messaging и видеопотоки). Но пока трафика IP-телефонии в мире было немного и он в основном носил характер соединений типа "точка - точка", это не вызывало больших проблем.
Для решения проблемы межоператорского взаимодействия и был создан SBC, после чего вместо схемы "IP-TDM-IP" стало использоваться прямое соединение "IP-IP". Кроме того, SBC берет на себя обеспечение взаимодействия сетей:
-межпротокольное (двусторонняя трансляция сигнальных протоколов SIP И H.323);
-внутрипротокольное (преобразование разных версий стеков протоколов);
-межоператорское;
-межвендорное (включая передачу факсов по протоколу T.38);
-контроль за установлением телефонных соединений (Call Admission Control, CAC);
-регулирование качества голоса путем ограничения числа одновременно активных вызовов;
-безопасность (включая функции RTP proxy для сокрытия внутренней структуры сети);
-возможность работы через устройство преобразования сетевых адресов NAT (Network Address Translation) и межсетевые экраны (обеспечение прохождения трафика);
Это означает, что контроллер SBC устанавливается на границе сети и выполняет те функции, которые нецелесообразно возлагать на Softswitch. В этом идея применения контроллеров SBC напоминает введение периферийных устройств управления для улучшения работы первого поколения АТС с программным управлением, в которых функции управления были реализованы в двухмашинном комплексе специализированных ЭВМ. Также надо понимать, что SBC работает с такими сетевыми устройствами, как Softswitch, межсетевой экран (Firewall), устройство преобразования сетевых адресов NAT, но не замещает их.
Функциональность SBC значительно шире, чем это необходимо "помощнику" Softswitch. Следует отметить, что разделение функциональности между системами Softswitch и SBC очень размыто. Softswitch может брать на себя большинство функций SBC, оставляя последнему лишь функцию нормализации трафика, то есть согласования кодеков, сигналов DTMF (многочастотный набор) и пр. Задачи Softswitch фокусируются на управлении медиа-шлюзами и маршрутизации вызовов между ТФОП и IP-сетью или внутри IP-сети. SBC изначально ориентирован на гораздо большее количество услуг реального времени (видео, мультимедиа, Instant Messaging), реализуемых в IP-сети. Трафику, пропускаемому через SBC, обеспечивается управление качеством обслуживания, безопасностью, полосой пропускания, но SBC не выполняет функции маршрутизации. Поэтому для взаимодействия сетей необходимо одновременное использование обоих видов оборудования - Softswitch и SBC.
Концепция IMS была разработана в 2002 г. консорциумом 3rd Generation Partnership Project (3GPP) для сетей 3G/W-CDMA и стандартизована в спецификациях 3GPP R.5. Позднее созданной моделью воспользовались сразу несколько организаций: 3GPP2, занимающаяся разработками для сетей CDMA2000, ETSI, группа Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN), работающая в области конвергенции фиксированных сетей. Альянс Open Mobile Alliance (OMA) определил приложения и услуги, работающие поверх IMS, а Internet Engineering Task Force (IETF) -протоколы сетевого уровня. ETSI, отраслевые группы Форума мульти-сервисной коммутации (Multiservice Switching Forum, MSF) и Альянса для продвижения решений для телекоммуникационной отрасли (Alliance for Telecommunications Industry Solutions, ATIS) одобрили IMS в качестве основы сетевой инфраструктуры следующего поколения.
IMS обеспечивает архитектуру (рис. 4), в которой многие функции могут быть использованы с различными приложениями и у разных провайдеров. Это позволяет быстро и эффективно создавать новые услуги и непосредственно предоставлять их. В основе концепции этого стандарта лежит способность IMS передавать сигнальный трафик и трафик в канале через IP-уровень, а также выполнять функции маршрутизатора или механизма управления сессиями абонентов с использованием информации об их состоянии.
IMS включает в себя блок интерфейсов, SIP-прокси-серверов и обычных серверов, а также медиа-шлюзов (для подсоединения к сетям с протоколом, отличным от IP). Сервисная архитектура представляет собой набор логических функций, которые можно разделить на три уровня:
1. Уровень абонентских устройств и шлюзов;
2. Уровень управления сеансами;
3. Уровень приложений.
1. На уровне транспорта и абонентских устройств инициируется и терминируется сигнализация SIP, необходимая для установления сеансов и предоставления базовых услуг, таких, как преобразование речи из аналоговой или цифровой формы в IP-пакеты с использованием протокола RTP (Realtime Transport Protocol). На этом уровне функционируют медиа-шлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM.
2. На следующем уровне располагается функция управления вызовами и сеансами CSCF (Call Session Control Function), которая регистрирует абонентские устройства и направляет сигнальные сообщения протокола SIP к соответствующим серверам приложений. Функция CSCF связана с уровнем транспорта и доступа для обеспечения качества обслуживания по всем сервисам.
Уровень управления вызовами и сеансами включает в себя сервер абонентских данных HSS (Home Subscriber Server), где централизованно хранятся уникальные сервисные профили всех абонентов. На уровне управления вызовами и сеансами также располагается функция управления медиа-шлюзами MGCF (Media Gateway Control Function), которая обеспечивает взаимодействие сигнализации SIP с сигнализацией других медиа-шлюзов (например, H.248). Функция MGCF управляет распределением сеансов по множеству медиа-шлюзов; для медиасерверов это выполняется функцией MSFC (Media Server Function Control).
3. Уровень услуг состоит из серверов приложений и контент-серверов для предоставления абонентам дополнительных услуг. Базовые средства предоставления услуг, как это определено стандартом IMS (например, управление присутствием или управление списками групп), реализованы в качестве услуг на сервере SIP-при-ложения. Серверы приложений обеспечивают обслуживание конечных пользователей. Архитектура IMS и сигнализация SIP обеспечивают достаточную гибкость для поддержки разнообразных телефонных и других серверов приложений. Так, разработаны стандарты SIP для услуг телефонии и сервисов IMS.
Архитектура IMS поддерживает множество серверов приложений для телефонных сервисов. Сервер телефонных приложений TAS (Telephony Application Server) принимает и обрабатывает сообщения протокола SIP, а также определяет, каким образом должен быть инициирован исходящий вызов. Сервисная логика TAS обеспечивает базовые сервисы обработки вызовов, включая анализ цифр, маршрутизацию, установление, ожидание и перенаправление вызовов, конференц-связь и т.д.
Гибкость архитектуры IMS позволяет сервис-провайдерам добавлять услуги в сеть VoIP путем взаимодействия с действующими приложениями или же путем интеграции собственных или разработанных третьими фирмами серверов приложений на базе SIP. Кроме того, сервис-провайдеры могут предоставить своим клиентам возможность разрабатывать и внедрять сервисы, использующие ресурсы сети VoIP.
Если сравнить архитектуры Softswitch и IMS, то из приведенных рисунков видно, что и та и другая архитектуры имеют трехуровневое деление, причем границы уровней проходят на одних и тех же местах. Для архитектуры Softswitch изображены в первую очередь устройства сети, а архитектура IMS определена на уровне функций. Идентичны также идея предоставления всех услуг на базе IP-сети и разделение функций управления вызовом и коммутации. По сути, к уже известным функциям Softswitch добавляются функции шлюза OSA и сервер абонентских данных.
Посмотрев на приведенные выше списки функций в обеих архитектурах, можно заметить, что состав функций практически не отличается. Можно было бы заключить, что обе архитектуры почти тождественны. Это верно, но только отчасти: они идентичны в архитектурном смысле. Если же разобрать содержание каждой из функций, то обнаружатся значительные различия в системах Softswitch и IMS. Например, функция CSCF: из ее описания уже видно отличие от аналогичных функций в Softswitch. К тому же если в архитектуре Softswitch функции имеют довольно условное деление и описание, то в документах IMS дается довольно жесткое описание функций и процедур их взаимодействия, а также определены и стандартизированы интерфейсы между функциями системы.
Поскольку было сказано, что функции в рамках архитектуры Softswitch определены достаточно свободно, то почему бы не рассматривать IMS как Mobile Softswitch? Иными словами, расширить возможности коммутаторов Softswitch для сетей мобильной связи.
Различие начинается с основной концепции систем. Softswitch - это в первую очередь оборудование конвергентных сетей. Функция управления шлюзами (и соответственно протоколы MGCP/MEGACO) является в нем доминирующей (протокол SIP для взаимодействия двух Softswitch/ MGC). IMS проектировалась в рамках сети 3G, полностью базирующейся на IP. Основным ее протоколом является SIP, позволяющий устанавливать одноранговые сессии между абонентами и использовать IMS лишь как систему, предоставляющую сервисные функции по безопасности, авторизации, доступа к услугам и т.д. Функция управления шлюзами и сам медиа-шлюз здесь лишь средство для связи абонентов 3G с абонентами фиксированных сетей. Причем имеются в виду лишь ТФОП. Для общения абонентов 3G с абонентами фиксированных VoIP-сетей и абонентами других 3G-сетей архитектура IMS предусматривает использование функции Security Gateway Function, которую реализуют граничные контроллеры SBC.
Идеология эксплуатации и управления известна под термином OSS (Operation Support System) и уже довольно давно разрабатывается и внедряется в операторских сетях. Для определения и оптимизации процессов существует несколько моделей, концепций и инструментов (ITIL, eTOM, TMN), позволяющих четко сформировать единый (для каждой модели) вид на все бизнес-процессы оператора.
Оптимальным сегодня считается подход еТОМ, разработанный Tele-Management Forum и принятый затем ITU-T в качестве альтернативы заполнения функциональности в сети TMN, которая была изначально призвана решить все проблемы OSS для операторов связи. Производителей подобных систем сегодня не так уж и мало - TTI (Netrac), HP (Open View) и другие.
Сценарии создания NGN, темпы модернизации ЕСЭ РФ (постепенные или радикальные) и характеристики соответствующего оборудования должны быть тщательно проанализированы всеми игроками телекоммуникационного рынка. Для того чтобы новая сеть появилась на свет в том виде, который действительно будет нужен Операторам связи, необходимо объединение усилий всех заинтересованных сторон. Должна быть выработана такая концепция построения NGN, которая позволит осуществить переход плавно, сможет гармонично вписаться в существующую структуру ЕСЭ РФ и будет функционально наполнена именно в той степени, в какой она будет востребована абонентами на каждом этапе развития инфокоммуникационной системы.