Способы и устройства для инициирования снабжения абонентскими данными в hss сети мультимедийной подсистемы протокола ip

Изобретение относится к способу и устройству для предоставления абонентских данных в узлах сети мультимедийной подсистемы протокола IP. Технический результат заключается в осуществлении динамического снабжения абонентскими данными множества узлов сети мультимедийной подсистемы протокола IP. Технический результат достигается за счет способа, который содержит прием запроса аутентификации или сообщения протокола инициирования сеанса относительно данного абонента, который использует пользовательский терминал, чтобы осуществлять доступ к сети мультимедийной подсистемы протокола IP, а если определяют, что абонентские данные в текущий момент не предоставлены для абонента в функциональном блоке сервера абонентских данных, или принимают такое определение, выполняют следующие этапы: 1) вызывают посылку первого уведомления, указывающего, что попытка регистрации отклонена, в пользовательский терминал, и 2) посылают второе уведомление в систему снабжения абонента, информирующее систему снабжения о попытке регистрации. 3 н. и 14 з.п. ф-лы, 6 ил.

 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение относится к способу и устройству для предоставления абонентских данных в узлах сети мультимедийной подсистемы протокола IP.

УРОВЕНЬ ТЕХНИКИ

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

UMTS (универсальная мобильная телекоммуникационная система) является беспроводной системой третьего поколения, предназначенной для обеспечения более высоких скоростей передачи данных и усовершенствованных услуг пользователям. UMTS является преемником глобальной системы мобильной связи (GSM), причем важным эволюционным этапом между GSM и UMTS является пакетная радиосвязь общего назначения (GPRS). GPRS вводит коммутацию пакетов в базовую сеть GSM и позволяет непосредственный доступ к сетям пакетных данных (PDN). Это дает возможность высокоскоростным пакетам коммутировать передачи далеко за пределом 64 кбит/сек ISDN посредством сети вызова GSM, что является необходимостью для скоростей передачи данных UMTS до 2 Мбит/сек. UMTS стандартизована Проектом партнерства 3-го поколения (3GPP), который является конгломерацией региональных органов в области стандартов, таких как Европейский институт стандартов в области телекоммуникаций (ETSI), Ассоциация предприятий радиоиндустрии (ARIB) и других. Для больших подробностей смотри 3GPP TS 23.002.

Архитектура UMTS включает в себя подсистему, известную как мультимедийная подсистема протокола IP (IMS), для поддержки традиционной телефонии, а также новых мультимедийных услуг IP (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229 TS 29.328 и TS 29.329, версии с 5 по 7). IMS обеспечивает главные признаки, чтобы расширить опыт межличностной коммуникации конечных пользователей посредством использования стандартизованных разрешающих устройств услуг IMS, которые способствуют новым расширенным межличностным услугам связи (между клиентами), а также услуги между человеком и контентом (между клиентом и сервером) через сети, основанные на IP. IMS может соединяться как с PSTN/ISDN (коммутируемой телефонной сетью общего пользования/цифровой сетью с интегрированным услугами), а также Internet.

IMS использует протокол инициирования сеанса (SIP), чтобы устанавливать вызовы или сеансы между пользовательскими терминалам (или терминалами и серверами приложений) и управлять ими. Протокол описания сеанса (SDP), переносимый с помощью сигнализации SIP, используют, чтобы описывать и согласовывать мультимедийные компоненты сеанса. В то время как SIP был создан как межпользовательский протокол, IMS позволяет операторам и провайдерам услуг управлять доступом пользователя к услугам и, соответственно, назначать оплату пользователям. 3GPP выбрал SIP для сигнализации между пользовательским оборудованием (UP) и IMS, а также между компонентами в IMS.

В качестве примера, фиг.1 схематически иллюстрирует, как IMS входит в архитектуру мобильной сети в случае сети доступа GPRS/PS (конечно, IMS может работать через другие сети доступа). Функциональные блоки управления вызовом/сеансом (CSCF) работают в качестве посредников (прокси) SIP в IMS. Архитектура 3GPP задает три типа CSCF: уполномоченный CSCF (P-CSCF), который является первой точкой контакта в IMS для терминала SIP, обслуживающий CSCF (S-CSCF), который обеспечивает услуги пользователю, на которые пользователь подписан, и опрашивающий CSCF (I-CSCF), ролью которого является идентифицировать правильный S-CSCF и передать в этот S-CSCF запрос, принятый из терминала SIP с помощью P-CSCF.

В сети услуг IMS серверы приложений (AS) обеспечены для осуществления функциональности услуг IMS. Серверы приложений обеспечивают услуги конечным пользователям в системе IMS и могут быть соединены либо как конечные точки через интерфейс Mr, заданный 3GPP, либо “связаны” с помощью S-CSCF через интерфейс ISC, заданный 3GPP. В последнем случае используют критерии начального фильтра (IFC) с помощью S-CSCF, чтобы определить, какие серверы приложений должны быть “связаны” во время установления сеанса SIP (или, фактически, с целью любого связанного способа, сеанса или не сеанса SIP). IFC принимают с помощью S-CSCF из HSS во время процедуры регистрации IMS как часть профиля абонента пользователя.

Предварительным условием для пользователя, чтобы получить доступ к IMS и ее услугам, является то, что пользователь ранее был “снабжен” в сети, т.е. что абонент и связанные данные услуг были зарегистрированы в центральной базе данных, такой как сервер абонентских данных (HSS) и функциональный блок определителя местонахождения подписки (SLF). Всякий раз, когда оператор сети желает запустить услугу через сеть IMS, оператор вряд ли точно знает, какие абоненты пожелают использовать услугу. Оператор имеет две возможности, либо предварительно снабдить полной базой данных абонента в сети IMS, либо осуществить некоторый вид способа автоматического снабжения, посредством которого абоненты могут быть снабжены, как только и когда они подписываются на услугу.

WO 2007/099090 заявляет и раскрывает один такой способ автоматического снабжения. Более конкретно, документ решает проблему, встречающеюся, когда абонент пытается зарегистрироваться в IMS, когда этот абонент не снабжен в IMS. При регистрации данные абонента традиционного регистра домашнего местонахождения (HLR) извлекают с использованием процедуры учета Radius (службы удаленной аутентификации пользователям по телефонным линиям) и сохраняют в базе данных HSS. Допускают, что процедура аутентификации и авторизации должна быть выполнена в сети GPRS до доступа к IMS. Следовательно, допускают, что принятая регистрация IMS должна быть аутентичной. В процедуре запроса местонахождения частный ID (IMPI) извлекают и идентифицируют с помощью сравнения его с ранее сохраненным значением IMSI, где IPMI может быть получен из IMSI. (IMSI сохраняют в узле AuC GMS/UMTS, а IMPI в узле AVG IMS для целей аутентификации). Доступные данные будут сохранены в HSS, и процедура регистрации будет успешной.

С процедурой, описанной в WO 2007/099090, могут возникать некоторое число проблем. Во-первых, процедура зависит от учета radius, выполняемого из GPRS в HSS, и другие способы аутентификации не могут быть использованы. Во-вторых, в сети с множеством HSS с SLF упомянутый SLF не будет снабжен местоположением HSS абонента, и выбор HSS для абонента будет сделан с помощью сети доступа. В-третьих, решение снабжать абонента в сети основано только на том факте, что абонент пытается осуществить доступ к сети и по существу деловые аспекты не рассматривают. В-четвертых, единственными данными, которые могут быть сохранены в HSS, являются те, которые приняты при попытке доступа. Наконец, системы деловой информации и оплаты не будут знать о снабженном абоненте.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

1) вызывают посылку первого уведомления, указывающего, что попытка регистрации отклонена, в пользовательский терминал, и

2) посылают второе уведомление в систему снабжения абонента, информирующего систему снабжения о попытке регистрации.

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

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

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

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

Способ может быть осуществлен в обслуживающем функциональном блоке управления сеансом вызова в качестве альтернативы или дополнительно к осуществлению способа в HSS.

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

1) вызвать посылку первого уведомления, указывающего, что попытка регистрации отклонена, в пользовательский терминал, и

2) посылки второго уведомления в систему снабжения абонента, информирующего систему снабжения о попытке регистрации.

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

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

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

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

1) вызывают посылку первого уведомления, уведомляющего, что попытка регистрации отклонена в пользовательский терминал, и

2) посылают второе уведомление в систему снабжения абонента, информирующее систему снабжения о попытке регистрации.

3) в ответ на прием упомянутого второго уведомления в системе обеспечения абонентских данных для абонента в упомянутом сервере абонентских данных или другой сервер абонентских данных мультимедийной подсистемы протокола IP.

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

Второе уведомление может быть послано с помощью сервера абонентских данных.

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

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

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

узлом функционального блока определения местонахождения подписки;

узлом в системе доменных имен/узлом перечисления;

сервером приложения протокола инициирования сеанса.

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 схематически иллюстрирует базовую сеть IMS, интегрированную в систему связи, содержащую сети доступа 3GPP (c коммутацией пакетов и коммутацией каналов);

фиг.2 схематически иллюстрирует различные узлы в сети IMS и внешнюю систему снабжения;

Фиг.3 изображает сигнализацию, связанную с процедурой автоматического снабжения IMS в системе фиг.2.

Фиг.4 - блок-схема последовательности этапов, изображающая процесс для автоматического снабжения абонентов в сети IMS;

Фиг.5 схематически иллюстрирует сервер абонентских данных сети IMS и

Фиг.6 схематически иллюстрирует систему снабжения для снабжения абонентов в узле или узлах сети IMS.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

Фиг.2 схематически иллюстрирует различные компоненты базовой сети IMS, включающей в себя сервер абонентских данных (HSS) 1, функциональный блок определения местонахождения подписки (SLF) 2, I-CSCF 3 и S-CSCF 4. “Внешняя” система 5 снабжения связывается с HSS, SLF и другими узлами базовой сети IMS, которые необходимо снабдить абонентскими данными, с помощью LDAP или интерфейса web-службы (XML/SOAP/HTTP). Внешнюю систему 5 снабжения обычно поддерживают с помощью оператора сети IMS, и она обеспечена базой данных или имеет доступ к базе данных, содержащей информацию об услугах и данные подписки. Как указано на фигуре, пользовательское оборудование (UE) взаимодействует с базовой системой IMS с помощью P-CSCF 6. Все из узлов, проиллюстрированных на фиг.2, осуществлены с использованием компьютерного аппаратного обеспечения, включающего в себя процессоры, память и т.д. Функциональные возможности могут быть осуществлены с помощью подходящего программного обеспечения.

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

1. Пользователь посылает сообщение регистрации SIP в сеть IMS (этап 100).

2. I-CSCF принимает сообщение регистрации и запрашивает SLF, идентифицировать для него некоторый HSS, которому в текущий момент распределен пользователь (этап 101).

3-4. В этом примере пользователь в текущий момент не снабжен, и SLF определяет, что должно быть применено “неявное снабжение” (этап 102). SLF возвращает в I-CSCF идентификатор (адрес) HSS для обработки запроса регистрации (SLF может решить, какой HSS возвращен, на основании внутренних политик: маршрутизации на основе домена, числа пользователей на HSS и т.д.). Этот режим является новым в SLF. Конечно, если IMS снабжена для абонента, следуют обычные процедуры IMS (этап 103).

5. I-CSCF посылает запрос регистрации в HSS.

6-7. HSS обнаруживает, что пользователь не снабжен и что должно быть применено неявное снабжение. Он применяет политики авторизации по умолчанию, которые были заданы, и возвращает “успешный” ответ в I-CSCF (этап 104).

8-9. I-CSCF маршрутизирует запрос регистрации в S-CSCF (этап 105), и S-CSCF запрашивает HSS, чтобы аутентифицировать пользователя (этап 106, 107). (Если аутентификация является неуспешной, опять следуют обычные процедуры IMS (этап 108)).

10-11. HSS обнаруживает, что пользователь, для которого запрошена аутентификация, не снабжен (этап 109), таким образом он применяет один или, возможно, оба из следующих способов аутентификации:

а) HSS использует заблаговременную безопасность IMS, при допущении, что он принял учетную информацию из GGSN.

b) он выполняет аутентификацию AKA IMS. В зависимости от того, что использован ли USIM или ISIM, HSS может запросить HLR или другой внешний объект аутентификации относительно деталей полномочий.

(Если абонентские данные предоставлены (снабжены), опять следуют обычные процедуры IMS (этап 110)).

12. Если аутентификация является успешной, HSS указывает это в S-CSCF, но также указывает, что пользователь является тем, кто должен быть неявно снабжен, и по существу, что не все узлы IMS в текущий момент будут знать о пользователе (этап 113). Этот режим является новым в HSS.

13-14. S-CSCF возвращает ошибку временной недоступности пользователю, информирующую пользователя о том, что после заданного интервала должна быть выполнена вторая регистрация (этап 114). Этот режим является новым в S-CSCF.

13'. HSS уведомляет внешнюю систему снабжения, что обнаружен и аутентифицирован новый пользователь и что он должен быть снабжен в IMS (этап 111). Чтобы выполнить это, HSS посылает в систему снабжения всю доступную информацию (принятые идентификаторы пользователя, MSISDN, необходимость создать дополнительные идентификаторы в случае, когда идентификатор регистрации основан на IMSI, из-за причин безопасности и т.д.). В этот момент посылают поддерживаемые возможности (такие как MMTel, PoC и т.д.), также объявленные с помощью UE, чтобы дать возможность системе снабжения предоставить услуги, которые поддерживает устройство и которые предложены оператором (поддерживаемые возможности ранее посланы из S-CSCF в HSS с использованием интерфейса Cx). Весь этот режим является новым в HSS.

14'-18'. Система снабжения рассматривает деловые аспекты, связанные со снабжением пользователя (занесение в черный список, уровень подписки и т.д.), и при допущении, что результат этого является успешным, она обеспечивает (снабжает) все требуемые узлы в системе IMS (DNS, SLF, HSS, систему оплаты, определенные услуги и т.д.) (этап 112). Система снабжения может решить, какими услугами снабдить на основе внутренних политик и указанных возможностей устройства.

19. UE осведомлен, что требуется вторая регистрация, и выполняет ее после определенного интервала. На этот раз регистрация пользователя является успешной, и пользователь получает полный доступ ко всем его/ее услугам IMS (этап 115).

Фиг.5 схематически иллюстрирует сервер абонентских данных (HSS) 1, подходящий для использования в описанной процедуре автоматического снабжения. HSS содержит первый приемник 10 для приема запроса аутентификации относительно данного абонента, который использует пользовательский терминал, чтобы осуществлять доступ к сети мультимедийной подсистемы протокола IP, и устройство 11 аутентификации для выполнения этой аутентификации. Устройство 12 определения обеспечено для того, чтобы определять, предоставлены ли или нет в текущий момент абонентские данные для абонента в базе 13 данных абонентов этого (или другого) HSS. Устройство 12 определения сконфигурировано с возможностью уведомления как внешней системы снабжения, так и пользовательского терминала в случае, когда данные не предоставлены в текущий момент и требуется снабжение. HSS содержит второй приемник 14 для приема данных предоставления из системы снабжения и для сохранения этих данных в базе 13 данных абонентов.

Теперь, ссылаясь на фиг.6, она иллюстрирует узел 5 системы снабжения для использования с описанной процедурой снабжения. Узел содержит память 20 для хранения данных подписки и политик сети и приемник 21 для приема, из узла упомянутой мультимедийной подсистемы протокола IP, уведомления, информирующего систему снабжения о попытке регистрации или доступа к услуге абонентом, для которого в текущий момент не предоставляют данные в HSS сети IMS. Устройство 22 определения сконфигурировано с возможностью определения абонентских данных на основании упомянутых данных подписки и политик сети, обычно установленных с помощью оператора сети. Устройство 23 посылки сконфигурировано с возможностью посылки определенных абонентских данных в HSS, распределенный абоненту.

Процедура снабжения, представленная в настоящей заявке, по-новому применяет способы аутентификации IMS 3GPP, такие как IMS-AKA. Все необходимые объекты в IMS могут быть автоматически предоставлены, уменьшая необходимость иметь “знание” абонента в сети до какой-либо активности абонента. При использовании системы снабжения, чтобы активировать подписку, абонентские данные, сохраненные в различных узлах по всей сети, могут быть совместимыми. Некоторые услуги могут быть предоставлены одновременно. Главная база данных или подобная также могла бы быть поддержана с абонентскими данными.

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

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

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

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

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

5. Способ по п.4 и содержащий этап, на котором включают одну или более возможностей сети во второе уведомление.

6. Устройство для обеспечения абонентских данных в сети мультимедийной подсистемы протокола IP, сконфигурированное с возможностью обеспечения функционального блока сервера абонентских данных в сети мультимедийной подсистемы протокола IP, причем устройство содержит:
приемник для приема запроса аутентификации относительно данного абонента, который использует пользовательский терминал, чтобы осуществлять доступ к сети мультимедийной подсистемы протокола IP,
устройство аутентификации для аутентификации абонента,
устройство определения для определения того, что абонентские данные в текущий момент не обеспечены для абонента в функциональном блоке сервера абонентских данных, и
устройство уведомления, реагирующее на такое определение с возможностью:
1) вызвать посылку первого уведомления, указывающего, что попытка регистрации отклонена, в пользовательский терминал,
2) посылать второе уведомление в систему снабжения абонента, информирующее систему снабжения о попытке регистрации.

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

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

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

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

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

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

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

14. Способ по п.13, в котором упомянутое сообщение ошибки протокола инициирования сеанса является сообщением временной недоступности.

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

16. Способ по любому из пп.7-15, в котором упомянутое сообщение протокола инициирования сеанса включает в себя одну или более возможностей мультимедийной подсистемы протокола IP пользовательского терминала, причем способ содержит этап, на котором включают эти возможности в упомянутое второе уведомление.

17. Способ по п.16, содержащий этап, на котором включают одну или более возможностей в упомянутое второе уведомление.