Обязательная регистрация ims что такое. Консолидация операторов и возможность предоставления конвергентных услуг. Необходимость сокращения расходов операторов

В поисках путей снижения издержек и увеличения доходов сервис-провайдеры все чаще задумываются о переводе голосовых услуг на рельсы VoIP. В IP-сети голосовые сервисы станут частью обширного комплекса коммуникационных сервисов реального времени, подчиняющихся общим принципам архитектуры "клиент-сервер". Среди таких сервисов можно назвать обмен мгновенными сообщениями (Instant Messaging, IM), мгновенную многоточечную связь (Push-to-Talk, PTT), NetMeeting?, а также сервисы VoIP третьего поколения беспроводной связи. Необходимо также отметить, что в процессе развития VoIP открывает дорогу услугам нового уровня, к которым относятся сервисы с учетом местоположения и присутствия в сети, мультимедийные сервисы, сотрудничество в реальном времени (collaboration) и многое другое.

Ускорить внедрение операторами новых услуг, как на сетях с коммутацией каналов использующих традиционные решения телефонии, так и на сетях с коммутацией пакетов использующих программные коммутаторы, призваны решения Lucent Accelerate? VoIP. Эти решения включают системы передачи голоса и данных следующего поколения, программное обеспечение и профессиональные услуги, которые необходимы операторам как мобильных, так и проводных сетей связи.

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

Отделение уровней транспорта и доступа от сервисного уровня (прозрачность доступа).

Управление сеансом связи, в ходе которого задействуются несколько сервисов связи реального времени.

Совместимость с имеющимися сервисами интеллектуальной сети (IN), к которым относятся: определение имени вызывающей стороны, бесплатный номер (800), переносимость локального номера, сервисы, соответствующие стандартам CAMEL, ANSI-41 и т.д.

Прозрачное взаимодействие с телефонными сетями (планы нумерации, сигнализация прохождения вызовов)

Конвергенция проводных и беспроводных сервисов.

Стандартизованные механизмы обмена пользовательской информацией между сервисами.

Стандартизованные механизмы аутентификации и биллинга конечных пользователей.

Стандартизованный, общий для всех сервисов графический пользовательский интерфейс.

Открытые стандартные интерфейсы и API для новых сервисов, разработанные сервис-провайдерами и третьими фирмами.

В настоящей статье рассматривается сервисная архитектура подсистемы IP-мультимедиа (IP Multimedia Subsystem, IMS), которая составляет фундамент решений Lucent Accelerate?. Решения Lucent Accelerate? позволяют реализовать сервисную интеллектуальность на всех уровнях проводных и беспроводных сетей, обеспечивая комплексный подход к внедрению VoIP.

Архитектура IMS

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

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

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

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

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

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

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

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

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

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

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

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

Сервер приложений телефонии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ни один абонент не откажется использовать коммуникационные сервисы в реальном времени и в органичном взаимодействии друг с другом. И сервис-провайдеры могут, организовав взаимодействие сервисов, предоставлять своим клиентам новые возможности. Приведем примеры. Абоненту в ходе длительного сеанса IM может понадобиться установить отдельный сеанс голосовой связи, используя телефонный справочник. Если абонент подключился к сессии PTT, все входящие звонки должны инициировать сообщение об ожидающем вызове. Как говорилось выше, сервисная архитектура IMS способна одновременно поддерживать множество различных коммуникационных приложений реального времени. Однако для предоставления такого рода смешанных услуг необходима организация дополнительного межсервисного взаимодействия. С этой целью Lucent предлагает ввести новый элемент? сервисный брокер, в функции которого входило бы сообщение данных о статусе и состоянии приложения другим приложениям. Как показано на рис. 2, сервисный брокер находится на уровне сеансного ядра и имеет интерфейсы ко всем взаимодействующим приложениям.

Планы Lucent по продуктам IMS

Обширный, полнофункциональный портфель продуктов Lucent Accelerate? основан на сервисной архитектуре и технологиях IMS. Как видно из рис. 3, составляющие его элементы используются на всех уровнях сервисной архитектуры IMS и во многих приложениях, о которых упоминалось выше. Сервисы, создаваемые партнерами Lucent, занимающимися разработкой приложений, встраиваются в открытую архитектуру IMS и могут использоваться сервис-провайдерами для ускоренного предоставления новых услуг.


Рисунок 3. Lucent Technologies IMS ? продукты и партнеры

Как показано на рис. 3, Lucent Softswitch (LSS) объединяет ряд функциональных элементов IMS: CSCF, TAS, MFRC, MGCF и IM-SSF. Кроме того LSS усиливает стандартную архитектуру IMS, выполняя функцию сигнального шлюза, которая обеспечивает прохождение сторонней сигнализации (H.323 или MGCP) в сервисную архитектуру IMS.

Дополнительную функциональность IMS обеспечивает портфель продуктов Lucent MiLIfe? Service Platform. Сервер медиаресурсов MiLife? Lucent Media Resource Server (LMRS) выступает в роли медиасервера. Абонентский регистр MiLIfe? Super Distributed Home Location Register (SDHLR) выполняет функции абонентской базы данных HSS, а шлюз MiLIfe? Intelligent Services Gateway (ISG) ? функции OSA-GW для взаимодействия с серверами приложений Parlay.

Медиашлюзы Lucent APX? и MaxTNT? , управляемые LSS, обеспечивают взаимодействие с ТфОП и поддержку телефонных соединений с УАТС.

Дополнительные телефонные услуги предоставляют серверы приложений Lucent, взаимодействуя с LSS и продуктами MiLife?. Среди этих серверов? система голосовых сообщений AnyPath?, единый веб-портал EBS (Enhanced Business Services), а также платформа предоплаты вызовов MiLife? SurePay?. Сервис-провайдеры могут сами разрабатывать приложения, пользуясь средой MiLife? Application Server (MAS).

Как уже говорилось, партнеры Lucent создают серверы приложений, которые взаимодействуют с продуктами Lucent в соответствии со стандартами IMS и поддерживают сервисы обмена мгновенными сообщениями, мгновенной многоточечной связи, виртуальные частные сети, а также действующие службы на базе SCP, такие как идентификатор вызывающей стороны, переносимость локального номера и службы 800.

Заключение

В поисках путей снижения издержек и увеличения доходов сервис-провайдеры все чаще задумываются о переводе голосовых услуг на рельсы VoIP, где коммуникационные сервисы реального времени могли бы бесшовно взаимодействовать друг с другом. Определенная стандартами архитектура подсистема IP Multimedia обеспечивает надежную реализацию всех требований, определенных в данной статье для создания новых конвергентных сервисов с поддержкой качества обслуживания. Эта архитектура лежит в основе решений Lucent Accelerate? VoIP, что обеспечивает использование интеллектуальных сервисов на всех функциональных уровнях проводных и беспроводных сетей. Более того, Lucent создает расширения архитектуры IMS, которые обеспечат ее развитие и поддержку широкополосных мультимедийных сервисов с помощью новых граничных сигнальных шлюзов. Вместе со своими партнерами Lucent предлагает решения, которые позволяют сервис-провайдерам повышать эффективность и ускоренными темпами выводить на рынок новые услуги.

С разрешения журнала "Мир Lucent".

Стандарт IP Multimedia Subsystem (IMS) является ключевым элементом при переходе к полномасштабным IP8услугам и конвергенции сетей. Этот стандарт обладает преимуществами IP, сохраняя при этом ожидаемый уровень качества для пользователей, расширяя сферы применения, поддерживая новые равноправные связи и мультимедийные возможности.

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

Направление развития рынка телекоммуникационных услуг следующего поколения во многом определяется тем фактом, что 3GPP (3rd Generation Partnership Project) приняла решение утвердить определенный IETF протокол Session Initiation Protocol (SIP) в качестве основы для сетей третьего поколения мобильной связи. Кроме того, 3GPP разработала спецификации IP Multimedia Subsystem (IMS), определяющие стандартную базовую архитектуру для услуг передачи голоса через интернет (VoIP) и мультимедийных сервисов.

Другие органы стандартизации, включая ETSI/TISPAN, в настоящее время также начинают использовать IMS. Этот стандарт поддерживает разнообразные типы доступа, в том числе GSM, WCDMA, CDMA2000, кабельный широкополосный доступ и WLAN.

Стандарт IP Multimedia Subsystem (IMS) определяет динамическую базовую архитектуру для услуг передачи голоса через интернет (Voice over IP, VoIP) и мультимедийных сервисов. Для пользователей услуги, основанные на IMS, обеспечивают связь между двумя абонентами и между абонентом и контент-ресурсом в различных режимах (включая передачу голоса, текста, изображений и видео или любую их комбинацию) с максимальной персонализацией и контролем.

Для операторов IMS предлагает концепцию многоуровневой архитектуры нового поколения, определяя горизонтальную архитектуру, в которой средства предоставления услуг и обычные функции могут использоваться неоднократно для различных приложений. Горизонтальная архитектура IMS также определяет совместимость и роуминг и обеспечивает контроль канала, биллинг и безопасность. Кроме того, она тесно интегрирована с существующими сетями передачи голоса и данных, и имеет множество ключевых преимуществ из области IT. Это делает IMS главным средством для слияния стационарных и мобильных сетей связи. Вот почему IMS станет оптимальным решением для предоставления мультимедийных услуг операторами стационарных и мобильных сетей.

Архитектура IMS

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

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

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

IMS включает в себя блок интерфейсов, SIP-прокси-серверов и обычных серверов, а также медиашлюзов (для подсоединения к сетям с отличным от IP протоколом). Многоуровневая архитектура IMS показана на рисунке.

Упрощенная схема многоуровневой архитектуры IMS

Итак, уровень услуг состоит из серверов приложений и контент-серверов для предоставления абонентам дополнительных услуг. Базовые средства предоставления услуг, как это определено стандартом IMS (например, управление присутствием или управление списками групп), реализованы в качестве услуг на сервере SIP-приложения.

Уровень управления включает в себя серверы управления сетью для обработки установления, изменения или отмены вызова или сеанса. Наиболее важной функцией в данном случае является CSCF (функция управления сеансом вызова). Данный уровень также включает полный набор функций поддержки, например, предоставления услуг, биллинга, эксплуатации и управления (О&М). Взаимодействие с сетями других операторов и/или прочими типами сетей осуществляется благодаря пограничным шлюзам.

На уровне связи и взаимодействия присутствуют маршрутизаторы и коммутаторы для магистральной сети и сети доступа.

Конвергенция сетей

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

IMS предлагает общую архитектуру для всех типов доступа (фиксированного широкополосного, WLAN, 2,5G, 3G), обеспечивая рост доходов за счет повышения качества услуг, увеличения эффективности передачи и поддержки внедрения новых мультимедийных услуг через различные сети доступа. Кроме того, эксплуатационные затраты уменьшаются благодаря упрощенному планированию и модернизации сетей, а также распределению сфер компетенции и разделению функций эксплуатации и технического обслуживания.

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

Стандарты на смену патентованным решениям

Операторы IMS также могут выбирать между использованием стандартизированных сервисных структур как части платформ предоставления услуг и созданием собственной сервисной структуры.

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

Недостатком отказа от стандартов является дороговизна разработки собственной системы. В этом случае все будет ограниченным: количество терминалов и их версий, круг разработчиков, привлеченных к проектированию, набор доступных услуг, совместимость с другими сетями и терминалами.

Альтернативой для операторов может стать использование стандартной архитектуры - IMS.

Функции и сервисы IMS

IMS упрощает создание и предоставление мультимедийных сервисов, базирующихся на общих средствах оказания услуг по типу "однократное создание - многократное использование". Эти средства предоставления услуг представляют собой общие "строительные" блоки многократного использования для создания сервисов. Средства оказания услуг, созданные для разнообразных приложений, могут становиться глобальными и автоматически включаться в новые приложения и услуги. Таких средств много, но основными из них являются управление присутствием и списками групп.

Управление присутствием

Благодаря средству оказания услуги присутствия можно информировать определенный круг пользователей о доступности и способах связи с членами данной группы. Это дает возможность пользователям "видеть" друг друга до установления соединения (активная адресная книга) или получать сообщения о том, что другие пользователи доступны.

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

Управление списками групп

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

Совместимость сервисов

Надо отметить, что IMS позволяет многократно использовать связи между операторами. Вместо того чтобы развивать различные связи и соглашения о взаимодействии для каждого сервиса, IMS обеспечивает установление и развитие связей между операторами для каждого сервиса.

Сегодня, если один пользователь желает получить доступ к сервису другого - например, проверить статус или местоположение, - маршрутизация к сервису этого другого пользователя будет специфической услугой и потребует запроса сервиса от оператора пользователя. Более того, для каждого сервиса должен существовать специфический межсетевой интерфейс, маршрутизация, точка доступа к сервису и средства обеспечения безопасности, а следовательно, и специфическое соглашение об услуге между операторами.

Если IMS функционирует, доступ к сервисам других пользователей является задачей сети IMS, общей для всех персональных сервисов IMS, как это показано на рисунке справа.

Услуги оператора, запрашивающего пользователя, не требуются для маршрутизации запроса. Межсетевой интерфейс между операторами действует в IMS, а общее сервисное согла-шение - между операторами IMS; маршрутизация, точка доступа к сервисной сети и средства безопасности могут использоваться неоднократно.

"Бесшовная" связь

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

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

Интеграция сервисов представляет собой возможность динамического изменения информационных средств, активизированных в ходе мультимедийного сеанса связи. Диапазон используемых типов информационных средств определяется только возможностями терминала пользователя. Таким образом IMS "интегрирует" в одном сеансе то, что сегодня представляет собой различные сервисы. Для пользователей применение единого сеанса означает то, что они могут работать в многозадачном режиме, то есть нет необходимости прерывать голосовой вызов (или переводить его в режим удержания), чтобы послать текстовое сообщение или видеоклип.

Взаимодействие сервисов - это возможность объединять их в пакеты, создавая новые возможности и удовлетворяя потребности пользователей. Например, пользователь может просматривать вэб-сайт и перейти к голосовому или видеовызову простым нажатием кнопки. Таким образом, сервисы взаимодействуют друг с другом, создавая для пользователя единое рабочее пространство.

Хотя мультимедийные сервисы на базе существующей технологии были доступны и раньше, всегда возникали сложности с развертыванием, высокой стоимостью и неэффективностью использования сетевых ресурсов. Компания Ericsson уверена, что высочайший технический уровень мультимедийной IP-технологии позволит предоставлять разнообразные сервисы, в том числе:

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

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

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

В мире проводной связи IMS не только способна предоставлять стандартизированные услуги VoIP, но и объединять, например, мультимедийные сервисы с IP-Centrex, или создавать усовершенствованные сервисы взаимодействия, подходящие как для малых/средних, так и для крупных предприятий.

Широкоизвестное приложение IMS: поддержка возможности push-to-talk по сотовой связи

Сотовая связь по принципу push-to-talk (Push-to-Talk over Cellular, PoC) является первой из многочисленных сфер применения IMS. В 2003 году ведущие поставщики услуг и операторы (в том числе Ericsson) объявили о завершении совместной разработки спецификации Push-to-Talk over Cellular, основанной на IP Multimedia Subsystem (IMS), как определено стандартами 3GPP и 3GPP2. Большую поддержку многих операторов и поставщиков услуг получила не только данная спецификация, но и РоС, предоставленная для ратификации в Open Mobile Alliance (ОМА). Open Mobile Alliance в настоящее время проводит работу по стандартизации, и учитывая тот факт, что в альянс входит более 350 представителей производителей, данная организация обеспечит преемственность стандартов и их функциональную совместимость.

Это должно сделать push-to-talk общедоступным сервисом, подобно SMS и MMS, за счет обеспечения "прозрачности" сети для конечных пользователей. Такая спецификация разработана для удовлетворения огромной потребности рынка в push-to-talk и IMS. Стандартизация ведет к расширению ассортимента типов и моделей терминалов за счет увеличения объемов производства у всех операторов, вовлеченных в процесс стандартизации.

РоС предлагает разнообразные сервисы для связи "абонент - абонент" и групповой связи, включая чаты, индивидуальные сигналы оповещения и управление присутствием. РоС работает только в среде с коммутацией пакетов и базируется на средствах оказания услуг IMS и общих функциях, как, например, управление группой, списком и присутствием, проведение конференц-связи, безопасность, биллинг и O&M.

Сервисы push-to-talk можно использовать в потребительском сегменте: оставаясь на связи с друзьями, планировать досуг, или общаться с членами семьи посредством нажатия кнопки. Эта услуга нацелена также на корпоративный сегмент, где она используется, в частности, для обмена информацией в рабочих группах - например, для находящегося на выезде специалиста IS/IT, которому необходимо связаться с коллегами для получения нужной информации.

Сервис push-to-talk с учетом соответствующего позиционирования и ценообразования может быть представлен как новая голосовая услуга в сегменте между голосовыми вызовами и сервисами текстовых сообщений типа SMS. Данный сервис является более быстродействующим по сравнению с обычными голосовыми вызовами и обеспечивает более простое групповое соединение. Также он, в отличие от SMS, кроме собственно сообщения, обеспечивает более быструю и эмоциональную связь между абонентами, а также мгновенную ответную реакцию.

Устройство типа портативной радиостанции для связи в мобильных сетях впервые с успехом было применено в США. Уже в середине девяностых годов мобильный оператор Nextel запустил региональный сервис, который к 2004 году превратился в общенациональную сеть с 12,3 миллионами абонентов. Nextel продемонстрировал рынку впечатляющие финансовые результаты наряду с очень высоким уровнем проникновения (>90%) сервисов типа портативной радиостанции, что побудило остальных игроков рынка к анализу возможностей создания конкурирующих сервисов.

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

Технология push-to-talk от компании Ericsson - Ericsson Instant Talk (EIT) - является комплексным решением, состоящим из трех основных компонентов: системы Ericsson IMS (IPMM), сервера приложений EIT и РоС-клиента на терминале пользователя.

Коммерческое обоснование IMS

Для конечных пользователей IMS обеспечивает связь между двумя абонентами и между абонентом и контент-ресурсом в различных режимах (включая голос, текст, изображения и видео или любую их комбинацию) с максимальной персонализацией и контролем.

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

Внедрение архитектуры IMS выгодно сегодня для операторов как стационарных, так и мобильных сетей. В перспективе IMS обеспечит безопасный переход к полномасштабной IP-архитектуре, которая будет удовлетворять потребности пользователей в новых усовершенствованных сервисах.

Используя IMS, операторы смогут сначала проверить возможности IP-мультимедиа, а затем принять соответствующие меры в отношении массового рынка мультимедийных IP-сервисов, в зависимости от рыночных и коммерческих потребностей.

Опираясь на концепцию горизонтальной архитектуры IMS, операторы смогут получить еще большую прибыль от многоуровневой архитектуры беспроводных и проводных сетей. Благодаря горизонтальной архитектуре с ее общими функциями многократного использования оператор может начать переход к полномасштабным IР-услугам.

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

Надо отметить, что IMS-сеть превосходит сети других типов по многим параметрам. Ключевым преимуществом IMS является то, что все перечисленные возможности реализуются на стандартизированной основе, обеспечивая таким образом функциональную совместимость между IMS-сетями и стационарными IP-сетями.

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

Изобретение относится к IP мультимедийной подсистеме (IMS), в частности к системе и способу для упрощения процесса регистрации пользователей в IMS. Техническим результатом является обеспечение IMS информацией о том, что является ли пользователь зарегистрированным при доступе с коммутацией каналов (CS) или доступе с коммутацией пакетов (PS). Указанный технический результат достигается тем, что в IMS подсистеме протокол канала управления IMS (ICCP) используется между абонентским устройством (UE) и функцией канала управления IMS (ICCF) и интерфейсом по протоколу инициирования сеанса (SIP) (между ICCF, функцией управления сеансами вызовов и сервером приложений), чтобы поддерживать индикатор доступа CS с использованием заголовка P-Access-Network-Information. Индикатор может использоваться посредством обслуживающей функции управления сеансами вызовов (S-CSCF) или сервером приложений (AS) в различных целях, таких как информация по решению маршрутизации, тарификации и оплате и присутствию. 4 н. и 10 з.п. ф-лы, 20 ил.

Рисунки к патенту РФ 2434364

Область техники, к которой относится изобретение

Изобретение относится к IP мультимедийной подсистеме (IMS). Более конкретно и не в качестве ограничения, настоящее изобретение направлено на систему и способ для упрощения процесса регистрации пользователей в IMS.

Уровень техники

Ниже приводится список аббревиатур, используемых в описании, а также их определения, которые должны применяться по всему описанию, если не указано иное.

Аббревиатуры

3GPP - Партнерский проект третьего поколения

ADS - выбор домена доступа

AS - сервер приложений

CAMEL - пользовательское приложение для усовершенствованной логики мобильной связи

CDR - запись данных вызова

CS - коммутация каналов

CSCF - функция управления сеансами вызовов

CSI - комбинация CS и IMS-услуги

IA - IMS адаптер

ICCF - функция управления коммутации каналов IMS

ICCP - протокол управления коммутации каналов IMS

ICS - централизованные IMS-услуги

IMPI - конфиденциальные идентификационные данные для IP мультимедийной подсистемы

IMS - IP мультимедийная подсистема

IMSI - международные идентификационные данные абонента мобильной связи

IP-CAN - сеть доступа с подключением по IP

ISC - управление IP мультимедийной подсистемой

ISUP - абонентская подсистема ISDN

MAP - подсистема мобильных приложений

MGCF - функция управления сетевым шлюзом

PS - с коммутацией пакетов

P-CSCF - прокси-функция управления сеансами вызовов

S-CSCF - обслуживающая функция управления сеансами вызовов

SIP - протокол инициирования сеанса

TAS - сервер телефонных приложений

UE - пользовательское оборудование

URL - унифицированный указатель ресурса

USSD - неструктурированные данные по дополнительным услугам

VCC - непрерывность речевых вызовов

WCDMA - широкополосный множественный доступ с кодовым разделением

Фиг. 1 иллюстрирует высокоуровневую блок-схему архитектуры 100 ICS. Централизованные IMS-услуги (ICS) являются предложенным рабочим элементом в Партнерском проекте третьего поколения (3GPP), чтобы сделать возможными IMS-услуги во множестве типов сетей доступа, таких как сеть 102 коммутации каналов (CS). Реализация услуг размещается в IMS 110, и CS-сеть 102 используется в качестве доступа к услугам в IMS 110.

По сравнению с 3GPP Версии 7, архитектура непрерывности речевых вызовов (VCC), функция управления IMS CS (ICCF) 106 вводится для того, чтобы обеспечивать возможность сигнализации, не поддерживаемой в рамках CS сигнализации (к примеру, ISUP), такой как IMS-регистрация, сигнализация в ходе вызова, дополнительная информация для сигнализации при установлении вызова (к примеру, SIP URL), чтобы эмулировать IMS-терминал в направлении IMS. Неструктурированные данные по дополнительным услугам (USSD) могут использоваться для того, чтобы транспортировать эту дополнительную сигнализацию, называемую ICCP (управление IMS CS) 104, в CS-сети.

В VCC согласно 3GPP Версии 7, пользователь VCC не является зарегистрированным в IMS при CS-доступе, и сервер телефонных приложений (TAS) 108 должен реализовывать дополнительные механизмы для того, чтобы предоставлять IMS-услуги пользователю. В качестве возможного решения, в 3GPP Версии 8, предлагается поддерживать IMS-регистрацию из UE 101 с помощью ICCP так, чтобы TAS 108 мог информироваться от S-CSCF по процедуре сторонней регистрации, что пользователь зарегистрирован в IMS. Обслуживающая CSCF - это функция управления сеансами вызовов для управления регистрацией пользовательского оборудования и маршрутизации в IP мультимедийной подсистеме. Другая CSCF, прокси-CSCF, является первой точкой контакта для пользовательского оборудования и управляет решениями по безопасности, верификации и политике. В настоящее время, нет процедуры, которая информирует IMS о том, является ли пользователь зарегистрированным при CS-доступе или при PS-доступе (это обусловлено тем, что ранее не было IMS-регистрации для CS-доступа). IMS может знать только то, что пользователь зарегистрирован в одном или более радиодоступов, при этом предполагается, что все доступы являются пакетными доступами. Доступ с коммутацией пакетов (PS) всегда предполагался в IMS.

Ввиду предположения, что доступ всегда является PS-доступом, имеются ситуации, которые не могут быть разрешены посредством механизма сторонней IMS-регистрации вплоть до 3GPP Версии 7. Например, оператор может захотеть реализовывать локальную политику при выборе контактного адреса S-CSCF, чтобы продвигать CS-доступ, а не PS-доступ; или наоборот. Оператор может захотеть различать плату за CS-доступ и PS-доступ и указывать это различие в IMS CDR. Кроме того, оператор может захотеть различать режим работы TAS в зависимости от того, является ли пользователь зарегистрированным при CS-доступе или при PS-доступе (к примеру, почтовый ящик "видео-в-видео" с переадресацией вызовов, если пользователь зарегистрирован в CS-доступе, где видео не может поддерживаться).

Было бы полезным иметь систему и способ для идентификации того, является ли пользователь зарегистрированным при CS или PS-доступе, которые преодолевают недостатки уровня техники. Настоящее изобретение предоставляет такую систему и способ.

Раскрытие изобретения

Настоящее изобретение предоставляет изменение SIP-интерфейса, к примеру, для ICCF, CSCF и AS, чтобы поддерживать индикатор CS-доступа в заголовке P-Access-Network-Information (Информация сети для P-доступа). Затрагиваемые узлы - это ICCF, S-CSCF и AS. Индикатор может использоваться посредством S-CSCF или AS в различных целях, таких как информация решения по маршрутизации, оплате и присутствию.

Таким образом, в одном аспекте, настоящее изобретение направлено на способ регистрации пользовательского оборудования (UE) в IP мультимедийной подсистеме (IMS) посредством отправки запроса на регистрацию в обслуживающую функцию управления сеансами вызовов (S-CSCF), при этом запрос на регистрацию включает в себя заголовок, содержащий информацию о типе доступа пользователя и контактах, связанных с типом доступа. Запрос на регистрацию пересылается ассоциированному IMS-серверу приложений, который отвечает на ICCF. S-CSCF использует вставленный заголовок запроса на регистрацию для того, чтобы реализовывать правила доступа согласно настройкам оператора или пользователя, при этом заголовок, включенный в запрос на регистрацию, является заголовком P-Access-Network-Information, который включает в себя контакты, связанные с доступом с коммутацией каналов.

Контактные адреса, связанные с доступом с коммутацией каналов в заголовке, размещаются в порядке использования перед обычным контактом доступа с коммутацией пакетов, и правила упорядочения, касающиеся обработки контактов, связанной с типом доступа, основаны на локальной политике в S-CSCF. Локальная политика в S-CSCF может зависеть от времени дня или профиля абонента.

В другом аспекте, настоящее изобретение направлено на систему для регистрации пользовательского оборудования (UE) в IP мультимедийной подсистеме (IMS), при этом система содержит средство для отправки запроса на регистрацию в обслуживающую функцию управления сеансами вызовов (S-CSCF), и запрос на регистрацию включает в себя заголовок, содержащий информацию о типе доступа пользователя и контакты, связанные с типом доступа. Система включает в себя средство для пересылки запроса на регистрацию ассоциированному IMS-серверу приложений и средство для отправки ответа регистрации на ICCF.

Предусмотрены средства, включенные в S-CSCF, для использования заголовка запроса на регистрацию, чтобы реализовывать правила доступа согласно настройкам оператора или пользователя, и заголовком, который включен в запрос на регистрацию, является заголовок P-Access-Network-Information, который включает в себя контакты, связанные с доступом с коммутацией каналов.

Контакты, связанные с доступом с коммутацией каналов в заголовке, могут быть размещены по порядку перед обычным контактом доступа с коммутацией пакетов, и правила упорядочения, касающиеся обработки контактов, связанной с типом доступа, основаны на локальной политике в S-CSCF, причем локальная политика в S-CSCF зависит от времени дня или профиля абонента.

Краткое описание чертежей

В следующем разделе изобретение описывается со ссылками на примерные варианты осуществления, проиллюстрированные на чертежах, на которых:

Фиг. 1 иллюстрирует высокоуровневую блок-схему архитектуры ICS;

Фиг. 2 иллюстрирует высокоуровневую схему последовательности сигналов доступа с коммутацией каналов при регистрации в соответствии с вариантом осуществления настоящего изобретения; и

Фиг. 3a, 3b и 3c иллюстрируют три ситуации, в которых зарегистрированное устройство идентифицируется в S-CSCF согласно вариантам осуществления настоящего изобретения;

Фиг. 4a-4d иллюстрируют ситуации, в которых упорядочение в S-CSCF изменяется в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 5a-5d иллюстрируют ситуации, в которых различные ответвляющиеся действия могут быть предприняты согласно варианту осуществления настоящего изобретения;

Фиг. 6a-6f иллюстрируют ситуации, касающиеся различных действий последовательной посылки вызова согласно варианту осуществления настоящего изобретения; и

Фиг. 7 иллюстрирует индикацию доступа с коммутацией каналов в сервер присутствия согласно варианту осуществления настоящего изобретения.

Осуществление изобретения

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

Параметр, ассоциированный с IMS, "P-Access-Network-Information", уже присутствует для того, чтобы доставлять касающуюся доступа информацию сети, но дополнительная информация, указывающая тип доступа (CS и PS), в настоящее время не включена в этот параметр. До появления ICS, PS-доступ являлся случаем по умолчанию. Заголовок P-Access-Network-Information описывается ниже для справки:

Фиг. 2 иллюстрирует высокоуровневую схему последовательности сигналов доступа с коммутацией каналов при регистрации в соответствии с вариантом осуществления настоящего изобретения. Заголовок P-Access-Network-Information расширяется в настоящем изобретении так, чтобы указывать тип доступа как CS, и вставляется посредством ICCF в ICCP запрос на регистрацию и доставляется в S-CSCF и сервер приложений (AS). Сервер приложений может быть сервером телефонных приложений или AS непрерывности речевых вызовов или любым другим AS (к примеру, сервером присутствия), который использует состояние регистрации для того, чтобы выполнять свое приложение «поверх» интерфейса управления IP мультимедийной подсистемой (ISC). S-CSCF также может использовать P-Access-Network-Information для того, чтобы реализовывать правила согласно настройкам оператора или пользователя, чтобы помещать контакты, связанные с CS-доступом, в порядке, отличающемся от PS-доступа.

Фиг. 3a, 3b и 3c иллюстрируют три ситуации, в которых зарегистрированное устройство идентифицируется в S-CSCF согласно вариантам осуществления настоящего изобретения. Различение между UE-устройствами с поддержкой CS и PS выполняется с использованием информации, включенной в регистрационное сообщение, предоставляемое ICCF с помощью ICCP. Фиг. 3a иллюстрирует использование «Device ID» (Идентификатор устройства) из UE в ходе регистрации как в CS, так и в PS. Это новый параметр в запросе на регистрацию ICCP и в сообщении SIP REGISTER, и S-CSCF должна хранить информацию Device ID с IP-адресом контакта. Например, если зарегистрированы два устройства, одно из которых является UE с CS- и PS-доступом, а другое - UE, являющимся PC только с PS-доступом, информация, сохраненная в S-CSCF, выглядит следующим образом:

Public User ID --- Contact IP1 --- CS access --- Device ID1

Contact IP2 --- PS access --- Device ID1

Contact IP3 --- PS access --- Device ID2

Примечание 1 - IP1 - это IP-адрес ICCF в случае CS-доступа.

Фиг. 3b иллюстрирует включение, по меньшей мере, одного "альтернативного контакта" из UE в ходе CS-регистрации. В запросе на регистрацию ICCP и в сообщении REGISTER, S-CSCF должна хранить информацию альтернативного контакта с IP-адресом контакта для CS-доступа. S-CSCF может идентифицировать, что две регистрации принадлежат одному совпадающему контактному адресу устройства и альтернативному контактному адресу. Например, если два устройства зарегистрированы, одно из которых является UE с CS- и PS-доступом, а другое - UE, являющимся PC только с PS-доступом, информация, сохраненная в S-CSCF, выглядит следующим образом:

Public User ID --- Contact IP1 - CS access - Alt contact IP2

Contact IP2 - PS access

Contact IP3 - PS access

Примечание - IP1 - это IP-адрес ICCF в случае CS-доступа.

Фиг. 3c иллюстрирует использование конфиденциальных идентификационных данных для IP мультимедийной подсистемы (IMPI) для того, чтобы идентифицировать устройство. IMPI могут быть извлечены из IMSI, доставленного в запросе на регистрацию ICCP (сообщении MAP USSD), и могут быть заполнены в существующем заголовке Authorization (Авторизация) сообщения REGISTER. S-CSCF должна хранить информацию IMPI с IP-адресом контакта, который должен использоваться для решения по маршрутизации. Например, если два устройства зарегистрированы, одно из которых является UE с CS- и PS-доступом, а другое - UE, являющимся PC только с PS-доступом, информация, сохраненная в S-CSCF, выглядит следующим образом:

Public User ID --- Contact IP1 - CS access - IMPI1

Contact IP2 - PS access - IMPI1

Contact IP3 - PS access - IMPI1

Примечание 1 - IP1 - это IP-адрес ICCF в случае CS-доступа. Примечание 2 - IMPI1 извлекается из IMSI, и IMPI2 сохраняется в IMSI, присоединенном к PC.

Фиг. 4a-4d иллюстрируют ситуации, в которых упорядочение в S-CSCF изменяется в соответствии с вариантом осуществления настоящего изобретения. S-CSCF также может использовать P-Access-Network-Information для того, чтобы реализовывать правила согласно настройкам оператора или пользователя, чтобы помещать контакты, связанные с CS-доступом, в порядке, отличающемся от типичного PS-доступа.

В настоящее время обработка контакта основана только на q-значении от пользователя. Параметр q используется для того, чтобы указывать приоритетное значение контактов для маршрутизации от пользователя. Настоящее изобретение предусматривает правило упорядочения, которое может быть основано на локальной политике в S-CSCF и может быть различным, к примеру, в зависимости от времени дня или для каждого подписчика. Возможные упорядочения в S-CSCF могут включать в себя:

Сначала проба контакта CS-доступа, а затем проба PS-доступа, если нет отклика (Фиг. 4a);

Сначала проба контакта PS-доступа, а затем проба CS-доступа, если нет отклика (Фиг. 4b);

Проба контакта CS-доступа только в том случае, если контакты как с CS-доступом, так и с PS-доступом зарегистрированы (если зарегистрирован только один контакт, проба зарегистрированного контакта) (Фиг. 4c); и альтернативно,

Проба контакта PS-доступа только в том случае, если контакты как с CS-доступом, так и с PS-доступом зарегистрированы (если зарегистрирован только один контакт, проба зарегистрированного контакта) (Фиг. 4d). Эти варианты должны дополнять обработку контактов в S-CSCF, которая в настоящее время основана только на q-значении от пользователя.

Фиг. 5a-5d иллюстрируют ситуации, в которых различные ответвляющиеся действия могут быть предприняты согласно варианту осуществления настоящего изобретения. S-CSCF также может использовать P-Access-Network-Information для того, чтобы реализовывать правила, чтобы подавлять разветвление к контактам для одного устройства, зарегистрированного по нескольким доступам. Правило разветвления может быть основано на локальной политике в S-CSCF и может быть различным, к примеру, в зависимости от времени дня. Возможные правила разветвления включают в себя:

Ветвление только к контакту с PS-доступом, если пользователь зарегистрирован как в CS-доступе, так и в PS-доступе (Фиг. 5a);

Ветвление только к контакту с CS-доступом, если пользователь зарегистрирован как в CS-доступе, так и в PS-доступе (Фиг. 5b);

Сначала ветвление к контакту с PS-доступом, а затем к контакту CS (Фиг. 5c); и

Сначала ветвление к контакту с CS-доступом, а затем ветвление к контакту PS (Фиг. 5d). Правило также может быть комбинировано с последовательной посылкой вызова так, что:

Ветвление только к контакту с PS-доступом, если пользователь зарегистрирован как в CS-доступе, так и в PS-доступе. Если ни одно из разветвленных устройств не откликается, запрашивание контакта CS-доступа, и

Ветвление только к контакту с CS-доступом, если пользователь зарегистрирован как в CS-доступе, так и в PS-доступе. Если ни одно из разветвленных устройств не откликается, запрашивание контакта PS-доступа.

Правило разветвления может быть основано на локальной политике в S-CSCF и может быть различным, к примеру, в зависимости от времени дня.

Фиг. 6a-6f иллюстрируют ситуации, касающиеся различных действий последовательной посылки вызова согласно варианту осуществления настоящего изобретения. S-CSCF может использовать P-Access-Network-Information для того, чтобы последовательно вызывать контакты способом, которым контакты, связанные с одним устройством, но с различными доступами, запрашиваются последовательно перед (или после) попыткой звонить контактам, указывающим на другие устройства. Другими словами, возможные правила последовательной посылки вызова включают в себя:

1) При последовательной посылке вызова различным устройствам, сначала проба контакта PS-доступа, если пользователь зарегистрирован как в CS-доступе, так и в PS-доступе. Если нет отклика:

Проба CS-доступа до пробы другого устройства (Фиг. 6a);

Проба контакта CS-доступа после того, как на все последовательные посылки вызовов в другие устройства нет ответа (Фиг. 6b); и

Не включать контакт CS-доступа (Фиг. 6c);

2) При последовательной посылке вызова различным устройствам, сначала проба контакта CS-доступа, если пользователь зарегистрирован как в CS-доступе, так и в PS-доступе. Если нет отклика:

Проба PS-доступа до запрашивания другого устройства (Фиг. 6d);

Проба контакта PS-доступа после отсутствия ответа на все последовательные посылки вызовов в другие устройства (Фиг. 6e); и

Не включение контакта P-доступа (Фиг. 6c);

Правило последовательной посылки вызова может быть основано на локальной политике в S-CSCF и может быть различным, к примеру, в зависимости от времени дня.

Эти параметры могут быть включены в P-Access-Network-Information или могут быть включены как новый параметр заголовка SIP. AS может использовать контактную информацию для того, чтобы различать между CS-доступом и PS-доступом для выбора домена доступа (ADS).

В VCC 3GPP Версии 7, сервер приложений VCC реализует ADS. Когда ADS выбирает PS-доступ, вызов маршрутизируется в зарегистрированный контакт в PS-доступе. Когда ADS выбирает CS-доступ, поскольку S-CSCF не имеет зарегистрированного контакта в CS-доступе, ADS пересылает вызов с использованием подходящего маршрутного номера, чтобы иметь возможность маршрутизировать в CS-доступ (называемый маршрутным номером CS), чтобы обходить обработку контактов в S-CSCF. AS VCC может узнавать состояние регистрации PS с использованием механизма сторонней регистрации, когда пользователь зарегистрирован в PS-доступе, но должен реализовывать конкретный отличный от IMS механизм, чтобы узнавать, что пользователь зарегистрирован в CS-доступе. Сторонняя IMS-регистрация также может использоваться для того, чтобы определять состояние регистрации в CS-доступе, что должно упрощать реализацию ADS.

AS и S-CSCF могут выдавать CDR, включающие в себя P-Access-Network-Information так, чтобы оператор мог различать схему тарификации и оплаты для связи по PS-доступу и связи по CS-доступу. P-Access-network-Information также может быть включен в запрос INVITE, когда сеанс устанавливается от ICCF (не только сообщение REGISTER, когда пользователь регистрируется в CS-доступе), чтобы указывать, что связь осуществляется по CS-доступу.

Фиг. 7 иллюстрирует указание доступа с коммутацией каналов в сервер присутствия согласно варианту осуществления настоящего изобретения. Сервер присутствия, которым является SIP AS, также может принимать P-Access-Network-Information в ходе процедур сторонней регистрации, чтобы определять то, находится ли пользователь в PS-доступе или в CS-доступе, и может предоставлять оптимальную информацию наблюдателям. "Наблюдатель" в этом контексте - это пользователь, подписанный на информацию присутствия пользователя ICS, и он "наблюдает" состояние присутствия пользователя ICS. Наблюдатель использует состояние присутствия для того, чтобы определять, какой доступ должен использоваться для того, чтобы инициировать мультимедийную связь, так что если пользователь зарегистрирован в PS-доступе, наблюдатель может инициировать мультимедийный вызов по PS-доступу (к примеру, речь и видео по PS-доступу). Такой наблюдатель может постоянно размещаться в UE или в сетевом узле.

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

ФОРМУЛА ИЗОБРЕТЕНИЯ

1. Способ регистрации пользовательского оборудования (UE) в IP мультимедийной подсистеме (IMS), содержащий этапы, на которых: отправляют запрос на регистрацию UE в IMS; определяют, исходит ли запрос на регистрацию из сети доступа с коммутацией каналов; в ответ на определение, что запрос на регистрацию исходит из сети с коммутацией каналов, вставляют заголовок, содержащий информацию, касающуюся сети доступа с коммутацией каналов, в запрос на регистрацию и пересылают запрос на регистрацию в IMS и ассоциированный IMS-сервер приложений.

2. Способ по п.1, дополнительно содержащий обслуживающую функцию управления сеансами вызовов (S-CSCF), использующую информацию во вставленном заголовке для реализации зависимых от доступа правил согласно настройкам оператора или пользователя IMS.

3. Способ по п.1, в котором заголовок вставляется в запрос на регистрацию посредством функции управления IMS CS и заголовок является заголовком P-Access-Network-Information, который включает в себя контакты, связанные с доступом с коммутацией каналов.

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

5. Способ по п.1, в котором идентификация пользовательского оборудования выполняется посредством использования информации, включенной в ICCP запрос на регистрацию, причем информация включает в себя идентификатор устройства (Device ID), альтернативный контакт или конфиденциальные идентификационные данные для IP мультимедийной подсистемы.

6. Способ по п.5, в котором идентификатор устройства представляет собой IP-адрес ICCF, альтернативный контакт представляет собой информацию, сохраненную S-CSCF с IP-адресом контакта, а конфиденциальные идентификационные данные для IP мультимедийной подсистемы извлекаются из IMSI UE.

7. Система для регистрации пользовательского оборудования (UE) в IP мультимедийной подсистеме (IMS), содержащая: UE для отправки запроса на регистрацию по протоколу управления IMS CS (ICCP) в IMS; средство, связанное с IMS, для определения того, исходит ли запрос на регистрацию из сети доступа с коммутацией каналов; функцию для вставки заголовка, содержащего информацию, касающуюся типа доступа с коммутацией каналов, в запрос на регистрацию, если определено, что запрос на регистрацию исходит из сети с коммутацией каналов; и логическое средство для пересылки запроса на регистрацию в IMS и ассоциированный IMS-сервер приложений.

8. Система по п.7, дополнительно содержащая обслуживающую функцию управления сеансами вызовов (S-CSCF) для использования информации во вставленном заголовке для реализации правил доступа согласно настройкам оператора или пользователя IMS.

9. Система по п.7, в которой заголовок вставляется в запрос на регистрацию посредством функции управления IMS CS (ICCF) и заголовок является заголовком P-Access-Network-Information, который включает в себя контакты, связанные с доступом с коммутацией каналов.

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

11. Система по п.7, в которой идентификация пользовательского оборудования осуществляется посредством использования информации, включенной в ICCP запрос на регистрацию, причем информация включает в себя идентификатор устройства (Device ID), альтернативный контакт или конфиденциальные идентификационные данные для IP мультимедийной подсистемы.

12. Система по п.11, в которой идентификатор устройства представляет собой IP-адрес ICCF, альтернативный контакт представляет собой информацию, сохраненную S-CSCF с IP-адресом контакта, а конфиденциальные идентификационные данные для IP мультимедийной подсистемы извлекаются из IMSI UE.

13. Функция управления для регистрации пользовательского оборудования (UE) в IP мультимедийной подсистеме (IMS), причем функция управления содержит: средство для приема от UE запроса на регистрацию в IMS по протоколу управления IMS CS (ICCP); средство, связанное с IMS, для определения того, исходит ли запрос на регистрацию из сети доступа с коммутацией каналов; функцию для вставки заголовка, содержащего информацию, касающуюся типа доступа с коммутацией каналов, в запрос на регистрацию, если определено, что запрос на регистрацию исходит из сети с коммутацией каналов; и логическое средство для пересылки запроса на регистрацию в IMS и ассоциированный IMS-сервер приложений.

14. Обслуживающая функция управления сеансами вызовов (S-CSCF) в системе для регистрации пользовательского оборудования (UE) в IP мультимедийной подсистеме (IMS), причем система содержит средство для приема от UE запроса на регистрацию в IMS по протоколу управления IMS CS (ICCP), средство, связанное с IMS, для определения того, исходит ли запрос на регистрацию из сети доступа с коммутацией каналов; функцию для вставки заголовка, содержащего информацию, касающуюся типа доступа с коммутацией каналов, в запрос на регистрацию, если определено, что запрос на регистрацию исходит из сети с коммутацией каналов; и логическое средство для пересылки запроса на регистрацию в IMS и ассоциированный IMS-сервер приложений; причем S-CSCF содержит средство для использования информации во вставленном заголовке для реализации правил доступа согласно настройкам оператора или пользователя IMS.

На 2013 год одно из важнейших приложений IMS – это поддержка полноценной технологии голосовой связи в сетях LTE (VoLTE). Другим ключевым драйвером рынка IMS является возможность создания операторами конкурентных сервисов в ответ на угрозу со стороны сторонних компаний, активно разворачивающих собственные мультимедийные сервисы поверх операторских сетей.

Определение IMS

IMS представляет собой программно-аппаратный комплекс, который является ключевым компонентом практически всех IP-сетей следующего поколения (Next Generation Network, NGN), поддерживающих SIP-телефония (SIP, Session Initiation Protocol) -приложения, и предназначается для обеспечения стандартизации мультимедийных сервисов во всех взаимосвязанных сетях. Благодаря универсальной архитектуре одна и та же IMS-платформа может быть использована для приложений и услуг в мобильных сетях всех поколений (2G, 3G, 4G), а также в фиксированных сетях.

Причем именно в сетях фиксированной связи концепция IMS появилась первоначально - как инструмент сокращения числа сетей крупных операторов (и, соответственно, расходов) за счет миграции на IP (масштабный проект BT Group (ранее British Telecom) в середине 2000-х). Позже, по мере стремительного старта LTE, основной интерес к IMS сместился в сторону поддержки голосовых (VoLTE) и «расширенных» мультимедийных услуг (RCS).

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

Одним из важнейших драйверов внедрения IMS является необходимость поддержки голосовых услуг в сетях LTE (VoLTE).

Преимущества IMS

Основные преимущества IMS:

  • Обеспечение взаимодействия разного типа сетей
  • Возможность разработки и быстрого внедрения новых услуг, включая VoLTE
  • Обеспечение качества оказания услуг (QoS)
  • Точное выставление счетов
  • Снижение затрат на эксплуатацию
  • Масштабируемость решений

Предпосылки внедрения IMS

Консолидация операторов и возможность предоставления конвергентных услуг

Конкуренция между существующими операторами мобильной связи остается очень высокой, на рынке происходят активные процессы слияний и поглощений (M&A). Нередко консолидируются компании - провайдеры разного типа услуг (фиксированная и мобильная телефония, мобильная телефония и кабельное телевидение и т.п.). Технология IMS помогает им объединять все типы сетей в одну, реализовать комплекс услуг и сервисов, сочетающий в себе возможности мобильной и фиксированной связи на базе одной платформы (конвергентные услуги) и обеспечить операторам рост ARPU и увеличение доходов.

Угроза со стороны ОТТ-сервисов

Сторонние поставщики текстовых, голосовых и видео-приложений (OTT -провайдеры) каннибализируют традиционные услуги мобильных операторов (голос и SMS), которые приносят последним основную часть доходов. С развитием технологий (переход на 4G) OTT-провайдеры увеличивают привлекательность своих сервисов, например, обеспечивают поддержку голоса и видео высокого разрешения (HD), что усугубляет проблему.

Необходимость сокращения расходов операторов

Очевидной тенденцией мирового рынка телекоммуникаций является рост капитальных затрат операторов.

Считается, что IMS в среднесрочной и долгосрочной перспективе позволит операторам сократить капитальные (CAPEX) и операционные (OPEX) затраты за счет использования единой IP-сети и открытой IMS-архитектуры. Кроме того, операторы смогут быстро и с малыми затратами выводить на рынок новые услуги. Однако на начальном этапе внедрения IMS операторам, очевидно, придется увеличить свои затраты.

Появление и развитие сетей LTE

Резкий рост потребления мобильного трафика данных, острая конкуренция и высокий спрос на услуги мобильного ШПД требует внедрения дорогостоящих технологий LTE и LTE Advanced. Развитие сетей 4G, в свою очередь, стимулирует операторов к внедрению технологии IMS, поскольку она дает возможность внедрять голосовые услуги на сетях LTE (VoLTE) и другие сервисы.

Архитектура IMS

Архитектура IMS обычно делится на три горизонтальных уровня:

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

Распространение IMS в России

В 2004-2005 гг. в России прошли первые демонстрации возможностей IMS (компании Siemens и Ericsson).

В 2006 г. Siemens открыл демо-центр IMS в Санкт-Петербурге, в котором осуществлялась демонстрация различных сервисов:

  • Call&Share,
  • Push And Talk Over Cellular,
  • Mobile Presence Manager,
  • Group Management,
  • Instant Messages Center и др.

В 2009 г. компания МГТС планировала внедрять IMS и завершить проект на аналоговом сегменте в 2011 г., однако из-за кризиса проект был реализован лишь частично. В частности, в 2010 г. на цифровой формат переведена лишь часть аналоговых АТС, а также установлено ядро сети. В начале 2012 г. МГТС запустила в тестовую эксплуатацию первый корпоративный сервис на базе IMS, в коммерцию сервис планировалось запустить в марте 2012 г. Первой услугой стал масшабируемый сервис IP-Centrex.

Ранее, в 2011 г. макрорегиональный филиал «Юг» ОАО «Ростелеком » использовал решение Alcatel-Lucent IMS для перевода существующей фиксированной сети на IP-архитектуру с поддержкой технологии VoIP и других современных сервисов.

Кроме того, в августе 2012 г. макрорегиональный фитлиал «Урал» ОАО «Ростелеком» проводил запрос котировок на право заключения договора по проекту «Развитие платформы разработки и доставки услуг и элементов IMS ядра».

Мировой рынок оборудования IMS: основные тренды и прогнозы

На рынке готовых IMS-систем на 2012 год действуют 7 крупнейших вендоров.

IMS (IP Multimedia Subsystem) – спецификация передачи мультимедийного содержимого в сетях электросвязи на основе протокола IP. Ее авторство принадлежит международному партнерству 3-d Generation Partnership Project (3GPP), объединившему European Telecommunications Standardization Institute (ETSI) и несколько национальных организаций стандартизации. IMS изначально разрабатывалась применительно к построению мобильных сетей 3-го поколения на базе протокола IP. В дальнейшем концепция была принята комитетом ETSI-TISPAN, усилия которого были направлены на спецификацию протоколов и интерфейсов, необходимых для поддержки и реализации широкого спектра услуг в стационарных сетях с использованием стека протоколов IP.
В настоящее время архитектура IMS рассматривается многими операторами и сервис-провайдерами, а также поставщиками оборудования как возможное решение для построения сетей следующего поколения и как основа конвергенции мобильных и стационарных сетей на платформе IP.
Принцип, на котором строится концепция IMS, состоит в том, что доставка любой услуги никаким образом не соотносится с коммуникационной инфраструктурой (за исключением ограничений по пропускной способности). Воплощением этого принципа является многоуровневый подход, используемый при построении IMS. Он позволяет реализовать независимый от технологии доступа открытый механизм доставки услуг, который дает возможность задействовать в сети приложения сторонних поставщиков услуг.
В Табл. 1 приведен перечень всех интерфейсов подсистемы IMS (включая интерфейсы взаимодействия с сетью доступа LTE), а на Рис. 1 показана общая архитектура сети.

Наименование

Объекты

Протокол

LTE user/control plane

HSS – S-CSCF/I-CSCF

SLF – S-CSCF/I-CSCF

eMSS – S-CSCF/I-CSCF

P-GW – IMS-AGW / MRFP /

CSCF/BGCF – IBCF

Interface to OCS

Interface to CDF

CGF – billing system

Рис.1 (архитектура сети IMS):

Рассмотрим базовые элементы более подробно.

1. Call Session Control Function (CSCF) – функция управления сеансом связи

Существуют 4 различных типа CSCF – прокси CSCF (proxy CSCF – P-CSCF), обслуживающий CSCF (serving CSCF – S-CSCF), запрашивающий CSCF (interrogating CSCF – I-CSCF) и CSCF экстренных служб (emergency CSCF – E-CSCF).

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

Кроме того, все CSCF могут генерировать тарификационные данные и направлять их в функции offline тарификации.

a) Proxy Call Session Control Function (P-CSCF)

P-CSCF – является точкой входа пользователей в IMS. Весь сигнальный IMS трафик абонентский терминал (UE) направляет на P-CSCF. Аналогично весь сигнальный трафик, генерируемый сетью в направлении к UE – посылается через P-CSCF.

Существуют 5 уникальных задач, выполняемых P-CSCF:

  • SIP компрессия,

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

  • Контроль целостности и защита конфиденциальности SIP сигнализации посредством использования IPSec или TLS.
  • Взаимодействие с PCRF.
  • Управление NAT (функционал SIP ALG – application level gateway).

Учитывая, что во многих сетях связи абонентские терминалы (UE) располагаются за NAT-ом, который модифицирует на сетевом уровне IP/port информацию всех пакетов, проходящих через него, возникает проблема, обусловленная тем, что классический тип NAT-ирования не принимает во внимание IP информацию на SIP и SDR уровнях. Действительно всеобъемлющий IMS доступ (возможность UE взаимодействовать с P-CSCF независимо от среды доступа) требует, чтобы IP информация в SIP/SDP и user plane соответствовала информации на сетевом (IP) уровне (из публичного пула IP адресации). Для модификации IP на уровне user plane P-CSCF управляет шлюзом сети доступа, который обеспечивает модификацию IP на уровне user plane.

  • Обнаружение экстренного вызова.

Задача P-CSCF в этом случае – детектирование запроса экстренного вызова и выбор E-CSCF для обработки данного экстренного вызова.

b) Interrogating Call Session Control Function (I-CSCF)

I-CSCF является точкой в сети оператора для всех входящих соединений к абонентам данного оператора. Основная задача, выполняемая I-CSCF – назначение S-CSCF, основываясь на данных, полученных из HSS.

Назначение S-CSCF происходит при регистрации пользователя или в ситуации, когда незарегистрированный пользователь получает SIP request к сервису, относящемуся к незарегистрированному состоянию (например, voice mail).

c) Serving Call Session Control Function (S-CSCF)

S-CSCF является центральной точкой IMS. Он обеспечивает выполнение процедуры регистрации, принятие решение о маршрутизации, управление машиной состояний сессии, хранение профиля пользователя.

Когда пользователь посылает запрос на регистрацию, он в конечном итоге маршрутизируется к S-CSCF, который инициирует процедуру аутентификации и загружает профиль пользователя из HSS. Получив и верифицировав данные, S-CSCF подтверждает регистрацию, после чего пользователь может генерировать и принимать IMS запросы.

S-CSCF использует информацию, содержащуюся в пользовательском профиле, для принятия решения – когда и какую AS подключать при получении от пользователя SIP запроса. Кроме того, пользовательский профиль может содержать инструкции о типе медиа политик, которые S-CSCF должен применить. Например, он может индицировать, что пользователю доступны только аудио компоненты, при этом видео компоненты не доступны.

После получения S-CSCF запроса исходящей (UE-originated) или входящей (UE-terminated) сессии S-CSCF отвечает за принятие решений о его дальнейшей маршрутизации. Например, при получении запроса исходящей сессии (UE-originated) S-CSCF принимает решение – требуется ли ему подключать AS перед дельнейшей маршрутизацией запроса. После взаимодействия с AS S-CSCF либо продолжит сессию в IMS домене, либо переправит ее в другой домен (CS или IMS другого оператора). Если UE использует MSISDN для адресации вызываемой стороны, то S-CSCF преобразует MISISDN в SIP URI формат перед дальнейшей пересылкой, т.к. IMS не маршрутизирует запросы, основываясь на MSISDN номерах. Аналогично S-CSCF принимает все запросы, которые будут терминироваться в UE. Несмотря на то, что S-CSCF знает IP адрес UE (после процедуры регистрации) он маршрутизирует все запросы только через P-CSCF, т.к. P-CSCF может применять политики безопасности доступа.

Дополнительно S-CSCF может послать тарификационную информацию в OCS для обеспечения on-line тарификации.

d) Emergency Call Session Control Function (E-CSCF)

E-CSCF – это выделенная функциональность для обработки экстренных запросов – вызов полиции, пожарной бригады, скорой помощи.

Основная задача E-CSCF – выбрать соответствующий центр экстренных служб (public safety answering point – PSAP), в который должен быть перенаправлен поступивший запрос. Как правило, в качестве критерия выбора PSAP выступает местоположение пользователя и тип вызываемой службы.

2. Серверы приложений (Application Server – AS)

Строго говоря, серверы приложений (Application Server – AS) предоставляют услуги с добавленной стоимостью (value-added multimedia services) и не являются объектами IMS, т.к. располагаются в модели взаимодействия на вышележащем уровне. AS размещаются либо у оператора в домашней сети пользователя, либо у сервисного провайдера. Основные функции AS:

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

Предоставляемые услуги не ограничиваются только чистыми SIP сервисами. Оператор может предоставлять в т.ч. CAMEL (customized applications for mobile network enhanced logic) и OSA (open service architecture) сервисы для своих IMS абонентов в соответствии с 3GPP TS 23.228.

Таким образом, под AS будем понимать SIP AS, OSA service capability server (SCS) и CAMEL IP multimedia service switching function (IM-SSF).

С точки зрения S-CSCF элементы SIP AS, OSA SCS и IM-SSF представляют собой однотипные модули. Поскольку пользователь может иметь несколько сервисов, то может существовать и несколько AS в профиле каждого пользователя. В одну сессию может быть вовлечен один или несколько AS. Для примера, оператор может иметь одну AS для предоставления голосовых supplementary services (например, услуга переадресации всех входящих голосовых вызовов с 17:00 до 19:00 на голосовую почту) и другую AS для предоставления услуги voice call continuity (handover VoLTE в 2G/3G CS call).

3. Контролер и Процессор мультимедийных ресурсов (Media Resource Function Controller – MRFC, Media Resource Function Processor – MRFP)

MRFC и MRFP обеспечивают предоставление таких сервисов, как конференц-связь, проигрывание голосовых сообщений (анноунсемент), транскодирование медиа потоков. MRFC – обрабатывает SIP сигнализацию к/от S-CSCF/AS и управляет MRFP. MRFP - предоставляет user-plane ресурсы в соответствии с командами, полученными от MRFC:

  • смешивание медиапотоков (для multiple parties);
  • генерирование голосовых сообщений (анноунсемент);
  • обработка медиа потока (транскодирование, анализ,...)

Для направления вызова в домен с коммутацией каналов (CS домен) S-CSCF пересылает SIP запрос к BGCF, который осуществляет выбор соответствующего CS домена. При этом CS домен может быть выбран как на текущем узле (в соответствии с местонахождением пользователя, совершившего вызов), так и в другой сети. Если CS домен выбирается в другой сети – BGCF направляет запрос BGCF данной сети. Далее от BGCF запрос направляется в MGCF. Описанная опция позволяет маршрутизировать сигнальный и медиа поток по сети IMS максимально близко к вызываемому абоненту.

Когда SIP запрос достигает MGCF он выполняет преобразование протоколов (SIP протокол с одной стороны и ISDN user part – ISUP с другой) после чего – посылает конвертированный сообщение в SGW CS домена. SGW выполняет двухстороннее преобразование транспортного уровня сигнализации (SIGTRAN IP/SCTP/MxUA с одной стороны и SS7 MTP с другой стороны). SGW не обрабатывает уровень приложений (application level) сигнализации (ISUP). На Рис. 2 SGW является частью IM-MGW.

MGCF также осуществляет управление IM-MGW. IM-MGW обеспечивает user-plane линк между IMS и CS доменами. Он терминирует TDM каналы CS домена с одной стороны и медиа поток IMS домена с другой; выполняет их преобразование, транскодирование (при необходимости) и обработку пользовательской сигнализации.

В дополнение IM-MGW может генерировать тональные сигналы и анноунсементы пользователям в CS домене.

Сигнализация, относящаяся к входящим вызовам из CS домена (ISUP) в направлении к IMS пользователям направляется в MGCF, где выполняется ее преобразование в SIP запросы, которые далее направляются в I-CSCF для терминирования.

IP short message gateway (IP-SM-GW) соединяет наиболее распространенную технологию мобильного обмена сообщениями SMS с IMS мессажингом. Когда SMS посылается к IMS пользователю – SMS маршрутизируется по сети сигнализации SS7 к IP-SM-GW, который помещает полученную SMS в качестве контента специального типа в SIP MESSAGE и направляет его в S-CSCF для дальнейшей маршрутизации. Это позволяет доставлять SMS сообщения пользователям, которые зарегистрированы не в 3GPP мобильных IP сетях (Wi-Fi, WiMAX), а также может рассматриваться как альтернатива традиционным методам доставки SMS сообщений (CS, GPRS).

IP-SM-GW также позволяет доставлять SMS в обратном направлении (от абонентов IMS сетей пользователям CS 2G/3G сетей). Когда IMS абонент отправляет SIP сообщение, содержащее SMS как специальный тип контента (special content type), IP-SM-GW извлекает его и направляет в SMS центр (SMSC) для дальнейшей доставки по сетям SS7. Данный тип взаимодействия позволяет предоставлять все существующие SMS услуги (в т.ч. услуги с дополнительной оплатой) абонентам, зарегистрированным в IMS сетях. Эта функциональность называется SMS over IP (3GPP TS 23.204).

Дополнительно IP-SM-GW может поддерживать "родной" (native) сервис взаимодействия между SMS и SIP-based аппликациями. При этом SMS конвертируется в native SIP запрос и со стороны IMS UE не требуется поддержка SMS технологии.

Существует ограничивающий фактор, который нужно принимать во внимание, а именно – размер SIP сообщения (RFC3428) должен быть как минимум на 200 байт меньше MTU (maximum transmission unit). Если IP-SM-GW принимает сцепленное (concatenated) SMS сообщение (группа сообщений стандартной длины, вместе формирующих одно сообщение большой длины) и размер SIP MESSAGE превышает возможный лимит, IP-SM-GW должен использовать сессионный режим (session mode).

Сессионный режим предполагает изначальную установку сессии между IMS UE и IP-SM-GW, для чего IP-SM-GW посылает SIP INVITE. Как только сессия установлена MSRP протокол (message session relay protocol) используется для доставки сообщения IMS UE.

Функция взаимодействия между IMS сетями различных операторов связи реализуются посредством функционального модуля управления пограничным взаимодействием (Interconnection Border Control Function – IBCF) и транзитного шлюза (Transition Gateway – TrGW). Решаются следующие задачи:

  • Трансляция между различными версиями IP (IPv4, IPv6), используемыми на сетях операторов. В этом случае IBCF модифицирует SIP и SDP данные, позволяя пользователям, использующим различные версии IP, взаимодействовать друг с другом.
  • Транскодирование в ситуации, когда приложения конечных пользователей не имеют общего кодека, который может быть использован (например, транскодирование между AMR и G.722). Сервис транскодирования может быть включен проактивно (перед запросом на установку сессии к вызываемому абоненту) или реактивно (после того как сессия будет прервана вызываемым абонентом) – 3GPP TS 23.228.
  • Скрытие сетевой топологии. В этом случае IBCF выполняет шифрование / дешифрование всех заголовков сообщений, которые содержат информацию о топологии сети.
  • Фильтрация информации в SIP сообщениях. В этом случае IBCF удаляет или модифицирует некоторые SIP заголовки перед маршрутизацией сообщений в направлении сторонних сетей.
  • Выбор направления.
  • Генерация CDR.
  • NAT/Port трансляция – TrGW выполняет модификацию IP заголовков пакетов пользовательского трафика (RTP и пр.)

7. Шлюз доступа IMS (IMS-AGW – Access Gateway)

В частных (например, домашних и офисных) фиксированных сетях абонентский терминал (UE) может находиться за NAT-ом и firewall-ом, установленных на сетевых устройствах, являющихся точками доступа в такие сети (customer premise equipment - CPE). При этом NAT не осуществляет модификацию / натирование информации на SIP / SDP уровнях.

Для решения данной задачи P-CSCF содержит функционал SIP ALG (application level gateway), который обеспечивает управление IMS-AGW. SIP INVITE запрос от UE с приватным IP адресом достигает P-CSCF, функционал ALG которого назначает публичный IP адрес, привязывает его к SIP сессии, выполняет NAT-ирование (замену приватных IP адресов на всех протокольных уровнях, включая IP, SIP, SDP), осуществляет его дальнейшую маршрутизацию и информирует шлюз доступа о созданной связке. При поступлении медиа потока между двумя абонентскими терминалами (UE) шлюз доступа будет осуществлять NAT-ирование RTP пакетов в/из публичного/частного адресного пространств.

8. Шлюз безопасности (Security Gateway – SEG)

Шлюз безопасности размещается на границе доменной зоны оператора и обеспечивает его защиту. Весь междоменный трафик должен в обязательном порядке проходить через SEG. SEG обеспечивает конфиденциальность, контроль целостности данных (data integrity) и аутентификацию в соответствии с 3GPP TS 33.203.

9. Функция извлечения информации о местоположении (Location Retrieval Function - LRF)

LRF ассистирует E-CSCF в обработке IMS экстренных вызовов путем предоставления информации о местоположении абонентского терминала (UE), инициировавшего экстренный вызов, которая используется для выбора экстренной службы (PSAP), куда сессия должна быть перенаправлена. Для получения информации о местонахождении пользователя LRF может иметь встроенный location server или иметь функционал GMLC (gateway mobile location center) – интерфейс к внешнему location server.

Для выбора соответствующего PSAP – LRF может содержать функцию RDF (routing determination function), которая используется для выбора адреса PSAP на основании информации о местоположении пользователя.

LRF может обеспечивать поддержку и других локальных регуляторных параметров, таких как emergency service routing number, location number, PSAP SIP URI, PSAP TEL URI,...

10. Расширенный мобильный центр коммутации – Enhanced MSC Server (eMSS)

eMSS представляет из себя MSC сетей 2G/3G, который обладает функциональностью P-CSCF в направлении IMS.

При регистрации пользователя в сети 2G/3G eMSS выполняет от имени пользователя регистрацию в IMS домене, что позволяет пользователю CS сети, не имеющему доступа в пакетную сеть, получить доступ к IMS услугам.

Когда пользователь совершает исходящий CS вызов (mobile originating call) eMSS конвертирует legacy CS вызов в запрос IMS сессии и направляет его на IMS систему. Аналогично, когда кто-либо совершает вызов к пользователю, обслуживаемому eMSS, входящий вызов (mobile terminating call) маршрутизируется на IMS платформу, выполняющую установленную процедуру управления входящим вызовом, включая HSS interrogation, и переправляющую SIP запрос на eMSS, который в свою очередь конвертирует протокол управления IMS сессией в протокол управления CS вызовом.

eMSS позволяет предоставлять услугу, действительно независимую от типа доступа (CS, IP-CAN, legacy), поскольку предоставление услуги всегда обеспечивается IMS платформой. Это обеспечивает возможность пользователям мигрировать из 2G/3G CS сетей в IMS и обратно.

11. Функция управления шлюзом доступа – Access Gateway Control Function (AGCF)

AGCF – представляет из себя точку входа для пользователей PSTN/ISDN сетей (аналоговые и ISDN телефоны). Он выполняет следующие функции:

  • управление медиашлюзом (MGW) уровня доступа (access gateway);
  • взаимодействие с подсистемой управления ресурсами и доступом;
  • взаимодействие с подсистемой подключения к сети для получения информации о профиле линии;
  • обеспечение сигнального взаимодействия между SIP сигнализацией с одной стороны и аналоговой телефонной / ISDN сигнализацией с другой стороны.

С точки зрения IMS платформы AGCF выглядит как P-CSCF и обеспечивает соответствующий функционал (управление процедурой SIP регистрации и пр.).

Необходимая для тарификации информация собирается функциями тарификации различных модулей IMS из SIP запроса. При этом возможна online тарификация (в этом случае функция тарификации запрашивает разрешение у биллинговой системы на обработку SIP запроса) и offline тарификация (в этом случае функция тарификации всегда позволяет обработку SIP запроса, отправляя собранную тарификационную информацию в биллинговую систему для формирования CDR записей).

В зависимости от конфигурации IMS возможны различные схемы тарификации различных сервисов. При этом управление логикой тарификации осуществляется на основе срабатывания тех или иных триггеров. Триггерами могут быть:

  • запросы создания, модификации и терминации сессии (sessionbased charging);
  • любая SIP транзакция, например, MESSAGE, PUBLISH, SUBSCRIBE (eventbased charging);
  • определенные SIP заголовки и SDP информация.

Функции тарификации всех IMS модулей, а также модулей доступа могут взаимодействовать с offline модулем тарификации (offline charging entity – CDF), используя diameter-based Rf интерфейс (3GPP TS 32.299).

На основе информации, полученной из функциональных блоков тарификации всех IMS модулей, CDF создает CDR записи, которые переправляются в шлюз тарификации (charging gateway function – CGF) через Ga интерфейс (3GPP TS 32.295). Далее CGF обрабатывает полученные CDR и переправляет их в биллинговую систему используя Bх интерфейс (3GPP TS 32.240).

Prepaid сервисам необходима online тарификация. Это означает, что IMS сеть должна запрашивать OCS перед авторизацией пользователя на использование того или иного сервиса. OCS ответственен за контроль в реальном времени счета пользователя, авторизацию пользователя на использование сервиса и списание баланса со счета пользователя за полученные услуги. Только три IMS модуля (S-CSCF, AS, MRFC) взаимодействуют с OCS, используя интерфейс Ro. Кроме IMS модулей с OCS могут взаимодействовать не IMS модули. В частности, SGSN использует CAMEL application part (CAP). В дополнении к credit control (тарификация в on-line) OCS может создавать CDR записи подобно CGF.

HSS является хранилищем абонентских данных и данных, связанных с услугами. Он содержит функциональность центра аутентификации (AUC), LTE функциональность (SAE-HSS), GSM/UMTS функциональность (HLR), IMS функциональность (IMS-HSS), функциональность репозитория данных для управления тарификацией и политиками качества (SPR). Также HSS может использоваться для хранения данных серверов приложений (AS).

PCRF отвечает за формирование политик качества и управление тарификацией, основываясь на сессионной информации, полученной из P-CSCF.

Установление сессии в IMS обеспечивается обменом сигнальными сообщениями, используя SIP и SDP, включая согласование медиа характеристик (кодеков, IP адресов, номеров портов). Если оператор использует на своей сети PCRF, P-CSCF переправляет ему необходимую SDP информацию, на основании которой он создает политики и правила тарификации, а также авторизует IP потоки соответствующих медиа компонентов, мапируя данные SDP на IP QoS параметры для шлюза сети доступа, например, P-GW/PCEF.

Основываясь на доступной информации, PCRF применяет сформированные PCC политики и правила тарификации на шлюзе сети доступа (P-GW/PCEF), создает и модифицирует виртуальные соединения для переноса медиа-трафика (EPS bearer). В дополнение, PCRF принимает события с транспортного уровня, например, при потере радио-соединения, информируя об этих событиях P-CSCF, который в использует полученную информацию при формировании тарификационных данных и закрытии IMS сессии от имени пользователя.

Кроме того, PCRF может использоваться для обмена тарификационными идентификаторами, которые позволяют оператору коррелировать CDR, сгенерированные сетью доступа и сетью IMS; доставлять в сеть доступа метод тарификации (длительность, объем, оба); информацию rating group; команды активации on-line / off-line тарификации; адреса on-line / off-line систем тарификации; требуемый уровень отчетности, базирующийся на сервисе и rating-group.

  • >">Вперед >>