CC BY
138
Интеграция приложений в сетях связи с подсистемой IMS
В настоящее время архитектура мультимедийной подсистемы IMS является одной Из самых распределенных информационных систем, в том числе на различных уровнях взаимодействия, обеспечивая вместе с тем интеграцию самых различных приложений. В основе IMS лежит взаимодействие различных компонентов посредством протоколов различных уровней и четкое распределение функционала между компонентами. Одной из основных функций IMS является предоставление открытой среды для быстрого создания услуг и внедрения их в эксплуатацию независимо от применяемых на сети технологий доступа и уже существующих сервисов. Одним из элементов подсистемы IMS является сервис-брокер. Функциональность сервис-брокера направлена на управление сервисными возможностями и организацией взаимодействия между любым типом серверов IMS приложений. Тем не менее, не все проблемы взаимодействия и предоставления услуг еще решены и функционал сервис-брокера в настоящее время изучается международными организациями 3GPP и Service Broker Forum. В этой статье рассматривается эволюция функциональности сервис-брокера, предложенной в стандартах, аспекты архитектурных решений и сценарии взаимодействия приложений, а так же приводится описание продуктов класса сервис-брокер различных производителей.
Ключевые слова: IP мультимедийная подсистема (IMS), сервис-брокер, диспетчер взаимодействия услуг (SCIM), функциями управления вызовами и сеансами (CSCF), сервер приложений (AS).
Варюхин С.В.,
ОАО "Интеллект Телеком",
Руководитель проектов Департамента технической стратегии, к.ф.-м.н., [email protected]
Моргунов В.С.,
ОАО "Интеллект Телеком",
Главный специалист Департамента технической стратегии,
Назаров А.Н.,
ОАО "Интеллект Телеком",
Начальник отдела Департамента технической стратегии, дт.н,
Введение
В настоящее время архитектура подсистемы предоставления мудьтимедийных услуг на основе протокола IP — IMS (IP Multimedia Subsystem) является одной из самых распределенных информационных систем, в том числе на различных уровнях взаимодействия, обеспечивая вместе с тем интеграцию самых различных приложений. На сегодняшний день в различных странах мира, в том числе и в России, внедрено и внедряется в коммерческую эксплуатацию довольно большое количество оборудования IMS от различных производителей. Подсистема IMS нацелена на предоставление открытой среды для быстрого создания услуг и внедрения их в эксплуатацию независимо от применяемых на сети технологий доступа, но этот подход не обязательно решает все проблемы взаимодействия серверов приложений и предоставления услуг. С точки зрения архитектуры подсистема IMS жестко определена в стандартах, но вот когда дело доходит до взаимодействия конкретных услуг, то тут-то и оказывается, что все не так просто. На первый взгляд вроде бы ответ, который долго искали, найден, и все должно работать, но когда дело до-
ходит до конкретики, то выясняется, что IMS является не единственным оборудованием на сети.
Вопрос интеграции между различными платформами и приложениями всегда стоял очень остро. И когда на сети встречаются либо сервера приложений IMS одного производителя оборудования, а ядро IMS другого, либо есть унаследованные платформы1, функционал которых необходимо перенести на абонентов новой сети, возникает необходимость в установке такого элемента как диспетчер взаимодействия услуг SCIM (Service Capability Interaction Manager). Функциональность SCIM направлена на управление сервисными возможностями и организацией взаимодействия между любым типом серверов IMS приложений.
Сегодня так же остро стоит вопрос не только взаимодействия серверов приложений различных типов между собой, но и взаимодействия различных новых услуг, возможно созданных на одной платформе, но работающих независимо друг от друга. В данном случае за логику взаимодействия услуг также должен отвечать SCIM.
Перечисленные выше факторы несомненно отражаются как на дополнительных капитальных затратах, так и на дополнительных операционных затратах, которые может понести оператор.
Развитие концепции SCIM международными стандартизирующими организациями
3GPP (англ. 3rd Generation Partnership Project) — консорциум, разрабатывающий спецификации для мобильной телефонии третьего поколения. В рамках 3GPP для систем подвижной связи третьего поколения (3G) были разработаны спецификации, которые являются частью семейства спецификаций ITU IMT-2000. Партнеры по проекту 3GPP также ответственны за поддержку и усовершенствование спецификаций для стандарта GSM и переходных технологий по направлению к системам 3G.
SCIM был предложен в технической спецификации консорциума 3GPP [1] для организации взаимодействия между серверами приложений AS (Application Server) при построении
Рис. 1. Архитектура подсистемы предоставления мудьшмедийных услуг диспетчером взаимодействия услуг
подсистемы IMS на сети сотовой связи. В нотации 3GPP SCIM был представлен, как часть сервера приложений AS (рис.1) [2] .
HSS: Home Subscriber Seiver, сервер домашних абонентов; S-CSCF: Serving Call Session control Function, функциями управления вызовами и сеансами; AS: Application Server, сервер приложений; Sh: Reference between AS and HSS, эталонная точка между AS и HSS; Cx: Reference point between CSCF and HSS, эталонная точка между CSCF и HSS; CAP: CAMEL (Customized Applications for Mobile Networks Enhanced) application part; MAP: Mobile application part, прикладная часть для мобильных сетей; MRFC: Multimedia Resource Function Controller, узел контроля мультимедийных ресурсов; MRFP: Multimedia Resource Function Processor, узел обработки мультимедийных ресурсов; MRF: Multimedia Resource Function, совокупность функций MRFP и MRFC; MRB: Media resource broker, узел обеспечения распределения нагрузки между разнородными узлами MRF; IM-SSF: IP Multimedia Service Switching Function, функция коммутации услуг IMS; Si: Reference point between a HSS and IM-SSF, эталонная точка между HSS и IM-SSF; Mr: Reference point between CSCF and MRFC, эталонная точка между CSCF и MRFC; OSA SCS: Open Service Access-Service Capability Server, сервер предоставления услуг на основе доступа; ISC: IP Multimedia Service Control, управление IMS-серверами.
В дальнейшем развитии спецификаций 3GPP функции SCIM возлагались на отдельно устанавливаемый логический модуль опорной сети, который получил название сервис-брокер SB (Service Broker) [3].
В результате возрастающей популярности концепции SCIM и SB был организован форум (Service Broker Forum), который объединил ведущих производителей продуктов данной категории [4]. Целью создания форума является определение всех необходимых интерфейсов для существенного ускорения процесса разработки и внедрения новых услуг. В первую очередь деятельность нового форума направлена на производителей оборудования связи.
В качестве предпосылок для создания архитектуры сети, включающей в себя SB, можно рассматривать следующие факторы:
• При разработке и внедрении новых сервисов вносить минимальные изменения в опорную сеть IMS и уже существующие серверы приложения AS;
• Обеспечивать возможность организации гибкого взаимодействия между новыми приложениями;
• Обеспечивать возможность организации взаимодействия между AS, избегая избыточного взаимодействия между приложениями;
• Управлять взаимодействием между IMS приложениями, программами, позволяющие
обеспечивать подключение услуг или других функций в системах связи (enabler) и другими, не-IMS приложениями;
• Поддерживать взаимодействие с существующими сервисами интеллектуальных сетей (IN);
• Упрощать организацию взаимодействия в гетерогенных сетях нескольких провайдеров;
• Предоставлять возможность персонализировать и управлять абонентскими услугами.
Физически, SB расположен между узлами опорной сети, отвечающими за управлением вызовами и сессиями, например, коммутаторами сети сотовой связи MSC (Mobile Switching Center), софтсвичами, основным элементом IMS — функцией управления вызовами и сеансами CSCF, и приложениями уровня услуг, будь то традиционные IN приложения, или SIP (Session Initiation Protocol, протокол установления сеанса) приложениями сетей следующих поколений NGN.
В концепцию SB включена комбинация следующих основных функций:
• SCIM, как модуль обеспечивающий взаимодействие серверов SIP-AS;
• IM-SSF, функция коммутации услуг, которая обеспечивает взаимодействие сообщений SIP с соответствующими сообщениями CAMEL, ANSI-41, подсистем INAP (Intelligent Network Application Protocol) или TCAP (Transaction Capabilities Application Part). Это взаимодействие позволяет поддерживаемым IMS IP-телефонам получать доступ к сервисам определения имени вызывающей стороны, бесплатного номера 800, переноса локального номера, и др.;
• IN-IN Trigger Management, управление механизмом выполнения услуг между IN платформами, возможность SB дублировать и оказывать влияние на сигналы о событиях от IN платформы на множество приложений, и таким образом, создавать комбинации услуг на основе IN платформы;
• Protocol/Call Flow Management, управление протоколами и вызовами для обеспечения взаимодействия и приведение к единому формату сигнализации и протоколов при установлении соединений между различными сетевыми элементами и сетями;
• Subscriber Data Management Interaction, управление взаимодействием профилей пользователей для обеспечения связности и взаимодействия между различными хранилищами данных о пользовательских профилях, которые для своей работы используют различные протоколы.
Сценарии взаимодействия приложений
Взаимодействие приложений может произойти по одному или нескольким следующим сценариям:
1. Взаимодействие приложений между серверами приложений.
Принимая во внимание тот факт, что различные приложения реализуются с использованием различных протоколов, взаимодействие приложений может быть взаимодействием между сетевыми узлами, на которых размещаются приложения, при этом приложения могут находиться как на одном, так и на разных серверах.
2. Взаимодействие между приложениями, реализованными на различных протоколах.
Для IMS SB взаимодействием приложений считается взаимодействие приложений, реализуемых с помощью хотя бы одного из следующих протоколов:
• IMS приложения, реализованные на протоколе SIP, взаимодействие с SB происходит напрямую;
• OSA приложения, запускаемые на OSA сервере приложений, которые взаимодействуют с SB через API интерфейс и OSA SCS;
• IN приложения, запускаемые в точке коммутации услуг SCP (Service Control Point), взаимодействуют с SB через IN шлюз.
3. Взаимодействие между приложениями различных типов
Приложения могут быть следующих типов:
• Приложения, для доступа к которым пользователи должны зарегистрироваться в сети оператора предоставляющего услуги;
• Приложения, для доступа к которым не требуется регистрация в сети оператора предоставляющего услуги.
Принимая во внимание приведенные выше типы приложений, взаимодействие приложений включает следующие варианты:
• Взаимодействие между приложениями, требующими регистрации (подписки) в сети оператора;
• Взаимодействие между приложениями, которые как требуют, так и не требуют регистрации в сети оператора;
• Взаимодействие между приложениями, не требующими регистрации в сети оператора.
4. Взаимодействие приложений в зависимости от их состояния
Приложение может иметь следующие состояния:
• Задействованное;
• Не задействованное.
• Ясно, что между незадействованными приложениями не может быть взаимодействия. Реально возможны следующие варианты:
• Взаимодействие между уже задействованным приложением и приложением, которое будет задействовано;
• Взаимодействие между приложениями, которые уже задействованы.
5. Взаимодействие между приложениями, в которых задействованы разные пользователи
Приложения могут быть предоставлены как одному, так и нескольким различным пользователям, таким образом, взаимодействие прило-
жений включает следующие варианты:
• Взаимодействие между приложениями для одного пользователя;
• Взаимодействие между приложениями для разных пользователей.
6. Взаимодействие приложений между активными сессиями
Пользователь может принимать участие в нескольких сессиях, в этом случае взаимодействие приложений будет включать следующие варианты:
• Взаимодействие между приложениями, участвующими в одной сессии;
• Взаимодействие между приложениями, участвующими в нескольких сессиях.
7. Взаимодействие приложений между сервисными доменами различных операторов
Приложения или сервера приложений могут находиться у различных операторов, оказывающих услуги. В этом случае взаимодействие приложений включает следующие варианты:
• Взаимодействие между приложениями, находящимися у различных операторов, оказывающих услуги;
• Взаимодействие между приложениями, находящимися у одного и того же оператора, оказывающего услуги.
Варианты архитектурных решений по взаимодействию сервис-брокера и серверов приложений
Интерфейс !БС используется для взаимодействия БВ, ДБ и Б-СБСР и передачи информации об истории вызовов процедур и статусе, включающем, какие процедуры вызывались, результатах вызова, были процедуры отменены или завершены успешно. Иногда используются интерфейсы БЬ и Сх, связывающие БВ и НББ, через которые загружается логика взаимодействия приложений, которая является частью профиля абонента.
БВ может быть представлен в виде отдельно стоящего узла опорной сети, или его функционал может быть встроен в сервер приложений или в узел 1МБ Б-СБСР
Функционал БВ может быть реализован как на одном узле (централизованная архитектура), так и на нескольких узлах (распределен-
архитектура, совмещающая указанные выше схемы (рис. 2) [3].
В централизованной архитектуре серверы приложений ДБ, на основании одновременного использования которых разработана новая услуга, "не знают" о существовании в опорной сети БВ, а узел Б-СБСР взаимодействует с БВ как с сервером приложений ДБ, поддерживающим интерфейс !БС. В данной архитектуре функционал БВ может быть реализован на уровне приложений, то есть вне Б-СБСР, или может быть встроен в Б-СБСР К недостаткам первого случая можно отнести необходимость реализации дополнительных средств обеспечения безопасности и доверительных отношений при использовании ресурсов различных ДБ. В то время, как во втором случае могут возникать проблемы при модульном наращивании сети, гибкости внедрения новых сервисов и возможной перегрузке узла Б-СБСР
Для распределенной архитектуры каждый сервер приложений ДБ, который вовлечен в предоставление интегрированного сервиса, имеет один БВ, который может быть интегрирован в ДБ или представлять собой отдельный узел в сети. Узел Б-СБСР взаимодействует с каждым БВ, как с отдельным ДБ, поддерживающим !БС интерфейс. Узел Б-СБСР перенаправляет сообщения между разными БВ до тех пор, пока серверы ДБ не завершат выполнение своих функций.
Гибридная архитектура представляет собой объединение двух представленных выше схем. В этой архитектуре БВ управляет не только взаимодействием серверов ДБ, которые находятся под его непосредственным контролем, но также взаимодействует и с другими, равноправными с ним БВ.
Для управления взаимодействиями между ДБ узлы опорной сети БВ должны иметь [5]:
• информацию о всех вовлеченных сервисах;
• информацию об используемых интерфейсах;
• взаимоотношения и связь между сервисами;
• политику и бизнес правила сервис-провайдеров и сетевых операторов;
• предпочтения абонентов.
Описание продуктов класса сервис-брокер различных производителей Motorola ServiceBroker
Решение Service Broker входит в состав линейки продуктов Motorola для объединения услуг связи Communications Convergence Engine (CCE) — универсальной платформы для операторов услуг кабельной и мобильной связи, включающей в себя средства для быстрого создания, администрирования и поставки объединенных пакетов услуг по передаче видео, голоса и данных для большого количества сетей и устройств. Motorola CCE представляет собой программную платформу, объединяющую традиционные инфраструктуры, SIP и IMS. Эта платформа позволяет поставщикам услуг расширять и развивать свои портфели продуктов путем включения всех элементов комплекта из трех или четырех услуг, включая передачу видео, VoIP, сверхскоростной доступ в Интернет и объединение стационарной и мобильной связи. Решение CCE специально разработано для внедрения функций конвергентных сетей и управления ими через универсальную платформу обслуживания Service delivery platform (SDP).
Oracle Communications Service Broker
Продукт Oracle Communications Service Broker является посредником между сетями различных типов и осуществляет управление множеством услуг в реальном времени, позволяет создавать новые конвергентные услуги, используя открытые стандарты, высокую масштабируемость и доступность платформ.
Сервис-брокер компании Oracle позволяет управлять и вызывать составные услуги в IP и SS7 доменах, при этом контролируя разнотипные типы вызовов, сессий и состояний. Он поддерживает конфигурируемые управляемые профили, которые могут быть использованы для предоставления пользовательской информации, при задействовании вновь вызываемых услуг с минимизацией излишнего обмена информацией.
Opendoud Rhino Service Interaction Server
Продукт Rhino Service Interaction Server (SIS) компании OpenCloud представляет собой мощную, гибкую и расширяемую платформу взаимодействия приложений, которая обеспечивает возможность создания конвергентных услуг и функциональность для взаимодействия между SS7 и IMS сетями.
Сервис-брокер Rhino SIS может быть использован как для традиционных телекоммуникационных услуг, которые обычно запускаются на SCF, так и для услуг, которые, как правило, оплачиваются после их оказания, таких как: Centrex, PBX и VPN. Сервис-брокер Rhino SIS обеспечивает трансляцию протоколов из SIP в IN и обратно, при этом обеспечивается взаимодействие между доменами пакетной и ка-
ная архитектура), также возможна гибридная
Рис. 2. Варианты архитектур сети с сервис-брокером.
нальной коммутации. Это позволяет абонентам сети TDM/SS7 пользоваться услугами, расположенными в IMS домене, и наоборот, при этом не происходит дублирования услуг в TDM или IMS сети.
Metaswitch Service Broker
Сервис-брокер Metaswitch Service Broker располагается в сети между уровнем приложений и опорной сетью и обеспечивает взаимодействие между различными доменами сети, включая IN/TDM, IP/IMS. Он обеспечивает взаимодействие между любыми приложениями, как уже существующими, так и новыми, и сетевыми элементами без необходимости вносить изменения в сервера приложений и элементы опорной сети.
Amdocs jNetX Service Broker
Платформа разработки услуг Amdocs Service Delivery Framework (SDF) значительно сокращает время, необходимое для разработки и внедрения новых сервисов и обеспечивает возможность максимального повторного использования существующих систем. Это решение SDF включает Amdocs jNetX Service Broker, имеющий функциональность сервис-брокера и поддерживающий взаимодействие на основе сигнализации SS7 (для MSC, HLR и IN платформ) и сигнализации, используемой в сетях следующих поколений на основе IP
Aepona ServiceBroker
Сервис-брокер компании Aepona предоставляет большие возможности для реализации IN и SIP сервисов благодаря преодолению ря-
да технических ограничений, которые существуют сегодня во множестве как унаследованных, так и ЫОЫ сетей. В N сетях сервис-брокер преодолевает ограничения в конфликтах между N платформами при выполнении услуг, в то время как для Б!Р телефонии обеспечивается функциональность БС!М и 1М-ББР
Сервис-брокер компании Деропа полностью поддерживает функционал для !БС интерфейса и в полной мере отвечает потребностям сетей ЫОЫ. Реализация взаимодействия между приложениями была выполнена в соответствии с рекомендациями 3ОРР/3ОРР2 и включена в эталонную архитектуру !МБ в качестве БС!М. Сервис-брокер управляет взаимодействием между приложениями как для Б!Р, так и для N платформ и выступает в качестве посредника при вызове независимых друг от друга Б!Р приложений в рамках одной и той же сессии или вызова.
Заключение
На данный момент стандартизация БС!М и БВ далека от завершения. В настоящее время существуют частные решения производителей, которые можно разделить на три типа в соответствие с функциями БВ:
• внутренний БВ, который соответствует распределенной архитектуре и является частью серверов приложений ДБ;
• внутренний БВ, являющийся частью функции управления вызовами и сеансами Б-СБСР;
• внешний БВ, соответствующий централизи-рованной и гибридной архитектурам, и представляющий собой отдельный узел опорной сети.
Функциональность, которую обеспечивает
сервис-брокер, играет важную роль в управлении взаимодействием услуг. Без данной функциональности будет сложно достичь эффективности при взаимодействии большого количества услуг между собой, а так же взаимодействия между приложениями, работающими с использованием различных протоколов и на сетях нескольких операторов, предоставляющих совместные услуги. На данный момент стандартизация SCIM и SB далека от завершения. На рынке существуют частные решения производителей. Решения, которые можно рассматривать, как внутренние сервис-брокеры, в большей степени привязаны к архитектуре IMS, в ряде случаев их функциональность реализована на узлах IMS. Наибольшее распространение на настоящий момент получили решения, представляющее собой внешние сервис-брокеры, основная функциональность которых заключается в том, чтобы реализовать функции сигнального шлюза между сетями и приложениями с разными протоколами сигнализации.
Литература
1. 3GPP TS 23.002: "Network Architecture".
2. 3GPP TS 23.218: "IP Multimedia (IM) session handling".
3. 3GPP TR 23.810: "Study on Architecture Impacts of Service Brokering".
4. http://www.senvcebrokerlorum.ong.
5. HUI-NA CHUAa , CHOR-MIN TANa , YUXIN Hob. A Study of Issues and Considerations of Service Interaction management in IMS Architecture. WSEAS TRANSACTIONS on COMPUTERS, ISSN: 1109-2750, Issue 9, Volume 7, September2008, pp. 1405-1415.
INTEGRATION OF APPLICATIONS IN COMMUNICATION NETWORKS WITH THE SUBSYSTEM IMS
S. Varyukhin, OJSC "Intellect Telecom", Project Manager Technical Strategy Department, [email protected] V. Morgunov, OJSC "Intellect Telecom", Senior Expert Technical Strategy Department, [email protected] ANazarov, OJSC "Intellect Telecom", Head of Division Technical Strategy Department,[email protected]
Abstract
Currently, the IMS architecture is one of the most distributed information systems, including different levels of interaction, while ensuring the integration of various applications. At the base of IMS is the interaction of various components through protocols of different levels and an efficient distribution of functions between components. One of main IMS's function is assignment of open environment for fast service delivery and implementation of them independent of applying access technologies and services. One of IMS's elements is service broker. The functionality of a service broker is directed to manage service capabilities and arrangement of interaction between any type of IMS application servers. However, all the problems of service interactions and service provisioning are not solved yet and Service Brokering function as currently being studied by the 3GPP and Service Broker Forum. In this paper the evolution of Service Broker functionality proposed in standards, aspects of architecture and application interaction scenarios are examined, as well as a description of service broker products from different vendors is given.
Key words: IP Multimedia Subsystem (IMS), service broker, Service Capability Interaction Manager (SCIM), Serving Call Session control Function (CSCF), Application Server (AS). Rekrenses
1. 3GPP TS 23.002: "Network Architecture".
2. 3GPP TS 23.218: "IP Multimedia (IM) session handling".
3. 3GPP TR 23.810: "Study on Architecture Impacts of Service Brokering".
4. http//www.sen/icebrokerforum.org.
5. HUI-NA CHUAa , CHOR-MIN TANa , YUXIN Hob. A Study of Issues and Considerations of Service Interaction management in IMS Architecture. WSEAS TRANSACTIONS on COMPUTERS, ISSN: 1109-2750, Issue 9, Volume 7, September 2008, pp. 1405-1415.
