Развитие услуг на украинском рынке мобильной связи

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

Рис.1 Соотношение JSE, JME и CLDC/CDC с развитием терминалов

Традиционно разработкой приложений для предоставления услуг занимались производители крупного телекоммуникационного оборудования. По мере развития рынка стало очевидно, что практически каждому оператору требуются нестандартные приложения, отвечающие запросам именно его абонентов. Возникла необходимость в детальном анализе спроса на новые услуги, поиске оптимальных решений и квалифицированных партнёров (application, service, content-провайдеры) для разработки гибких инструментов и приложений. Появился новый сегмент мобильной сети — Service Layer, уровень платформ, приложений и контента, на котором используются уже хорошо зарекомендовавший себя транспорт (SMS, MMS, WAP gateway, Internet access) и новые системы и решения (Content Delivery, OSA Parlay — Open Service Access, IPTV, JVM — Java virtual machine, IP Centrex, MoIP — messaging over IP, SIP-based).

Ситуация на рынке мобильной связи требует поиска наиболее гибких систем и решений, не только поддерживающих стандартные сетевые протоколы (особенно в сегменте интеллектуальных систем IN), но и отвечающих спросу и растущим возможностям абонентских терминалов (Java, Windows, Symbian, Linux, SavaJe, другие API). Современные технологии требуют перестроения сети оператора с использованием новых подходов к развитию и планированию сети — от традиционно-вертикальной интеграции, когда предоставляемая услуга полностью обеспечивается одним оператором, до поиска горизонтальной интеграции, когда одна и та же услуга (например, ежедневное обновление курса валют, кривых роста индексов фондовых рынков с выводом графиков на телефон пользователя) предоставляется программным комплексом на платформе Application Service-провайдера для нескольких операторов одновременно.

Большинство операторов сегодня рассматривают сегмент сети сервисного уровня (Service Layer) в качестве основного элемента своей общей бизнес-стратегии уже на ближайшее время. Хотя доля реализации сервисного уровня в стоимости всей сетевой инфраструктуры невысока, потенциально она может значительно улучшить показатель доходности ARPU от каждого абонента и привлечь потребителей в новые сегменты рынка.

Новые услуги на рынке. Аппаратная платформа пользовательского терминала

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

Новые мультимедийные услуги требуют внедрения новых функций и протоколов в пользовательском мобильном телефоне. Расширенные возможности современных мобильных телефонов всё чаще заставляют производителей задуматься о поиске новых операционных сред. Существующие на рынке телефоны совместимы с операционной средой Java&trade (является официальной торговой маркой Sun Microsystems). Новые приложения базируются на подуровнях Java&trade — MusicDJ&trade, PlayNow&trade, но эти названия скорее знакомы пользователям, а создателям приложений хорошо известны Java for Micro Edition (JME), Java for Enterprise Edition (JEE), Java for Standard Edition (JSE). В частности, стандарт JME обязан своим появлением первоначальному и хорошо известному Java Community Process (JCP).

Рис.2 Взаимные требования и соотношение услуг, спроса и технологий

В области крупных сетевых решений компания Ericsson разработала и представляет платформу EMP (Ericsson Mobile Platform), которая наряду со стандартами JME, JEE, JSE поддерживает и API-интерфейс (Application Programming Interface) и является платформой уровня middleware и открытого доступа OPA (Open Platform API). EMP даёт возможность производителям разрабатывать мобильные телефоны и смартфоны стандартов GPRS, EDGE и WCDMA.

Java-приложения можно сегодня обнаружить везде, на компьютерах любых типов: на пользовательских КПК, в современных автомобилях, в медицинских системах, в смартфонах и смарт-картах, играх. Но в силу минимизации процессорных модулей и по-прежнему высоких требований к графическому интерфейсу, Java-среда разделилась на три направления (см. рис.1):

• Java for Standard Edition (JSE) — для персональных компьютеров;
• Java for Enterprise Edition (JEE) — для специальных приложений, в основном сегмент оборудования Enterprise;
• Java for Micro Edition (JME) — для потребительских устройств широкого пользования, включая мобильные телефоны.
JME-среда, в свою очередь, может иметь конфигурацию двух типов:
 • Connected Limited Device configuration (CLDC) — используется для конфигурации мобильных телефонов дистанционно (оператором или при подключении PC), а также при пользовании SIM Tool kit;
• Connected Device Configuration (CDC) — используется в карманных ПК (PDA) и смартфонах.

С момента появления CLDC разработчики этого протокола и создатели приложений уделяли большое внимание совместимости возможностей CLDC с аппаратными средствами телефонов. В силу явной тенденции к миниатюризации устройств, возможности CLDC для построения новых мощных приложений раскрывались постепенно, по мере выхода мультимедийных телефонов нового поколения. Создание более функциональной CLDC (в реализации CDC) расширило возможности JME-профайла самого терминала на порядок, позволяя загружать приложения сразу с момента старта. CLDC, CDC поддерживают mobile information device profile (MIDP), который обеспечивает API-интерфейс и открывает широкое поле для деятельности на пути построения объединённой компилированной среды CLDC/MIDP. Текущая версия унифицированной среды — MIDP 2.0, которая вскоре будет заменена на MIDP версии 3 (JSR-271), позволяет работать одновременно нескольким приложением на терминале с возможностью доступа к общим базам данных на сервере провайдера с более высоким уровнем безопасности.

Рис.3 Игроки на рынке, отношения между ними

Рынок Java-приложений стремительно развивается. В сентябре 2005 года GSM Ассоциация предоставила статистику, свидетельствующую, что число мобильных терминалов в мире превысило 2 миллиарда, при этом, по данным Sun Microsystems, число Java-совместимых мобильных телефонов на планете составляет более 700 миллионов.

Сегментация сетей и услуг.
Провайдеры услуг

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

Несмотря на то, что предоставление дополнительных абонентских услуг в сетях связи становится всё более привлекательным для больших операторов, имеющих всю инфраструктуру GSM/EDGE, WCDMA (RAN, UTRAN, Core, Packet backbone), практика показывает, что успех в этом бизнесе имеет место там, где услуги создаются профессиональными разработчиками, контент-провайдерами и сервис-провайдерами. На рынок абонентских услуг выходят новые игроки, чья деятельность сфокусирована на услуге как таковой, а не на способе и скорости доставки её пользователю. Появляются порталы и серверы, доступ к которым имеют как разработчики, так и представители отделов маркетинга (оператора и провайдера), тестирующие новые услуги. В результате формируются определённые устойчивые отношения между разными функционирующими звеньями одной цепи разработки E2E (End to End) -сервисов, способствующие более успешному ведению бизнеса (здесь можно говорить о бизнес-моделях, определяющих отношения B2B — Business to Business — между игроками на рынке). Такие отношения выдвигают свои специфические требования к техническим процессам создания услуг, т.е. к используемым технологиям на разных этапах — разработки, наладки и эксплуатации приложений (рис.3). При этом, как правило, компаниям-разработчикам не нужно быть технически “подкованными” в области связи, они могут эффективно использовать имеющиеся средства информационных технологий (например, языки программирования С++, Java, стандартные серверы приложений компаний Microsoft, Sun, Borland и т.д.).

Рис.4 Структура Parlay-шлюза, протоколы взаимодействия

Например, говоря о вертикально-интегрированных решениях, технология IN (интеллектуальная сеть) позволила вынести размещение логики сервиса в специальные узлы SCP (Service Control Point), которые образовали управляющий уровень интеллектуальных сетей, отделённый от сетей доступа. Таким образом была решена задача предоставления интеллектуальных услуг одного узла SCP абонентам различных сетей доступа, а также абонентам различных операторов. Но такие узлы SCP по-прежнему являются платформенно-зависимыми. Так, у компании Ericsson это узлы на базе AXE-810, у Alcatel — на базе S12, у Siemens — продукт INXpress. Следовательно, кроме поставщиков сетей IN никто не может создавать и модифицировать абонентский сервис, организуемый на базе SCP. Необходимость гибкого конфигурирования услуг оператором сети привела к созданию средств спецификации услуг с использованием блоков SIB (Service Independent Block). Но только открытые технологии с использованием прикладных программных интерфейсов API позволили окончательно уйти от платформенной зависимости в вопросах разработки сервисных приложений.

При стремлении к горизонтальной интеграции возникает задача предоставления технической возможности третьим сторонам (не операторам и не поставщикам сетей) разрабатывать платформенно-независимые сервисные приложения путём использования самого широкого класса ИT-средств: различных языков программирования, операционных систем и аппаратных платформ. Технология OSA/Parlay (OSA — Open Service Access) призвана разрешить именно эту задачу, имея в себе Parlay-шлюз доступа к серверам приложений и инкапсулированные сетевые протоколы INAP, CAP, MAP, IS41, CS1, CS1+, CS2, H.248, H.323, SIP (рис.4)
Parlay — (амер. англ., ХХ в.) действие в карточной игре, при котором выигранные деньги используются в следующей ставке для увеличения последующего выигрыша.

Рис.5 Parlay-интерфейсы

На рис.4 показана концепция решения Parlay. Абоненты сетей доступа посредством Parlay-шлюза пользуются услугами, предоставляемыми сервисными приложениями. Услуги могут быть доступны абонентам самых различных сетей — мобильных сетей (GSM, TDMA, и т.д.), сетей общего пользования (ТФОП), IP-сетей. Если сеть не поддерживает ни один из перечисленных сетевых протоколов прямого взаимодействия с Parlay-шлюзом (например, сеть мобильной связи NMT450), это не исключает предоставления услуг абонентам. В этом случае доступ к услугам может быть предоставлен через сеть, которая поддерживает такой протокол — например, через сеть ТФОП по одному из вариантов протокола INAP: CS1, CS1+, CS2. Каждый из приведенных компонентов отвечает за определённую функциональность в сетях связи при выполнении логики сервиса: управление вызовами, взаимодействие с пользователями услуг, определение местоположения абонента и т.д. Parlay-шлюз, или сервер доступа к услугам (Service Capability Server — SCS), взаимодействует с сетью доступа по существующим сетевым протоколам (CAP, MAP, H.323, и т.д.), а с серверами приложений шлюз взаимодействует при помощи открытых прикладных программных интерфейсов Parlay. Это даёт возможность управлять сервисными компонентами шлюза со стороны приложений, обеспечивая тем самым управление сетью доступа и реализуя ту логику сервиса, которую создал разработчик сервисного приложения.

Рис.6 Framework интерфейсы. Возможность построения бизнес-модели

Серверы приложений могут размещаться в сетях LAN или WAN, связываясь по протоколу TCP/IP с Parlay-шлюзом. Таким образом, реализуемая логика и содержание абонентских услуг могут быть распределены в интернете, осуществляя принцип привлечения большего числа разработчиков услуг.

Один из элементов технологии Parlay — OSA Framework — является основным компонентом, обеспечивающим согласованную работу сервисных элементов и сервисных приложений. На него возложены функции регистрации и аутентификации приложений, обеспечение их целостности и ряд других функций. Можно отметить, что приложение, как и сервер приложений, может быть также распределённым, т.е. реализованным в IP-сети на нескольких компьютерах. В соответствии с этим спецификация Parlay различает три основных типа интерфейсов (рис.5):

1. Интерфейсы Framework — сервисные приложения
2. Интерфейсы сервисные приложения — сервисные компоненты
3. Интерфейсы Framework — сервисные компоненты

Разработчика сервисных приложений в особенности интересуют первые два типа интерфейсов API. Универсальность использования программных интерфейсов API достигается благодаря использованию языка IDL (Interface Description Language) для их описания. Этим обеспечивается возможность написания сервисных приложений на различных языках программирования: С++ и Java (существуют соответствующие компиляторы IDL -> C++ и IDL -> Java). Спецификации Parlay для каждого компонента содержат диаграммы классов (Class Diagrams) и классы интерфейсов (Interface Classes), которые описывают используемые компонентом интерфейсы (здесь под компонентом понимается Framework или сервисные компоненты). Для описания классов интерфейсов использован язык UML (Unified Modelling Language) объектного моделирования.

Интерфейс сервисные приложения — Framework обеспечивает следующие механизмы:

Рис.7 JAIN Community

• Аутентификация приложений. Приложение должно быть аутентифицировано перед тем, как оно сможет получить доступ к другим интерфейсам OSA;
• Авторизация приложений, в процессе которой определяется доступ приложения к определённым функциям сервисных компонентов;
• Инвентаризация (discovery) компонента Framework и функций сервисных компонентов. Приложение получает доступ к интерфейсам Framework и информацию о доступных функциях сервисных компонентов;
• Установление сервисного соглашения, которое должно быть “подписано” приложением перед использованием им ресурсов и функций сервисных компонентов;
• Доступ к функциям сервисных компонентов. Framework обеспечивает контроль доступа к функциям сервисных компонентов для любого API-метода приложения.

Интерфейс Framework — сервисные компоненты обеспечивает механизм регистрации функций сервисных компонентов в Framework.
Интерфейс Framework — оператор услуг обеспечивает механизм подписания контрактного соглашения (сервисного контракта) между оператором услуг и компонентом Framework.

Таким образом, для Framework определены три типа интерфейсов (рис.6):

• Cервисные приложения — Framework (интерфейс 1);
• Framework — сервисные компоненты (интерфейс 3);
• Framework — оператор услуг (интерфейс 4).

Рис.8 Взаимодействие среды JAIN SLEE с сетью оператора GSM

На рис. 6 показано, что оператор услуг может выступать в роли заказчика ресурсов для сервисных приложений, сервисное (клиентское) приложение — в роли потребителя ресурсов сервисных компонентов, а Framework — в роли розничного продавца ресурсов. Механизм подписки сервисного контракта оператором услуг заключается в установлении на определённых условиях ассоциированных связей между сервисными приложениями, принадлежащими данному оператору услуг, и необходимыми ему функциями сервисных компонентов. Благодаря существующим открытым интерфейсам (интерфейс 3 на рис.6), Framework может существовать отдельно от сервисных компонентов. В этом случае под сервером доступа к услугам (SCS) мы понимаем только набор сервисных компонентов, каждый из которых, в принципе, может быть предоставлен своим вендором, как, собственно, и Framework.

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

В концепции Parlay технология Framework играет ключевую роль, а в конкретной реализации хорошо известны приложения Java, а именно JAIN и JSLEE, как результат совместного труда разработчиков на портале Sun Developer Network (SDN).

Рис.9 Логические компоненты SIP-протокола

JAIN — это среда Java (Java IN), которая разрабатывается с 1997 года. Технология JAIN предполагает использование разработчиками сервисных приложений объектно-ориентированного языка программирования Java или, другими словами, технологии Java с хорошо развитыми средствами создания приложений (в частности, компонентной моделью EJB, Enterprise JavaBeans). Кроме того, JAIN вместе с комбинацией SLEE/JAIN является средой для Application-провайдеров при разработке программ, совместимых и работающих с OSA/Parlay. Для этой цели на базе организаций Parlay Group и JAIN Community (рис.7) была создана рабочая группа Parlay Java Realization Work Group.

JAIN SLEE не выполняет функции network connectivity, для этого используются сетевые протоколы INAP, CS1, CAP. Объектно-ориентированной технологией для связи ресурсных адаптеров OSA/Parlay-сервера является технология взаимодействия с сетевыми протоколами SCF/SSF — Corba, которая является связующим звеном с сетью GSM-оператора (рис.8).

SLEE — Service Logic Execution Environment — это среда, предназначенная для создания ресурс-адаптеров (resource adaptor) с целью развёртывания Parlay/Parlay-X аппликаций. В условиях постоянного поиска оптимальных интерфейсов, отсутствия стандартизированных протоколов, использования API, а также специфических Parlay-сред J2SE и J2EE, основанных на Java, среда SLEE может использоваться как более унифицированная с применением ресурс-адаптеров.

В последнее время очень часто применяется протокол SIP (Session Initiation Protocol) в качестве сигнального протокола, используемого для установления, модификации и разъединения мультимедийных сессий в IP-сетях. Протокол SIP закладывается разработчиками и производителями в последующие модификации IP backbone -оборудования (такие как SGSN, GGSN, Mobile Enablers for messaging & charging). Хотя разработкой и стандартизацией протокола занималась специальная группа IETF (IETF — Internet Engineering Task Force), SIP был принят крупными международными организациями по стандартизации в качестве главного протокола мультимедийных сервисов мобильных сетей третьего поколения (3G). Компания Ericsson разработала и предложила готовое решение — IMS (IP Multimedia Subsystem). Сети NGN (NGN — Next Generation Network) будут развиваться параллельно с существующими сетями 2G/3G и предлагать миграцию традиционных сетей связи в NGN. Направление развития многофункциональных и мультимедийных сетей, базирующихся на протоколе IP, будет стремиться к унификации и функциональности, что на сей день реализовано в протоколе SIP. Между всеми заинтересованными группами в индустрии телекоммуникаций достигнут консенсус о протоколе SIP как главном средстве реализации мультимедийных коммуникационных услуг следующей генерации.

Рис.10 IMS-архитектура

Протокол инициации сессии, SIP, — это сигнальный протокол прикладного уровня (application level control protocol), разработанный с целью:

• создания, модификации и прерывания мультимедийных сессий или вызовов между двумя или несколькими участниками;
• поиска местонахождения пользователя и переадресации вызова;
• обеспечения мобильности с помощью переадресации вызова и использования proxy-сервера посредника.

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

• мультимедиа (речь, видео, и т.д.);
• игры (Gaming);
• присутствие и мгновенный (в реальном времени) обмен сообщениями (Presence and Instant Messaging).

Протокол SIP можно модульно надстраивать. Могут быть реализованы различные функции, механизмы безопасности, методы, заглавия, опции, транспортные протоколы и т.д., но это не обязательно, так как протокол SIP содержит механизм, обеспечивающий ему возможность определения параметров оконечного решения. Изделия компании Ericsson полностью поддерживают такие направления развития, что подтверждает мощный и всеохватный ассортимент, производимый в области коммутации пакетов IP-сети, — IP третьего (3G) и последующего поколений, их дальнейшее развитие. SIP, в отличие от протокола ISUP (ISDN User Protocol), не поддерживает концепцию различных вариантов протокола, таких как предотвращение отказа в обслуживании (denial-of-service prevention), процесс идентификации подлинности пользователя (authentication), защита целостности (integrity protection), криптографическая защита (encryption) и услуги защиты персональной информации (privacy services). Протокол SIP поддерживает варианты IP-протоколов IPv4 и IPv6 (Internet Protocol version 4 and 6), что значительно расширяет область его применения, а также облегчает миграцию сетей, базирующихся на протоколе IP, в направлении IPv6.

Рис.11 Ericsson IMS-решение

Протокол SIP структурирован как многоуровневый протокол, причём каждый уровень определяет соответствующий набор правил. Этот протокол специфицирует логические элементы. Каждый элемент протокола не должен содержать каждый из всех уровней. Кроме того, когда говорится, что некоторый элемент содержит определённый уровень, в действительности это значит, что данный элемент придерживается набора правил, определённых этим уровнем. Протокол SIP базируется на протоколе передачи гипертекста HTTP (Hypertext Transport Protocol), модели транзакций запросов и ответов (request/response transaction model). Каждая транзакция состоит из запроса, который вызывает определённый метод или функцию сервера, и минимально одного ответа на данный запрос. Протокол SIP не используется для описания характерных признаков сессии, таких как вид информации (речь, видео и т.д.), кодек или частота выборки. Вместо этого тело сообщения SIP содержит те характеристики сессии, для описания которых используется протокол описания сессии SDP (Session Description Protocol) или какой-то другой протокол, разработанный для этой цели. Возможность отделения функций управления установлением сессии от процесса согласования характеристик сессии — очень важное свойство протокола SIP, обеспечивающее его эффективность, т.к. позволяет использовать протокол для установления сессии любого типа. Протокол SIP вместе с другими IETF-протоколами является составной частью архитектуры, обеспечивающей мультимедийные возможности. Обычно такая архитектура основывается на следующих протоколах:

• Транспортный протокол реального времени RTP (Real-time Transport Protocol), используемый для передачи данных в реальном времени и для ответной информации о качестве услуги;
• Протокол потоковой передачи в реальном времени RTSP (Real-Time Streaming Protocol);
• Протокол для управления шлюзами доступа к телефонной сети общего пользования с коммутацией каналов (H.248/MEGACO — Media Gateway Protocol);
• Протокол описания мультимедийных сессий (SDP — Session Description Protocol).

Функция SIP не зависит ни от одного из вышеперечисленных протоколов. Так как SIP-сообщения и сессии, обеспечиваемые протоколом SIP, могут проходить через различные сети, протокол не может и не обеспечивает возможность резервирования сетевых ресурсов (network resource reservation capabilities). Поскольку характер предоставляемых услуг требует повышенной надёжности, протокол SIP обеспечивает и целый ряд дополнительных механизмов (предотвращение DoS, аутентификация и пр.).

На самом нижнем первом уровне протокола SIP находится синтаксис и кодирование (syntax and encoding), использующие правила расширенной формы Бэкуса–Наура ABNF (Augmented Backus-Naur Form).

Второй, транспортный, уровень (transport layer) определяет, каким образом клиент (client) посылает запросы и принимает ответы, а также как сервер принимает запросы и посылает ответы посредством сети. Все компоненты протокола SIP должны поддерживать протокол дейтаграмм пользователя UDP (User Datagram Protocol) и протокол управления передачей TCP (Transport Control Protocol), но могут поддерживать и другие протоколы, например протокол управления потоковой передачей SCTP (Stream Control Transmission Protocol). Так как UDP — ненадёжный протокол, SIP содержит собственный механизм повторной передачи, включающий и трёхвариантный (three-way) обмен между пользователями при установлении сессии.

Третий уровень, уровень транзакций (transaction layer), управляет повторной передачей прикладного уровня, соединением ответа и запроса, а также таймаутом прикладного уровня. Транзакция является базовым компонентом протокола SIP и состоит из одного или больше ответов. Уровень транзакций содержит компоненты клиента и сервера. Логическая структура любой архитектуры, использующей протокол SIP, представлена на рис. 8.

• Агент пользователя UA (User Agent) — приложение, которое устанавливает, принимает и прерывает сессию/вызов. Состоит из двух отдельных частей: клиента агента пользователя UAC (User Agent Client) и сервера агента пользователя UAS (User Agent Server). UAC посылает запросы и принимает ответы. UAS принимает запросы и посылает ответы. Приложение UA, которое инициировало вызов/сессию, в процессе посылки запроса на инициирование сессии играет роль UAC, но в случае принятия запроса о прерывании сессии ведёт себя как UAS.

• Сервер-посредник (Proxy Server) — основной задачей сервера является маршрутизация. Proxy-сервер обрабатывает SIP-сообщения (запросы и ответы) и модифицирует их, если это требуется, до маршрутизации. Согласно изменениям состояния существует несколько типов proxy-серверов:

1. Сервер Stateless proxy, не имеющий состояния транзакции во время направления запросов и ответов.

2. Сервер Stateful proxy в течение транзакции сохраняет состояние транзакции.

3. Сервер Call stateful proxy сохраняет все состояния, относящиеся к сессии (от INVITE до BYE). SIP-сервер в режиме proxy представлен на рис. 8.

4. Сервер переадресации (Redirection Server) — UAS, принимает запросы и в ответах клиенту обычно посылает один или несколько новых адресов.

5. Сервер регистрации (Registrar Server) — особый тип UAS-модуля, который принимает REGISTER-сообщения и затем принятую информацию направляет серверам определения местоположения (согласно обслуживаемым доменам).

6. Агент пользователя B2BUA (Back-to-back User Agent) — играет роль UAC и UAS, объединённых логикой приложения. B2BUA (рис. 3) принимает запросы как UAS, но для определения требуемого ответа на принятый им запрос ведёт себя как UAC и генерирует запрос. В отличие от proxy-сервера, B2BUA поддерживает состояние диалога и участвует во всех запросах инициированного им диалога.

Услуга определения местоположения (Location Service) позволяет серверу переадресации или proxy-серверу направлять запрос к местоположению вызываемого пользователя на основании принятого унифицированного идентификатора ресурса URI (Uniform Resource Identifier).

Роль UAC и UAS, а также proxy-сервера и сервера переадресации определяется для каждой отдельной транзакции. Приложение UA, инициировавшее вызов/сессию, при передаче запроса об инициировании сессии играет роль UAC, но в случае принятия запроса о прерывании сессии будет вести себя как UAS. Подобным образом одно и то же программное обеспечение в некоторых случаях будет действовать как proxy-сервер, а при следующем вызове будет выполнять функцию сервера переадресации.

С развитием стандартов систем 3G по мимо двух сетевых подсистем 2G — коммутации каналов CS (Channel Switching) и коммутации пакетов PS (Packet Switching) определена и третья подсистема — IMS (рис. 9). Протокол SIP выбран в качестве главного направляющего протокола для мультимедийных сессий в IP мультиме дийной подсистеме. Подсистема IMS определяет новую мобильную сетевую инфраструктуру, которая обеспечивает возможность конвергенции данных, речи и технологии мобильной сети, базирующейся на IP-инфраструктуре. По идее, IMS заполнит разрыв между традиционными телекоммуникациями и интернетом.

Это расширит возможности операторов в предложении новаторских услуг, ожидаемых пользователями. Подсистема IMS задумана с целью обеспечения и улучшения мобильных мультимедийных услуг в реальном времени, таких как речевые услуги (rich voice), видеотелефония, обмен сообщениями, конференция и push-услуги (пакетная передача речи, названа “нажми и говори”). IMS обеспечивает эти услуги коммуникации между оконечными пользователями посредством нескольких ключевых механизмов, включая управление и переговоры сессиями, управление качеством услуги и мобильностью. Однако IMS обеспечивает гораздо больше, чем услуги в реальном времени между пользователями. Подсистема IMS специфицирована с целью обеспечения её независимости от уровня доступа. Таким образом, она может быть использована для построения фундамента конвергенции стационарных и мобильных коммуникаций. Главные элементы подсистемы IMS представлены на рис. 10.

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

• IMS WeShare — даёт возможность пользователям моментально получать и совместно использовать информацию, такую как картинки, клипарты и прочий контент, во время разговора с другим абонентом, не прерывая соединения. Таким образом, услуга IMS weShare позволяет комбинировать доступ к предлагаемым сервисам, параллельно с предоставляемыми телефонными услугами (Circuit Switched services).

• IMS Push-to-Talk — это услуга, позволяющая оператору запустить сервисы Push-to-Talk поверх существующей GSM/GPRS/EDGE- или CDMA-сети. Решение IMS Push-to-Talk полностью соответствует стандарту Push to talk over Cellular (PoC) и фактически является решением Voice over IP на мобильных сетях  GSM с использованием Packet Switching.

• IMS Multimedia телефония. Это решение является полностью E2E сетевым решением, позволяющим предлагать и развивать расширенные мультимедийные услуги и контент, доставляемые как для мобильных абонентов посредством 2G/3G-сетей, так и фиксированным абонентам на проводных широкополосных IP-сетях.

Мультимедийная телефония также включает в себя полный пакет функциональности IP Centrex, что немаловажно для создания узконаправленных услуг на рынке SME (Small Market Enterprise) и может быть использовано для развития массовых услуг и для Circuit Switched -абонентов существующих GSM/GPRS/EDGE-сетей с поддержкой функциональности Video Streaming и Real Video. Были проведены интегрированные тесты с фиксированными ISDN-телефонами, и IMS-платформа позволила включить новые программные модули стыковки мобильных и фиксированных сетей.

• IMS Messaging. Это решение является E2E-стандартным в пакете Ericsson, основанным на IMS messaging -подходах построения мобильных и фиксированных сетей. В базовом варианте услуга предполагает передачу текстовых сообщений, расширенных информированием передающего абонента о “доступности” в сети принимаемого абонента и возможности принять сообщение. Последующие шаги мультимедийных сообщений включают в себя мультимедийные сообщения и контент, с разными возможностями изменения профайла абонентов по передаче, приёму, сохранению и дальнейшему использованию.

• IMS Studio. Это решение представляет среду для создания новых услуг, исследования спроса и обеспечения максимального качества. Это решение включает модуль Service Development Studio, поддерживающий создание приложений как на сервере, так и на клиентском терминале, использующем данную IMS-аппликацию, что достигается при помощи высокоуровневого API-протокола, скрывающего для абонента/разработчика сложность построения доступа контент-провайдера через сеть оператора к провайдеру услуг.

Центральным элементом для управления вызовом/сессией в IMS является функция управления вызовом/сессией (CSCF — Call Session Control Function), которая, в сущности, является SIP-сервером и реализует функции SIP-доступа (proxy), регистрации (registrar) и определения местоположения (location service), с отдельными специфическими адаптациями. В издании 3GPP Release 5 определена основная архитектура IMS, в которой используются различные типы узлов/функций, IMS-управление сессиями, SIP-профиль для применения в 3GPP, интерфейс между узлами / функциями, способ защиты IP-мультимедийных услуг и др. В версии 3GPP Release 6 определено дальнейшее развитие подсистемы IMS, фазы 2. А именно: IMS-способ взаимодействия между сетями с коммутацией каналов CS и IP-сетями, IMS-конференции, IMS-обмен сообщениями, присутствие, IMS-управление группами, дополнительные SIP-возможности, поддержка пакетной передачи речи в мобильной связи, названная “нажми и говори” (Push to Talk over Cellular), IMS срочные вызовы и др.

Главные технические спецификации, описывающие использование SIP в IMS:

• TS 23.228, IP Multimedia Subsystem (IMS); Stage 2 — IP мультимедийная подсистема, фаза 2;
• TS 24.229, IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 — IP-протокол управления мультимедийным вызовом, базирующийся на протоколе инициации сессии SIP и протоколе описания сессии SDP, фаза 3;
TS 29.163, Interworking between the IM CN subsystem and CS networks — Взаимодействие между подсистемой IM CN и сетями CS;
• TS 29.962, Signalling interworking between the 3GPP profile of the Session Initiation Protocol (SIP) and non-3GPP SIP usage — Сигнализация взаимодействия между протоколом инициации сессии профиля 3GPP и другим SIP-протоколом, не 3GPP-профиля;
• TS 29.847, Conferencing based on SIP, SDP and other protocols — Конференция, базированная на SIP, SDP и других протоколах; Functional models, information flows and protocol details — Функциональные модели, информационные потоки и детали протокола;
• TS 24.841, Presence based on SIP — Присутствие, базированное на SIP; Functional models, flows and protocol details — Функциональные модели, информационные потоки и детали протокола. Архитектура IMS, описанная стандартами 3GPP2, практически идентична архитектуре 3GPP. Однако в отличие от 3GPP, где коммуникацию между узлами коммутации мобильной связи MSC (Mobile Switching Centre) всё ещё определяет протокол BICC, в случае 3GPP2, базирующемся на Интернет-протоколе (All-IP), такое соединение обеспечивается протоколом SIP-T.

IMS-решение компании Ericsson представлено на рис. 11.