СИСТЕМА И СПОСОБ ДЛЯ УКАЗАНИЯ ДОСТУПА С КОММУТАЦИЕЙ КАНАЛОВ ПРИ IMS-РЕГИСТРАЦИИ Российский патент 2011 года по МПК H04W8/06 H04W60/04 H04W88/10 H04L29/06 

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

Изобретение относится к 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 или в сетевом узле.

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

Изобретение относится к 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 ил.

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.