ПОДСИСТЕМА МУЛЬТИМЕДИЙНОЙ СВЯЗИ IMS
Концепция IMS (IP Multimedia Subsystem)
Опыт реализации сетей NGN на базе программных коммутаторов SX показал, что построенные сети хорошо справляются с предоставлением услуг передачи речи и организации видеоконференций, а также достаточно легко соединяются и взаимодействуют с существующими сетями с КК (ТфОП, СПС – 2G).
Дальнейшее расширение номенклатуры услуг востребованных пользователями привело к появлению пакета услуг Triple Play (тройной пакет, включающий голосовые услуги, доступ в Интернет и просмотр телевизионных программ). Для реализации такого пакета услуг необходимо было объединить усилия трех разных компаний: телефонную компанию, провайдера доступа в Интернет и компанию, предоставляющую услуги IPTV (передачи ТВ через IP-сеть). Однако, даже наличие в телефонной компании развитого IP-транспорта и программного коммутатора SX не позволяло ис-
пользовать ресурсы NGN в качестве основы для предоставления услуг тройного пакета. SX не мог контролировать и тарифицировать доступ в Интернет, а также обеспечивать телевещание в режиме групповой рассылки (Multicast) и передачу видеофильмов по запросу (Unicast). Разница в организации доступа к информации, способах адресации, методах определения стоимости услуги и ее тарификации создавали непреодолимые трудности по координации действий компаний провайдеров, хотя обслуживали они одних и тем же пользователей, которые были вынуждены оплачивать разные счета, обращаться в разные службы поддержки и приобретать разное оконечное оборудование. Эта ситуация усугублялась
тем, что, как правило, абоненты использовали единую сеть широкополосного доступа для получения всех трех услуг.
|
|
Одновременно с накоплением опыта построения сетей NGN на базе SX в телефонных сетях происходило преобразование мобильных сетей на технологию NGN/SX, связанное как с изменением транспортной структуры сетей 2-го поколения (2G), построения сетей 3-го поколения (3G), так и началом построения сетей 4-го поколения (4G), ориентированным на использование пакетного радиоинтерфейса.
Идеологию создания и развития сетей третьего и четвертого поколений разрабатывал консорциум 3GPP (3-d Generation Partnership Project). Первая спецификация сетей 3-го поколения была сделана в 1999 году и получила название Release 99. В качестве нового стандарта радиоинтерфейса была выбрана технология – WCDMA (Wireless Code Division Multiple Access) и определен подход для создания услуг на основе архитектуры OSA (Open Service Architecture). Затем последовал Release 4, в котором был определен IP-транспорт и введены понятия MSC-сервера и транспортных шлюзов MGW. В Release 5 была впервые описана концепция IMS. В Release 6 были добавлены функции взаимодействия с сетями КК и различными сетями доступа.
Взаимодействие 3GPP и ETSI осуществляется в рамках проекта TISPAN, который появился в 2003 году и предназначен для адаптации технологии IMS к требованиям стационарных сетей связи, а также для разработки процесса конвергенции мобильных и стационарных сетей на базе IMS.
IMS (IP Multimedia Subsystem) – это спецификация стандартной архитектуры по управлению мультимедийными сеансами для сетей NGN. Система IMS специально разработана как распределенная структура управления сеансами на основе единого протокола сигнализации – SIP, общей базы абонентских данных – HSS (Home Subscriber Server) и ядра системы управления CSCF (Call/Session Control Function).
|
|
Система IMS обеспечивает управление сеансами связи для голосовых услуг с возможностью активации мультимедийных приложений (rich voice), видеотелефонии, передачи мультимедийных сообщений, для организации услуг IPTV, услуг определения местонахождения абонента и его мобильности. Также IMS должна обеспечивать требования по качеству обслуживания QoS для каждого из приложений, взаимодействовать с другими сетями (ТфОП, мобильными сетями второго 2G (КК), третьего 3G и четвертого 4G поколений (КП)), поддерживать инвариантность доступа (включая технологии WiFi, LTE, GPRS, xDSL, HFC, PON...), а также гибкую
систему тарификации мультимедийных сеансов.
Архитектура IMS
Архитектура IMS (рис. 8.1) содержит 3 уровня:
1) уровень доступа и транспорта;
2) уровень управления сессиями;
3) уровень услуг и приложений.
Рисунок 8.1 - Архитектура IMS
Уровень доступа и транспорта включает терминальное оборудование, сети доступа с различными технологиями (WiFi, LTE, GPRS, xDSL, HFC, PON), единую транспортную IP-сеть и транспортные шлюзы (MGW). Уровень управления сессиями включает ядро IMS, сервер пользовательских данных HSS (Home Subscriber Server) и сигнальные шлюзы. В IMS определяются не узлы сети, а функции, которые могут быть реализованы на одной или нескольких аппаратных платформах. Таким образом, в ядре представлена функция управления сеансами CSCF (Common Session Control Function), которая является SIP-сервером, осуществляющим функции: прокси, взаимодействия и обслуживания (Proxy, Interrogating, Service-CSCF).
Уровень приложений представлен серверами приложений AS (Application Server).
|
|
Сервер пользовательских данных HSS является централизованным хранилищем данных об абонентах и услугах, замещая собой сервер HLR (Home Location Register) из архитектуры GSM.
Сервер HSS выполняет следующие функции:
· управляет мобильностью;
· поддерживает аутентификацию и авторизацию;
· поддерживает предоставление услуг и приложений.
В подсистеме IMS может быть один или несколько серверов HSS. Если в сети несколько серверов HSS, то необходима функция SLF (Subscriber Location Function), представляющая собой базу данных о том, какой сервер HSS хранит данные конкретного пользователя.
Рисунок 8.2 - Ядро IMS
Ядро IMS включает 3 типа SIP серверов, выполняющих следующие общие функции по управлению сессиями (CSCF):
1. Proxy-CSCF – прокси-сервер.
2. Interrogating-CSCF – сервер взаимодействия.
3. Service-CSCF – сервер обслуживания.
С точки зрения SIP функция P-CSCF является входящим/исходящим прокси-сервером, через который проходят все запросы от терминала в IMS и обратно.
Терминал прикрепляется к P-CSCF во время регистрации и эта связь сохраняется до отмены регистрации. Основным назначением P-CSCF является маршрутизация запросов и ответов SIP между терминалом и S-CSCF. P-CSCF обеспечивает аутентификацию пользователей посредством создания защищенных IPsec ассоциаций, что освобождает от повторной аутентификации остальные функции ядра IMS. P-CSCF производит проверку правильности формирования SIP-сообщений, поступающих от терминала.
Подсистема IMS обычно содержит несколько P-CSCF, каждая из которых обслуживает свою группу пользователей.
Основное назначение функции взаимодействия I-CSCF заключается в обращении к HSS по протоколу Diameter с целью получения данных о месте нахождения пользователя и обслуживающей его S-CSCF. Если ни одна сервисная CSCF еще не назначена, то I-CSCF производит ее назначение. Обычно в подсистеме IMS организуются несколько серверов I-CSCF, как правило, расположенных в домашней сети.
Обслуживающий S-CSCF, выполняет функции регистрирующего SIP-сервера, т.е. поддерживает привязку местоположения пользователя (IP-адрес) к его SIP-адресу (PUI – Public User Identity). S-CSCF взаимодействует по протоколу Diameter с сервером HSS с целью получения данных о профиле пользователя, включающих список доступных ему услуг и набор триггерных точек для маршрутизации SIP-запросов к соответствующим серверам приложений. Вся сигнальная информация, передаваемая и принимаемая терминалом, проходит через S-CSCF, которая анализирует каждое сообщение и определяет его последующее назначение. S-CSCF поддерживает сеанс и взаимодействует с функциями начисления оплаты. Для обеспечения масштабируемости в сети могут находиться несколько S-CSCF, которые всегда располагаются в домашней сети.
Функция PDF (Policy Decision Function) отвечает за выработку политики об изменении параметров сеанса. PDF получает информацию о сеансе от P-CSCF. PDF принимает решение о повторной авторизации при изменении параметров сеанса или о запрете передачи данного трафика. PDF иногда интегрируется с P-CSCF, но может быть реализована отдельно.
Функция MRF (Media Resource Function) предназначена для
воспроизведения различных объявлений и состоит из:
- контроллера MRFC (Media Resource Function Controller);
- процессора MRFP (Media Resourse Function Processor).
Контроллер MRFC находится на сигнальном уровне и взаимодействует с S-CSCF по протоколу SIP. Контроллер MRFC управляет процессором MRFP по протоколу MEGACO/H.248. Процессор MRFP хранит информацию, формирует и посылает объявления. Кроме воспроизведения объявлений, MRF может смешивать медиа-потоки, перекодировать информацию разных кодеков, собирать статистические данные и анализировать медиаинформацию. MRF всегда находится в домашней сети.
Для взаимодействия с сетями с КК в IMS (рис. 8.3) выделены
следующие элементы:
- сервер маршрутизации вызовов по телефонному номеру BGCF (Breakout Gateway Control Function);
- сервер управления транспортными шлюзами MGCF (Media Gateway Control Function);
- транспортный шлюз MGW (Media Gateway);
- сигнальный шлюз SGW (Signalling Gateway).
Рисунок 8.3 - Функции взаимодействия IMS с сетями с КК (ТфОП, GSM)
BGCF (Breakout Gateway Control Function) – это сервер для маршрутизации вызовов на основе телефонного номера. Сервер BGCF используется только при установлении соединений к сети с КК (ТфОП, GSM). Сервер BGCF производит выбор транспортного шлюза, через который будет осуществляться взаимодействие с сетью с КК. Сервер BGCF выбирает шлюз, если взаимодействие происходит в пределах своей сети или другую IMS, когда взаимодействие с нужной сетью КК выполняется в той IMS.
Шлюз сигнализации SGW находится на границе между сетью с КК и IP-сетью. В задачи шлюза сигнализации входит поддержка окончания сигнальных звеньев ОКС №7 на уровне МТР и обеспечение передачи сигнальных сообщений протоколов ISUP, INAP, MAP к серверу MGCF. Для транспортировки этих сигнальных сообщений используется протокол SCTP, который обеспечивает надежную и корректную передачу как в сторону MGCF, так и в сторону сети с КК.
Функция контроллера шлюзов MGCF (Media Gateway Control Function) обычно реализуется в виде отдельного сервера. Сервер MGCF принимает сигнальные сообщения от SGW и взаимодействует с транспортными шлюзами MGW по протоколу MEGACO/H.248. MGCF взаимодействует с другими функциями IMS по протоколу SIP. Реализация MGCF в виде отдельного сервера практически соответствует функционированию программного коммутатора Softswitch в режиме контроллера шлюзов MGC, поэтому многие компании производители оборудования используют ранее разработанные программные коммутаторы в качестве элементов IMS.
На рисунке 8.4 представлены стеки протоколов в сетевых элементах, обеспечивающих обмен сигнальными сообщениями ОКС №7 при взаимодействии IMS с коммутационными станциями ТфОП (КК) или центрами сетей GSM (MSC – Mobile Switching Center).
Рисунок 8.4 - Стеки протоколов в элементах IMS, обеспечивающих сопряжение с сетью с КК
В коммутационной станции (CS) реализован обычный стек протоколов ОКС №7 с подсистемой пользователя ЦСИС (ISUP). В сигнальном шлюзе SGW реализована версия протокола SIGTRAN – M3UA. Сигнальные сообщения ISUP передаются в контроллер шлюзов MGCF через процедуру адаптации M3UA по стеку SCTP/IP. Контроллер MGCF взаимодействует с остальными функциями IMS с помощью протокола SIP.
Серверы приложений AS (Application Server) предоставляют услуги посредством взаимодействия с IMS. Сервер обслуживания S-CSCF пересылает запросы к соответствующему серверу приложений AS, который обеспечивает поддержку услуги.
Подсистема IMS обеспечивает взаимодействие с большим количеством различных серверов приложений. Это могут быть как стандартные SIP-сервера, так и сервера построенные на концепции OSA (Open Service Architecture). Кроме того, обеспечивается взаимодействие с серверами CAMEL, которые традиционно входят в структуру мобильных сетей 2G.
В IMS различают следующие типы серверов приложений:
1) серверы поддержки телефонных услуг TAS (Telephone Application Server);
2) серверы взаимодействия с серверами услуг в мобильных сетях IM-SSF (IP Multimedia Service Switching Function);
3) серверы доступа к услугам с открытой сервисной архитектурой OSA-GW (Open Service Access GW).
Серверы приложений работают как промежуточные устройства между обслуживающей S-CSCF с одной стороны и собственно серверами услуг, которые реализуют услуги и построены по различным технологиям. Это могут быть классические серверы приложений, серверы OSA (Open Service Architecture) или стандартные серверы сети GSM, использующие протокол CAMEL. Серверы приложений могут взаимодействовать с HSS для получения необходимых пользовательских данных.
Серверы поддержки телефонных услуг TAS эмулируют работу всех видов стандартных телефонных услуг (все виды переадресации вызовов, идентификацию номеров, завершение вызовов к занятому абоненту, конференция и др.).
Серверы взаимодействия с серверами услуг в мобильных сетях IM-SSF обеспечивают абонентам IMS возможность пользоваться стандартным набором услуг, предоставляемым абонентам сетей GSM при помощи протокола CAMEL (роуминг, хэнд-овер и др.).
Серверы доступа к услугам с открытой сервисной архитектурой OSA-GW обеспечивают взаимодействие абонентов IMS с серверами открытой сервисной архитектуры OSA, которые могут принадлежать другим компаниям.
Сценарий установления сессии
Перед началом установления сессии терминалы должны пройти процедуру регистрации. Процесс регистрации представлен на рис. 8.5.
Рисунок 8.5 - Процесс регистрации
1. Абонентский терминал посылает запрос на регистрацию в P-CSCF.
2. P-CSCF запрашивает в DNS IP-адрес взаимодействующей I-CSCF.
3. P-CSCF пересылает запрос регистрации в I-CSCF.
4. I-CSCF запрашивает в HSS адрес обслуживающей S-CSCF.
5. I-CSCF пересылает запрос регистрации к S-CSCF.
6. S-CSCF получает из HSS профиль пользователя и список прикладных серверов, доступных данному пользователю.
7. Прикладной сервер получает извещение о регистрации пользователя.
После завершения регистрации пользователь начинает установление сессии. Начало установления сессии на исходящей стороне представлено на рис. 8.6.
Рисунок 8.6 - Установление сессии на исходящей стороне
1. Терминал пользователя посылает запрос на установление соединения к P-CSCF.
2. P-CSCF пересылает запрос пользователя к S-CSCF.
3. S-CSCF пересылает запрос прикладному серверу AS.
4. S-CSCF запрашивает в DNS адрес взаимодействующей I-CSCF, обслуживающей вызываемого пользователя (функциональность ENUM).
После этого, запрос пересылается к I-CSCF (если вызываемый является терминалом VoIP) или к BGCF (если вызываемый является абонентом телефонной сети).
Допустим, что вызываемый абонент подключен к другой IMS.
Продолжение процесса установления сессии показано на рис. 8.7.
1. I-CSCF получает запрос на установление сессии от смежной IMS.
2. I-CSCF обращается к HSS для получения адреса обслуживающей S-CSCF и профиля вызываемого абонента.
3. I-CSCF пересылает запрос на установление сессии к S-CSCF.
4. S-CSCF обращается к прикладному серверу AS, указанному в профиле вызываемого абонента, и получает адрес P-CSCF, обслуживающей терминал вызываемого абонента.
5. S-CSCF пересылает запрос к P-CSCF.
6. P-CSCF пересылает запрос к вызываемому терминалу.
После этого, происходит установление RTP-сессии между вызываемым и вызывающим терминалами.
Рисунок 8.7 - Установление сессии на входящей стороне
Если вызываемым или вызывающим пользователем является абонент телефонной сети, то сценарий установления сессии существенно изменяется. Это связано с тем, что после анализа номера вызываемого абонента в BGCF, управление сессией передается к контроллеру шлюзов MGCF, который и обеспечивает взаимодействие сетей через транспортный шлюз (рис. 8.8).
1. Терминал пользователя посылает запрос на установление соединения к P-CSCF.
2. P-CSCF пересылает запрос пользователя к S-CSCF.
3. S-CSCF пересылает запрос прикладному серверу AS.
4. S-CSCF запрашивает в DNS адрес I-CSCF. Поскольку вызываемый абонент не является абонентом IMS, то его адреса нет в DNS сервере.
5. S-CSCF пересылает запрос к BGCF.
6. BGCF пересылает запрос на установление соединения к контроллеру шлюзов MGCF.
Рисунок 8.8 - Установление сессии между абонентом VoIP и абонентом
ТфОП
После этого, весь процесс установления соединения выполняется под управлением MGCF. MGCF посылает запрос на установления контекста в транспортном шлюзе MGW.
Затем MGCF посылает сигнальное сообщение IAM в телефонную сеть (ТфОП). После получения ответа вызываемого абонента MGCF устанавливает сессию между вызывающим абонентом VoIP и вызываемым телефонным абонентом.
В заключении рассмотрим более подробно полный процесс установления сессии между абонентами разных IMS (рис. 8.9). Сценарий установления сессии между абонентами разных IMS состоит из следующих этапов:
1. Вызывающий абонент посылает запрос к серверу P-CSCF-1 своей сети.
2. P-CSCF-1 пересылает запрос к серверу S-CSCF-1 своей сети.
3. S-CSCF-1 пересылает запрос прикладному серверу AS-1.
4. AS-1 анализирует запрос и сообщает S-CSCF-1, что вызываемый абонент не принадлежит к данной сети.
Рисунок 8.9 - Установление сессии между абонентами разных IMS
5. Если S-CSCF-1 не находит дополнительного фильтрующего критерия, то S-CSCF-1 обращается к серверу DNS/ENUM для определения взаимодействующей I-CSCF-2. Если I-CSCF-2 не является частью данной IMS, то S-CSCF-1 проверяет прописан ли адрес I-CSCF-2 в списке взаимодействующих доменов:
- если адрес I-CSCF-2 находится вне списка взаимодействующих доменов, то S-CSCF-1 пересылает сообщение INVITE к I-CSCF-2 через I-BCF для выполнения NAPT, скрытия внутренней топологии сети и защиты (firewall);
- если адрес I-CSCF-2 найден в списке взаимодействующих доменов, то S-CSCF-1 пересылает сообщение INVITE непосредственно в I-CSCF-2, находящийся в сети назначения.
6. I-CSCF-2 посылает запрос в HSS для поиска адреса S-CSCF-2, обслуживающей вызываемого абонента. HSS сообщает текущий адрес
S-CSCF-2, обслуживающий вызываемого абонента.
7. I-CSCF-2 пересылает сообщение INVITE к S-CSCF-2.
8. S-CSCF-2 проверяет сервисный профиль вызываемого абонента (например, транспортный профиль SDP) и оценивает начальный фильтрующий критерий. В нашем примере S-CSCF-1 указывает, что необходимо обращение к прикладному серверу AS-2.
9. Остальные шаги сценария соответствуют процессу установления входящей сессии.
Рассмотренные сценарии относятся к базовым процессам установления мультимедийных сеансов (передачи голоса, видеоконференции), тогда как предоставление услуг IP TV имеет свои особенности, связанные с организацией широковещательного режима (multicasting).
Реализация IMS
В настоящее время существует большое число платформ IMS,
поставляемых как известными вендорами (Alcatel-Lucent, Nokia, Ericsson,
Huawei…), так и небольшими компаниями. Учитывая, что концепция IMS написана на уровне взаимодействующих функций, то ее реализации отличаются большим разнообразием. В связи с этим, рассмотрим только один типичный пример реализации IMS: 5060 IP Call Server, компании Alcatel-Lucent. Это компактное решение, в котором некоторые функции реализуются на одной и той же аппаратной платформе. Функциональная схема 5060 ICS представлена на рис. 8.10.
Основные функции ядра системы выполняются на платформе 5450 ICS (IP Session Control):
1) прокси-функция Proxy-CSCF;
2) функция взаимодействия Interrogate-CSCF;
3) функция обслуживания Service-CSCF;
4) функция обработки вызовов к экстренным службам Emergency-CSCF
(E-CSCF);
5) функция маршрутизации телефонных вызовов Breakout Gateway Control Function (BGCF);
Рисунок 8.10 Функциональная схема 5060 ICS
6) функция пограничного контроля Interconnection Border Control Function (I-BCF);
7) внутренняя функция управления шлюзами доступа Internal Access Gateway Control Function (i-AGCF);
8) внутренний брандмауэр Internal Signalling Firewall (Internal-SigFW).
Первые три функции ядра IMS были подробно рассмотрены ранее.
Функция E-CSCF предназначена для обработки вызовов к экстренным службам, что требует обеспечения специальных сценариев обработки этих вызовов, ориентированных на правила, принятые в данной стране.
Функции BGCF достаточно полно представлены в приведенных сценариях установления сессии. Однако, рассмотренные сценарии предполагают, что взаимодействующие IMS находятся в сети одного оператора. Если это условие не выполняется, то необходимо принимать меры по защите платформы IMS от внешних атак.
Этой цели служит функция контроля пограничного взаимодействия I-BCF, задача которой сокрытие внутренней структуры IMS и обеспечение корректного взаимодействия с другими IP-сетями.
Для защиты системы сигнализации используется встроенный брандмауэр Internal SigFW.
Функция управления шлюзами доступа также реализована i-AGCF на платформе 5450 ICS.
Отдельный модуль 5450 IRC (IP Resource Control) выполняет функции PDF (Policy Decision Function), т.е. выработки конкретных политик управления сеансом, ориентированных на реализуемую службу Service-based Policy Decision Function.
Интегрированная функция распределения легального доступа к сеансам связи i-LIDF и шлюз для законного прослушивания LIG (Lawful Intercept Gateway) являются основой для СОРМ.
Для обеспечения взаимодействия с ТфОП используется оборудование программных коммутаторов MGC (MGC-8, MGC-10, MGC-12).
На физическом уровне взаимодействие отдельных аппаратных платформ обеспечивается Ethernet коммутатором 6850 Omni Switch.
Поддержка единой абонентской базы данных осуществляется через внутренний iHSS, который также обеспечивает функцию SLF.
Процесс тарификации выполняется двумя функциями:
1) функцией установления тарифа i-CRF (internal Charge Rate Funсtion);
2) функцией сбора тарификационных данных i-CCF (internal Charging Collection Function).
Функция i-CRF собирает тарификационные запросы ACR (Accounting
Request) по каждому SIP-сеансу, которые поступают от сервера приложений 5420 CTS. I-CRF обрабатывает поступающие запросы ACR и на их основе создает детализированные тарификационные записи CDR (Charging Detail Records) в формате ASN.1.
Сформированные тарификационные записи пересылаются в i-CCF.
Программа i-CCF обрабатывает тарификационные записи CDR и отправляет их в биллинг-сервер.