Что такое ims в телефоне. Предпосылки внедрения IMS

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

• Serving CSCF (S- CSCF ) – обслуживающая CSCF . Обрабатывает все SIP-coобщения, которыми обмениваются оконечные устройства;
• Proxy CSCF (P- CSCF ) – через нее в систему IMS поступает весь пользовательский трафик;
• Interrogating CSCF (I- CSCF ) – запрашивающая CSCF . Представляет собой точку соединения с домашней сетью. I- CSCF обращается к HSS, чтобы найти S- CSCF для конкретного абонента;

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

P-CSCF создает первую контактную точку на сигнальном уровне внутри ядра IMS для терминалов IMS данной сети. Функция P- CSCF принимает запрос от или к терминалу и маршрутизирует его к элементам ядра IMS . Обслуживаемый терминал пользователя закрепляется за функцией P- CSCF при регистрации в сети на все время регистрации. Модуль P- CSCF реализует функции, связанные с аутентификацией пользователя, формирует учетные записи и передает их в сервер начисления платы. Одним из элементов модуля P- CSCF является Policy Decision Function (PDF) – функция выбора политики, оперирующая с характеристиками информационного трафика (например, требуемая пропускная способность) и определяющая возможность организации сеанса или его запрета, необходимость изменения параметров сеанса и т. д.;

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

BGCF (Breakout Gateway Control Function) – функция управления шлюзами, управляет пересылкой вызовов между доменом коммутации каналов (ТфОП или GSM) и сетью IMS . Данный модуль осуществляет маршрутизацию на основе телефонных номеров и выбирает шлюз в домене коммутации каналов (КК), через который сеть IMS (где расположен сервер BGCF) будет взаимодействовать с ТфОП или GSM. Здесь также производится генерация соответствующих учетных записей для начисления платы абонентам сетей КК;

MGCF (Media GatewaysControl Function) – функция управления шлюзами (Media Gateways) – управляет соединениями в транспортных шлюзах IMS , используя Н.248/MEGACO;

SGW (Signaling Gateway) – сигнальный шлюз – обеспечивает преобразование сигнализации ТфОП в вид, понятный MGCF. Связан с ядром IMS через интерфейсы группы протоколов SIGTRAN;

RACS (The Resource and Access Control) – подсистема управления ресурсами и доступом – обеспечивает функции управления доступом (на основании имеющихся в распоряжении ресурсов, местной политики и авторизации на основании профилей пользователей) и входа в сеть с помощью управления шлюзом (gate control), включая управление преобразованием сетевых адресов и портов, и присвоение приоритета;

PDF (Policy Decision Function) – функция выбора политики, оперирующая с характеристиками информационного трафика (например требуемая пропускная способность) и определяющая возможность организации сеанса или его запрета, необходимость изменения параметров сеанса и т. д.;

NASS (Network Attachment Subsystem ) – подсистема подключения сети – в ее основные задачи входит динамическое назначение IP-адресов (используя DHCP – Dynamic Host Configuration Protocol), аутентификация на уровне IP, авторизация доступа к сети, управление местонахождением на уровне IP.

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

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

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

• SCIM (Service Capability Interaction Manager) – обеспечивает управление взаимодействием плоскости приложений и ядра IMS ;
• SIP AS (SIP Application Server) – сервер приложений, служащий для выполнения услуг, базирующихся на протоколе SIP. Ожидается, что все новые услуги в IMS будут находиться именно в сервере SIP AS;
• OSA-SCS (Open Service Access – Service Capability Server) – сервер возможных услуг, который обеспечивает интерфейс к услугам, базирующимся на открытом доступе услугам (OSA – Open Service Access). Целью является обеспечение услугам возможности доступа к сетевым функциям посредством стандартного программного интерфейса приложений;
• IM-SSF (IP Multimedia – Service Switching Function) – сервер коммутации услуги, служит для соединения подсистемы IMS с услугами в системе приспособленных к пользователю приложений для улучшения логики мобильной сети (CAMEL – Customized Applications for Mobile network Enhanced Logic). Речь идет об услугах, разработанных для глобальной системы мобильной связи GSM, а с помощью функции IM-SSF (функция коммутации услуг) использование данных услуг возможно и в IMS ;
• TAS (Telephony Application Server) – сервер телефонных приложений принимает и обрабатывает сообщения протокола SIP, а также определяет, каким образом должен быть инициирован исходящий вызов. Сервисная логика TAS обеспечивает базовые сервисы обработки вызовов, включая анализ цифр, маршрутизацию, установление, ожидание и перенаправление вызовов, конференц-связь и т. д. TAS также обеспечивает сервисную логику для обращения к медиасерверам при необходимости воспроизведения оповещений и сигналов прохождения вызова. Если вызов инициирован или терминирован в ТфОП, сервер TAS отвечает за сигнализацию SIP к функции MGCF для выдачи команды медиашлюзам на преобразование битов речевого потока TDM (ТфОП) в поток IP RTP и направление его на IP-адрес соответствующего IP-телефона. В одном сообщении IMS могут содержаться данные о нескольких TAS, предоставляющих определенные услуги различным типам абонентских устройств. Например, один сервер TAS оказывает услуги IP Centrex (частные планы нумерации, общие справочники, автоматическое распределение вызовов и т. д.), другой сервер поддерживает УАТС и предоставляет услуги VPN. Взаимодействие нескольких серверов приложений осуществляется посредством сигнализации SIP-I для завершения вызовов между абонентскими устройствами различных классов;
• HSS (Home Subscriber Server) – сервер домашних абонентов – аналогичен элементу сетей GSM – серверу HLR (Home Location Register) – является базой пользовательских данных. Сервер HSS обеспечивает открытый доступ в режиме чтения/записи к индивидуальным данным пользователя, связанным с услугами. Доступ осуществляется из различных точек окончания – таких как телефон, приложения Web и SMS, телевизионные приставки типа set-top box и т. д. В HSS реализуется также функции SLF (Subscription Locator Function), которая определяет положение базы данных, содержащей данные конкретного абонента, в ответ на запрос от модуля I- CSCF или от сервера приложений.

Наконец, в состав сервера HSS входят модули HLR и AuC (Authentication Center) для работы с сетями 2G.

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

Изобретение относится к 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 крупнейших вендоров.

ределенный в RFC 2486. PrUI выглядит следующим образом: [email protected]

Для абонентов UMTS PrUI хранится в логическом модуле идентифи-

кации мобильных абонентов IMS ISIM (IP Multimedia Services Identity Module), а так же в HSS, и используется для аутентификации и регистрации пользователя в IMS. PrUI не может быть изменен в терминале пользователя, действителен на все время подписки пользователя на услуги IMS, не используется для маршрутизации сообщений SIP. После регистрации и аутентификации пользователя PrUI должен храниться так же в S-CSCF.

3GPP Release 5 предписывал каждому пользователю иметь один PrUI, но в Release 6 это ограничение убрано, и теперь пользователь может иметь несколько PrUI.

Каждому идентификатору PrUI оператор ставит в соответствие, по меньшей мере, один идентификатор PuUI в формате SIP URI (RFC 3261) и не более чем один в формате tel URL (RFC 3966). В IMS идентификатор PuUI используется для маршрутизации сигнальных SIP-сообщений и в качестве контактной информации для других пользователей.

Формат PuUI:

 sip:[email protected]

 sip:[email protected];user=phone

Пользователю обычно требуется два разных PuUI – один для сети передачи данных, другой для телефонной сети общего пользования.

Другая причина иметь несколько PuUI – возможность использовать различные номера для разных контактов или услуг. Идентификационная карта IMS-терминала ISIM хранит один PrUI и, как минимум, один PuUI. Перед началом установления или в ходе сессии PuUI должен быть зарегистрирован в процессе регистрации.

Полная структура взаимосвязи нескольких PrUI и PuUI хранится в пользовательском профиле HSS (рис. 1.2). Пользовательский профиль обычно состоит из информации необходимой для подписки на услуги IMS, такой как идентификатор PrUI. Подписка на услуги IMS содержит один или несколько профилей обслуживания Service Profile (набор услуг и соответствующих данных пользователя). Каждому идентификатору PuUI оператор ставит в соответствие только один профиль обслуживания Service Profile.

UICC (Universal Integrated Circuit Card) – термин, означающий смен-

ную идентификационную карту, имеющую стандартизованный интерфейс с терминалом. Карта UICC может содержать несколько логических приложений, таких как SIM (GSM), USIM (UMTS) и ISIM – наиболее важное приложение, поскольку служит для идентификации, авторизации и конфигурации терминала при работе в IMS-сети.

						Public User Identity 1			Service Profile 1
			Private User Identity 1
Подписка на услуги						Public User Identity 2
IMS (IMS Subscription)
			Private User Identity 2						Service Profile 2
						Public User Identity 3

Рис. 1.2. Идентификация IMS пользователей

В 3GPP Release 6 появился идентификатор Public Service Identity (PSI),

В отличие от описанных выше идентификаторов, PSI присваивается не пользователям, а услугам, размещенным на серверах приложений. Так же, как и PuUI, идентификаторы PSI могут иметь формат sip url или tel url.

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

Подсистема IMS специфицируется как многоуровневая архитектура с разделением на три уровня (плоскости):

User Plane – транспортную плоскость; Control Plane – плоскость управления; Application Plane – плоскость приложений.

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

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

Синализация

Пользовательские данные

Рис. 1.3. Архитектура IMS

Транспортный уровень

Транспортный уровень отвечает за процедуру подключения пользователей к сети IMS (подуровень управления) и транспортировку данных пользователя (функции передачи). Функциональными элементами транспортного уровня являются:

подсистема присоединения сети NASS (network attachment subsystem) используется для пользователей не 3GPP доступа, относится к подуровню управления транспортного уровня. NASS обеспечивает динамическое назначение IP-адресов и других параметров конфигурации оборудования пользователя, аутентификацию пользователя до или в течение процедуры назначения IP-адреса, авторизацию и конфигурацию доступа к сети на основе профиля пользователя, управление местоположением;

подсистема управления доступом и ресурсами RACS (resource and admission control subsystem) используется для пользователей не 3GPP доступа, относится к подуровню управления транспортного уровня. RACS обеспечивает управление доступом, резервирование ресурсов, обеспечивает доступ к услугам, предоставляемым пограничным шлюзом, включая управление шлюзом и преобразование сетевых адресов;

мультимедийный шлюз IM–MGW (IP Multimedia Media GateWay)

осуществляет преобразование пользовательской информации сети с коммутацией каналов TDM в пакеты IP-сети и обратно и коммутацию пользовательской информации между портами шлюза;

шлюз сопряжения TrGW (Transition Gateway) вместе с функцией пограничного взаимодействия IBCF (Interconnection Border Control

Function) отвечает за взаимодействие между IP-сетями различных версий IP и операторов. Шлюз сопряжения TrGW осуществляет согласование сетей на уровне передачи пользовательской информации;

функция процессора ресурсов мультимедиа MRFP (Media Resource Function Processor) обеспечивает под управлением контроллера ресурсов мультимедиа MRFC широкий набор функций для поддержки мультимедийных сеансов, в том числе конфигурирование ресурсов, смешивание различных медиапотоков от нескольких источников, генерацию мультимедийных объявлений, обработку мультимедийных потоков (транскодирование), управление правом доступа к медиаресурсам при организации конференции.

Уровень управления

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

Основные логические элементы уровня управления.

Функциональный объект управления сессиями CSCF (Call/Session Control Function) является центральной частью системы IMS, используя протокол SIP, выполняет функции, обеспечивающие предоставление различных услуг реального времени посредством транспорта IP. CSCF включает три основных функции:

Proxy CSCF (P-CSCF) – выполняет функцию посредника (на сигнальном уровне) для взаимодействия IMS сети и пользовательского IMS терминала. Весь сигнальный трафик протокола SIP направляется от пользовательского терминала к P-CSCF и далее к точке входа в домашнюю сеть (I-CSCF), если пользователь находится в гостевой IMS, или к S-CSCF, если пользователь находится в домашней сети. Адрес S-CSCF определяется в процессе регистрации пользователя. Можно сказать, что P-CSCF реализует функции логического объекта SIP-агента пользователя UA (User Agent). P- CSCF участвует в регистрации пользователя, определяет адрес I-CSCF, находящейся в домашней сети, формирует учетные записи и передает их в сервер начисления платы, а также осуществляет проверку правильности построения сообщений SIP, передаваемых IMS терминалом. Обслуживаемый терминал пользователя закрепляется за функциональным объектом P- CSCF при регистрации в сети на все время регистрации. Адрес P-CSCF на все время сеанса хранится в S-CSCF для трансляции данных к пользователю;

Interrogating CSCF (I-CSCF) – выполняет функцию посредника для взаимодействия с внешними сетями. Функциональный объект I-CSCF создает первую контактную точку домашней сети IMS на сигнальном уровне в процессе регистрации пользователей, находящихся в гостевой сети, при установлении соединений между пользователями, находящимися в

различных домашних сетях, для всех внешних соединений с пользователями данной сети или гостевыми пользователями, временно находящимися в данной сети. Кроме выполнения функций SIP-прокси I-CSCF взаимодействует по протоколу Diameter с пользовательской базой данных HSS для:

o определения наличия или возможности регистрации пользователя

в данной сети,

o получения информации о функциональном объекте S-CSCF,

o если S-CSCF еще не назначен, I-CSCF производит его выбор в процессе регистрации пользователя,

o определение возможностей пользователя по доступу к услугам. I-CSCF также формирует учетные записи для начисления платы;

Serving CSCF (S-CSCF) – обслуживающая функция, обеспечивает управление мультимедийными сеансами. Помимо функции SIP-сервера, S- CSCF выполняет функцию регистрирующего сервера сети SIP (SIPregistrar), то есть хранит всю информацию о пользователе, полученную от I-CSCF и HSS: IP-адреса терминала, с которого пользователь получил доступ в сеть, PuUI, PrUI, возможности пользователя по доступу к услугам, адреса P-CSCF, I-CSCF. В свою очередь, S-CSCF информирует сервер пользовательских данных HSS о том, что пользователь прикреплен к ней на срок своей регистрации, и о срабатывании таймера регистрации. Вся сигнальная информация SIP, передаваемая и принимаемая IMS-терминалом, проходит через функциональный объект S-CSCF, к которому прикреплен пользователь. S-CSCF поддерживает сеанс в течение всего времени его продолжения и, по мере надобности, взаимодействует с сервисными платформами и с функциями начисления платы. S-CSCF всегда находится в домашней сети пользователя.

Пользовательская база данных HSS (Home Subscriber Server) представляет собой централизованное хранилище информации о пользователях и услугах сети IMS и является эволюционным развитием HLR (Home Location Register) из архитектуры сетей GSM/UMTS. В HSS хранится информация о публичном PuUI и закрытом PrUI идентификаторах пользователя IMS, имя обслуживающей функции управления сеансом связи S- CSCF, параметры аутентификации и шифрования, информация о сервере приложений, об услугах, на которые подписан пользователь, имя функции учета стоимости.

HSS взаимодействует с CSCF и серверами приложений, используя протокол Diameter. Если количество пользователей слишком велико, чтобы данные о них хранились в одном HSS, сеть может содержать более одного HSS. Такая сеть наряду с несколькими HSS имеет в своем составе функ-

циональный объект SLF (Subscriber Location Function), который хранит данные и соответствие адресов HSS адресам пользователей. Узел, передавший к SLF запрос с адресом пользователя, получает от него сведения о

Функциональный объект управления медиашлюзом MGCF (Media Gateways Control Function), его основной задачей является управление медиашлюзами (IM-MGW), а также прямое и обратное преобразование сигнализации сетей ОКС 7 (протокол ISUP) в сигнализацию сети IMS (протокол

Сигнальный шлюз SGW (Signaling Gateway) осуществляет преобразование протоколов нижних уровней для обеспечения двустороннего сигнального обмена между сетью IP и сетью TDM, заменяя подсистемы MTP протоколом SIGTRAN. При этом протоколы прикладного уровня (ISUP, MAP, CAP и другие) через SGW транслируются без анализа.

Контроллер ресурсов мультимедиа MRFC (Media Resource Function Controller). Контроллер ресурсов мультимедиа MRFC взаимодействует с S-CSCF по протоколу SIP и, используя информацию, полученную от S- CSCF, управляет MRFP с помощью протокола MEGACO (H.248). Например, трансляцией акустических сигналов и объявлений, транскодированием и перекодированием, объединением медиапотоков при управлении конференциями.

Функциональный объект управления пограничными шлюзами

BGCF (Breakout Gateway Control Function) реализует функции управления выбором сети, осуществляет маршрутизацию на основе информации о телефонных номерах, получаемой из сообщений протокола SIP, административной информации и/или с помощью доступа к базам данных. BGCF используется только при установлении сеанса между пользователями сети IMS и абонентом сети с коммутацией каналов. BGCF выбирает сеть IMS, в которой будет происходить взаимодействие с сетью с коммутацией каналов, или MGCF, если BGCF находится в сети IMS, которая будет взаимодействовать с сетью с коммутацией каналов. Оборудование BGCF также маршрутизирует транзитный сигнальный трафик.

Функциональный объект граничного взаимодействия IBCF

(Interconnection Border Control Function) обеспечивает взаимодействие с IP-

сетями. IBCF, обеспечивает реализацию стека протоколов SIP/SDP для установления взаимосвязи между приложениями SIP на основе IPv6 и приложениями SIP на основе IPv4, сокрытие сетевой топологии, управление с помощью протокола MEGACO шлюзами сопряжения TrGW при установлении соединений с другими IMS или другими сетями, функционирующими на основе протокола IP. IBCF также выполняет функции маршрутизации при транзите.

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

Уровень приложений относится к верхнему уровню сетевой архитектуры IMS. На данном уровне расположены серверы приложений AS, пре-

доставляющие доступ как к приложениям IMS, так и приложениям на основе других платформ (таких как OSA и CAMEL).

На этом уровне сервера приложений отвечают за обслуживание конечных пользователей.

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

SCIM (Service Capability Interaction Manager) – обеспечивает управление взаимодействием плоскости приложений и ядра IMS;

SIP AS (SIP Application Server) – сервер приложений, служащий для выполнения услуг, базирующихся на протоколе SIP. Ожидается, что все новые услуги в IMS будут находиться именно в сервере SIP AS;

OSA-SCS (Open Service Access – Service Capability Server) – сер-

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

IM-SSF (IP Multimedia – Service Switching Function) – сервер ком-

мутации услуги, служит для возможности использования в IMS услуг

CAMEL (Customized Applications for Mobile network Enhanced Logic) разра-

ботанных для мобильных сетей;

TAS (Telephony Application Server) – сервер телефонных прило-

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

1.6. Технологии доступа к сети IMS

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

Изначально (в спецификациях 3GPP Release 5) IMS была ориентирована на работу с мобильными сетями поколения 2,5G (GSM/GPRS), имеющими технологию радиодоступа GERAN, и 3G (UMTS) – технология радиодоступа UTRAN. В стандартах консорциума 3GPP2 описана возможность доступа к IMS сети радиодоступа CDMA2000.

В последующих версиях 3GPP Release 6, 7 и ETSI TISPAN рассмотрены вопросы взаимодействия IMS с сетями, имеющими технологии доступа WLAN/Wi-Fi, хDSL (рис. 1.4). А в версиях 8 и 10 спецификаций 3GPP была добавлена поддержка инфраструктур HSPA и LTE.

Presence AS Messaging AS

Уровень приложения

Рис. 1.4. Организация доступа к сети IMS

Для доступа к IMS пользователей сетей радиодоступа GERAN/UTRAN используются узлы GPRS (SGSN, GGSN) (рис. 1.4).

За доступ пользовательского оборудования WLAN к сети IMS отвечает пакетный шлюз PDG (Packet Data Gateway) и шлюз беспроводного дос-

тупа WAG (Wireless Access Gateway).

Мультиплексор DSLAM (Digital Subscriber Line Access Multiplexer) и граничный шлюз A-BGF/BAS (Access Border Gateway Function/Broadband Access Switch), обеспечивает широкополосный доступ фиксированных пользователей к сети IMS.

1.7. Основные протоколы IMS

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

Протоколы подсистемы IMS обеспечивают управление мультимедийными сессиями (SIP, SDP), передачу пользовательского трафика (RTP и RTCP), регистрацию, аутентификацию, авторизацию, поддержку мобильности пользователя (Diameter). Протокол MEGACO/H.248 используется для

управления зависимыми объектами транспортной плоскости. Для транс-
портировки сигнальной информации ОКС7в сетях IP и взаимодействия с
другими сетями, в частности с ТфОП, используется протокол SIGTRAN.
						Плоскость услуг и
							приложений
						Плоскость управления
						Транспортная плоскость
				Сеть абонентского доступа

Рис. 1.5. Функциональные элементы и интерфейсы архитектуры IMS

Перечень возможных интерфейсов (внешних и внутренних) и протоколов взаимодействия, реализованных в архитектуре IMS, представлен в табл. 1.1.

			Таблица 1.1
	Наименование	Протоколы	Описание
	интерфейса (рис. 1.6)	взаимодействия
			Обмен сообщениями
			между сервером приложения AS
			и функцией MRFC
			Взаимодействие
			между I-CSCF/S-CSCF и HSS
			Обнаружение сервером приложе-
			ний AS, необходимого HSS,
			в сети с несколькими HSS
			Обнаружение функциями
			I-CSCF/S-CSCF, необходимого
			HSS, в сети с несколькими HSS
			Обмен сообщениями между
			оборудованием пользователя
			и функциями CSCF
			Взаимодействие между
			блоками IBCF различных
			мультимедийных сетей
			Обмен сообщениями между
			функциями CSCF и серверами
			приложений AS
			Взаимодействие между
			элементами IBCF и TrGW
			Взаимодействие между TrGW
			и пограничными шлюзами
			различных мультимедийных сетей
			Взаимодействие между блоками
			I-CSCF и сервером приложений

В настоящее время в Беларуси оператор электросвязи Белтелеком усиленно внедряет телефонную связь на базе сети IMS. Предоставляется оборудование в пользование. Представляет оно собой обычный ADSL модем, но со встроенным SIP клиентом.

Но у нас есть CISCO 2951 с поднятой телефонией. Возникла мысль, а можно ли настроить такой телефонный номер без оборудования Белтелеком и напрямую в маршрутизаторе.

При разборе настроек в модеме выяснилось следующее. VoIP подается по отдельному PVC (VCI/VPI=2/35) в режиме IP/DHCP:

Модем получает настройки IP и шлюза по DHCP.

Нам важно запомнить адрес шлюза, для дальнейшей настройки на CISCO.

При заключении договора выдаются следующие данные:

Номер телефона: +37517xxxxxxx
Login: [email protected]

Необходимо также узнать пароль к сервису IMS: passIMS . У меня в маршрутизаторе Cisco установлена ADSL2 and ADSL2 High-Speed WAN Interface Cards .

Настраиваем сначала подключение по нужному PVC(2/35).

Interface ATM0/1/0.2 point-to-point ip address dhcp no ip proxy-arp ip nat outside ip virtual-reassembly in atm route-bridged ip pvc 2/35 encapsulation aal5snap
.02 в имени интерфейса выбрана произвольно, так как у меня уже есть одно соединение на этом же интерфейсе.

Sh int atm 0/1/0.2
убеждаемся что интерфейс поднялся и IP адрес получен.

Настройки SIP серверов тоже можно увидеть в модеме, если предварительно в telnet дать следующую команду: sendcmd 3 webd setconfig voippagedisp y .

Будем использовать один из SIP серверов, а именно 10.56.0.9 . Далее необходимо прописать маршруты.

Ip route 10.56.0.9 255.255.255.255 10.233.64.1 ip route 10.56.0.10 255.255.255.255 10.233.64.1 ip route 10.56.0.11 255.255.255.255 10.233.64.1
10.56.0.10 и 10.56.0.11 - это адрес RTP сервера обслуживающего аудио поток. Так как ims.beltel.by не имеет в DNS записи, то прописываем ее руками.

Ip host ims.beltel.by 10.56.0.9
Теперь переходим к непосредственной настройки sip-ua. Здесь есть особенность, авторизация должна проходить с указанием домена, т.е. вида [email protected]. Поэтому используем еще параметр number .

Sip-ua credentials number +37517xxxxxxx username [email protected] password PassIMS realm ims.beltel.by authentication username +37517xxxxxxx password PassIMS realm ims.beltel.by retry invite 3 retry response 3 retry bye 3 retry cancel 3 retry register 5 registrar dns:ims.beltel.by:5060 expires 3600 auth-realm ims.beltel.by sip-server dns:ims.beltel.by:5060 connection-reuse host-registrar
Об успешной регистрации будет видно из команды:

Dial-peer voice 8017 voip description #toIMS# translation-profile outgoing fromIMS destination-pattern 8017.T session protocol sipv2 session target sip-server session transport udp voice-class codec 1 dtmf-relay rtp-nte no vad
Необходимо также обязательно подменять свой внутренний номер на номер выданный Белтелекомом, чтобы звонок обслуживался. Это делается через translation-profile .

Voice translation-rule 1 rule 1 /.*/ /+37517xxxxxxx/ voice translation-profile fromIMS translate calling 1
Так как у меня используются телефоны Cisco 6921, то для входящего звонка просто прописан параметр secondary на внутреннем номере.

Ephone-dn 1 dual-line number 1234 secondary +37517xxxxxxx no-reg both
Таким образом мы получаем SIPовский номер в нашу телефонную сеть без дополнительного стороннего оборудования и в цифровом виде.

Update: С недавнего времени Белтелеком начал работать по UDP протоколу. Поэтому для входящих соединений уже не получится вписать secondary номер. Необходимо делать dial-peer с входящим правилом.

Примерно такой:

Dial-peer voice 9192 voip description #Incoming_IMS# translation-profile incoming incomIMS session protocol sipv2 session target dns:ims.beltel.by session transport udp incoming called-number +37517xxxxxxx voice-class codec 1 dtmf-relay rtp-nte
где translation-profile incoming incomIMS это правило сопоставления номера IMS вашему внутреннему, на который необходимо принять звонок.

Например:

Voice translation-rule 5 rule 1 /.*/ /1234/ voice translation-profile incomIMS translate called 5