Область техники
Настоящее изобретение относится к IP Multimedia Subsystem (мультимедийной подсистеме IP) (IMS) и, в частности, к способу, системе и устройству для осуществления ассоциации пользовательской идентичности.
Уровень техники
IMS это подсистема, предложенная организацией 3rd Generation Partnership Project (3GPP), которая поддерживает мультимедийные услуги IP. Существенный признак IMS состоит в осуществлении разделения между управлением услугами, управлением сеансами и доступом к однонаправленному каналу с развертыванием Session Initiation Protocol (протокола инициирования сеанса) (SIP) в качестве протокола управления вызовом. IMS является платформой управления мультимедиа/управления вызовом в пакетной области и поддерживает как сеансовые, так и несеансовые мультимедийные услуги. IMS обеспечивает общую платформу услуг для мультимедийных приложений.
На фиг. 1 показана частичная архитектурная схема IMS, в которой Call Session Control Function (функция управления сеансом вызова) (CSCF) является центральной управляющей частью в базовой сети IMS и отвечает за аутентификацию подписки User Equipment (пользовательского оборудования) (UE) и управление сеансами. CSCF осуществляет базовую функцию маршрутизации сеанса в отношении вызывающего и вызываемого пользователей и осуществляет инициирование маршрутизации для ценных добавленных услуг на Application Server (сервер приложений) (AS) и взаимодействие управления услугами при выполнении условия, согласно IMS Initial Filter Criteria (iFC) (исходным критериям фильтра) подписанным пользователем. Home Subscriber Server (домашний сервер абонента) это сервер базы данных пользователей, который сохраняет информацию подписки IMS для пользователя, т.е. информацию ассоциации между пользовательской идентичностью и данными подписки пользователя. Когда пользователь проводит операцию услуги, соответствующие объекты в IMS, например Interrogating (опрашивающая) CSCF (I-CSCF), Serving (обслуживающая) CSCF (S-CSCF) и AS, получают данные подписки соответствующего пользователя от HSS, через пользовательскую идентичность. В информации подписки IMS множество данных подписки пользователя, относящихся к услуге, называется Service Profile (SP) (профилем услуги).
Обратимся к фиг. 2, где показана схема, демонстрирующая соотношение между пользовательской идентичностью и SP. Согласно фиг. 2 пользовательская идентичность включает в себя IMS Private User Identity (личную пользовательскую идентичность IMS) (IMPI) и IMS Public User Identity (публичную пользовательскую идентичность IMS) (IMPU). IMPI принадлежит только одной подписке IMS, и одна подписка IMS может включать в себя совокупность IMPI. IMPI может включать в себя совокупность IMPU, и IMPU может совместно использоваться совокупностью IMPI. IMPU имеет только один SP, и один SP может совместно использоваться совокупностью IMPU.
Можно видеть, что HSS ассоциирует IMPU, которые совместно используют один и тот же SP. В практических применениях иногда пользователь надеется, что два или более подписанных IMPU не только совместно используют один и тот же SP, но также имеют одни и те же данные услуги, например информацию пересылки по адресу, в точности одинаковую информации представления, что означает, что два или более IMPU имеют эквивалентное поведение. Однако HSS не может ассоциировать такого рода IMPU с уровнем техники.
Сущность изобретения
Соответственно, с одной стороны, варианты осуществления изобретения предусматривают два способа осуществления ассоциации пользовательской идентичности; с другой стороны, варианты осуществления изобретения предусматривают систему и устройство для осуществления ассоциации пользовательской идентичности, чтобы можно было ассоциировать IMPU с эквивалентным поведением.
Первый способ осуществления ассоциации идентичности пользователя, предусмотренный согласно варианту осуществления изобретения, включает в себя этапы, на которых:
устанавливают идентификатор пользователя с эквивалентным поведением на HSS; и
ассоциируют публичные пользовательские идентичности IMS (IMPU) с эквивалентным поведением через установленный идентификатор пользователя с эквивалентным поведением.
Система для осуществления ассоциации пользовательской идентичности, предусмотренная согласно варианту осуществления изобретения, включает в себя HSS и первый запрашивающий объект, где:
HSS способен ассоциировать IMPU с эквивалентным поведением и передавать информацию ассоциации IMPU с эквивалентным поведением на первый запрашивающий объект путем переноса информации в сообщении; и
первый запрашивающий объект способен анализировать сообщение от HSS и получать информацию ассоциации IMPU с эквивалентным поведением из сообщения.
Устройство для осуществления ассоциации пользовательской идентичности, предусмотренное согласно варианту осуществления изобретения, включает в себя модуль установления указания и модуль представления указания, где:
модуль установления указания способен устанавливать идентификатор пользователя с эквивалентным поведением на HSS;
модуль представления указания способен ассоциировать IMPU с эквивалентным поведением с использованием идентификатора пользователя с эквивалентным поведением, установленного модулем установления указания.
Из вышеописанных решений следует, что варианты осуществления изобретения устанавливают идентификатор пользователя с эквивалентным поведением на HSS и ассоциируют IMPU с установленным идентификатором пользователя с эквивалентным поведением. В результате ассоциация IMPU с установленным эквивалентным поведением осуществляется на HSS, что повышает удобство пользователя.
Краткое описание чертежей
Фиг. 1 - частичная архитектурная схема IMS.
Фиг. 2 - схема, демонстрирующая соотношение между пользовательской идентичностью и SP.
Фиг. 3 - иллюстративная логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно варианту осуществления настоящего изобретения.
Фиг. 4 - иллюстративная блок-схема устройства для осуществления ассоциации пользовательской идентичности согласно варианту осуществления настоящего изобретения.
Фиг. 5 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно первому варианту осуществления настоящего изобретения.
Фиг. 6 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно второму варианту осуществления настоящего изобретения.
Фиг. 7 - схема, демонстрирующая структуру класса Public Identity согласно уровню техники.
Фиг. 8 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно третьему варианту осуществления настоящего изобретения.
Фиг. 9 - схема, демонстрирующая структуру добавленного класса, который указывает псевдонимическую идентичность согласно третьему варианту осуществления настоящего изобретения.
Фиг. 10 - блок-схема устройства для осуществления ассоциации пользовательской идентичности согласно третьему варианту осуществления настоящего изобретения.
Фиг. 11 - блок-схема системы для осуществления ассоциации пользовательской идентичности согласно третьему варианту осуществления настоящего изобретения.
Фиг. 12 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно четвертому варианту осуществления настоящего изобретения.
Фиг. 13 - схема, демонстрирующая структуру класса Public Identity согласно четвертому варианту осуществления настоящего изобретения.
Фиг. 14 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно пятому варианту осуществления настоящего изобретения.
Фиг. 15 - схема, демонстрирующая структуру класса Public Identity согласно пятому варианту осуществления настоящего изобретения.
Фиг. 16 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно шестому варианту осуществления настоящего изобретения.
Фиг. 17 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно седьмому варианту осуществления настоящего изобретения.
Фиг. 18 - схема, демонстрирующая структуру класса Public Identity согласно седьмому варианту осуществления настоящего изобретения.
Фиг. 19 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно восьмому варианту осуществления настоящего изобретения.
Фиг. 20 - блок-схема системы для осуществления ассоциации пользовательской идентичности согласно восьмому варианту осуществления настоящего изобретения.
Фиг. 21 - логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно девятому варианту осуществления настоящего изобретения.
Подробное описание
Согласно варианту осуществления изобретения идентификатор пользователя с эквивалентным поведением устанавливается на HSS, и IMPU с эквивалентным поведением ассоциируются с использованием идентификатора пользователя с эквивалентным поведением.
Обратимся к фиг. 3, где показана иллюстративная логическая блок-схема способа ассоциирования идентичности пользователя согласно варианту осуществления настоящего изобретения. Согласно фиг. 3 последовательность действий включает в себя следующие этапы:
Этап 301: установление идентификатора пользователя с эквивалентным поведением на HSS.
На этом этапе существует, по меньшей мере, следующие два способа установления идентификатора пользователя с эквивалентным поведением на HSS.
Согласно первому способу на HSS указание устанавливается для указания множества IMPU с эквивалентным поведением.
Согласно второму способу указание устанавливается для указания множества IMPU с эквивалентным поведением, которому принадлежит IMPU, с IMPU на HSS.
Этап 302: ассоциирование IMPU с эквивалентным поведением с использованием установленного идентификатора пользователя с эквивалентным поведением.
Согласно первому способу этапа 301 установленное указание используется для организации IMPU с эквивалентным поведением в множество на этом этапе. Таким образом, указание включает в себя одно или несколько множеств IMPU с эквивалентным поведением, и каждое множество IMPU с эквивалентным поведением включает в себя один или несколько IMPU.
Согласно второму способу этапа 301 установленное указание используется для указания множества IMPU с эквивалентным поведением, которому принадлежит IMPU. Таким образом, значение указания используется для определения, какому множеству IMPU с эквивалентным поведением принадлежит IMPU.
Кроме того, HSS может представлять информацию ассоциации IMPU с эквивалентным поведением для S-CSCF, и/или HSS может представлять информацию ассоциации IMPU с эквивалентным поведением для AS.
Кроме того, S-CSCF может представлять информацию ассоциации IMPU с эквивалентным поведением для AS, и/или S-CSCF может представлять информацию ассоциации IMPU с эквивалентным поведением для P-CSCF, и/или S-CSCF представляет информацию ассоциации IMPU с эквивалентным поведением для UE.
Кроме того, информация ассоциации IMPU с эквивалентным поведением может быть включена в информацию услуги iFC, относящихся к IMPU, на HSS. Когда S-CSCF запрашивает пользовательские данные у HSS, S-CSCF загружает iFC с информацией услуги, включающей в себя информацию ассоциации IMPU с эквивалентным поведением, из HSS, и S-CSCF представляет информацию услуги, включающую в себя информацию ассоциации IMPU с эквивалентным поведением, для AS путем ее переноса в сообщении, при выполнении iFC. AS может получать информацию ассоциации IMPU с эквивалентным поведением из сообщения.
Обратимся к фиг. 4, где показана иллюстративная блок-схема устройства для осуществления ассоциации пользовательской идентичности согласно варианту осуществления изобретения. Согласно фиг. 4 устройство включает в себя модуль установления указания и модуль представления указания.
В котором модуль установления указания способен устанавливать идентификатор пользователя с эквивалентным поведением на HSS.
Модуль представления указания способен ассоциировать IMPU с эквивалентным поведением с использованием идентификатора пользователя с эквивалентным поведением, установленного модулем установления указания.
Кроме того, чтобы пользователь мог регистрировать совокупность IMPU в сети IMS, предусмотрен механизм неявной регистрации. Таким образом, когда регистрируется любой из IMPU, принадлежащих Implicitly Registered Public User Identity Set (множеству неявно зарегистрированных публичных пользовательский идентичностей) (IRPUIS), другие IMPU в IRPUIS регистрируются в то же время. Кроме того, IMPU в одном и том же IRPUIS должны принадлежать одному и тому же IMPI, и IMPU могут иметь один и тот же или разные SP, однако один и тот же IMPU принадлежит только одному IRPUIS.
Согласно фиг. 2 IMPU1 и IMPU2 принадлежат одному и тому же IRPUIS. Когда IMPU1 регистрируется в сети, IMPU2 также регистрируется. Аналогично, когда IMPU2 регистрируется в сети, IMPU1 также регистрируется. Здесь IMPU1 и IMPU2 имеют разные SP. Каждый из IMPU3 и IMPU4 на фиг. 2 представляет собой IRPUIS, совместно используемое IMPI1 и IMPI2, и имеет одно и то же SP. Каждый из IMPU5 и IMPU6 на фиг. 2 представляет собой IRPUIS, принадлежащий IMPI2, и они имеют разные SP. При этом IMPU5 имеет такой же SP, как у IMPU3 и IMPU4.
Множество IMPU с эквивалентным поведением согласно вариантам осуществления изобретения может быть подмножеством IRPUIS или множеством IMPU с эквивалентным поведением, независимых от IRPUIS. Для удобства описания IMPU с эквивалентным поведением называются Alias Public User Identity (псевдонимическая публичная пользовательская идентичность) (APUI), и множество IMPU с эквивалентным поведением называется Alias Public User Identity Set (множество псевдонимических публичных пользовательских идентичностей) (APUIS) в этом описании.
В дальнейшем способ, система и устройство для осуществления ассоциации пользовательской идентичности будут подробно описаны со ссылкой на некоторые варианты осуществления.
Первый вариант осуществления: используется первый способ, т.е. указание, используемое для указания IMPU с эквивалентным поведением, устанавливается на HSS.
Обратимся к фиг. 5, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно первому варианту осуществления изобретения. Согласно фиг. 5 последовательность действий включает в себя следующие этапы:
Этап 501: установление указания для указания APUIS на HSS.
На этом этапе к HSS добавляется тип данных. Этот тип данных предназначен для указания APUIS и действует как указание APUIS. Оно может быть подмножеством IRPUIS соответствующего пользователя или множеством, независимым от IRPUIS. Обратимся к таблице 1, где представлено детальное осуществление варианта осуществления. Указание, используемое для указания APUIS, добавленное в Таблицу 1, называется Alias Public User Identity Set и может, при необходимости, быть добавлено в соответствующую подстатью, которая представлена как 3.X.X в таблице 1.
В таблице 1 “M” представляет «обязательный», “C” представляет «условный» и “-” представляет «отсутствующий». Тип “P” представляет статический постоянный тип, и “T” представляет динамический временный тип.
Этап 502: Ассоциирование IMPU с эквивалентным поведением с использованием установленного ранее указания.
На этом этапе установленное указание используется для указания IMPU с эквивалентным поведением, т.е. одного или нескольких APUIS. Каждое APUIS включает в себя один или несколько IMPU, и IMPU имеют в точности одинаковый SP и в точности одни и те же данные услуги, т.е. они имеют эквивалентное поведение. Может существовать совокупность APUIS согласно подписке IMS, и даже может существовать совокупность APUIS для каждого IRPUIS, хотя каждый IMPU может принадлежать только одному APUIS.
Способ осуществления ассоциации идентичности подробно описан выше. В дальнейшем будет подробно описано устройство для осуществления ассоциации идентичности.
Структура, отношение соединения и функция устройства согласно этому варианту осуществления изобретения такие же, как для устройства, показанного на фиг. 4, за исключением того, что устройство этого варианта осуществления является экземпляром устройства, показанного на фиг. 4. Иначе говоря, модуль установления указания в устройстве способен устанавливать указание, используемое для указания APUIS на HSS.
Второй вариант осуществления: используется второй способ, т.е. указание, используемое для указания множества IMPU с эквивалентным поведением которому принадлежит IMPU, устанавливается с IMPU на HSS.
Обратимся к фиг. 6, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно второму варианту осуществления изобретения. Согласно фиг. 6 последовательность действий включает в себя следующие этапы:
Этап 601: установление указания, используемого для указания множества IMPU с эквивалентным поведением, которому принадлежит IMPU, с IMPU на HSS.
На этом этапе можно добавить номер для каждого IMPU, принадлежащего APUIS в IRPUIS, соответствующем IMPU на HSS. Номер предназначен для указания APUIS, которому принадлежит IMPU, и действует как указание APUIS, которому принадлежит IMPU.
Альтернативно, можно добавить номер для каждого IMPU, принадлежащего APUIS, независимому от IRPUIS. Номер предназначен для указания APUIS, которому принадлежит IMPU, и действует как указание APUIS, которому принадлежит IMPU.
Этап 602: ассоциирование IMPU с эквивалентным поведением с использованием установленного ранее указания.
На этом этапе установленное указание используется для указания тех IMPU в IRPUIS, которые имеют в точности одинаковые SP и данные услуги для IMPU, иначе говоря, они имеют эквивалентное поведение.
Альтернативно, установленное указание используется для указания IMPU, которые имеют в точности одинаковые SP и данные услуги для IMPU, иначе говоря, они имеют эквивалентное поведение.
При наличии совокупности APUIS указание используется для указания APUIS, которому принадлежит IMPU. IMPU с одним и тем же номером принадлежат одному и тому же APUIS.
Способ осуществления ассоциации идентичности подробно описан выше. В дальнейшем будет подробно описано устройство для осуществления ассоциации идентичности.
Структура, отношение соединения и функция устройства согласно этому варианту осуществления изобретения такие же, как для устройства, показанного на фиг. 4, за исключением того, что устройство этого варианта осуществления является экземпляром устройства, показанного на фиг. 4. Иначе говоря, модуль установления указания в устройстве способен устанавливать указание, используемое для указания APUIS, которому принадлежит IMPU, с IMPU на HSS.
Способ и устройство для осуществления ассоциации пользовательской идентичности на HSS подробно описаны в двух вышеприведенных вариантах осуществления. В практических применениях, AS, UE, P-CSCF, S-CSCF также может потребоваться информация соответствующих IMPU. Например, S-CSCF нужно знать, какие IMPU имеют эквивалентное поведение, благодаря чему информация может поступать на AS, P-CSCF. Когда пользователь изменяет данные услуги IMPU1 посредством UE, пользователю может понадобиться знать, применимо ли изменение также к IMPU2. Когда AS передает сообщение на IMPU1, AS может понадобиться знать, следует ли передавать такое же сообщение также на IMPU2. P-CSCF может потребоваться обеспечить IMPU с эквивалентным поведением точке принятия решения в сети доступа, чтобы одна и та же политика выбиралась для IMPU с эквивалентным поведением. Таким образом, HSS может дополнительно включать в себя представление информации ассоциации IMPU с эквивалентным поведением для сетевого объекта, например S-CSCF или AS.
Согласно уровню техники S-CSCF, назначенная пользователю, может получать информацию подписки на услугу пользователя от HSS с использованием пары команд Server-Assignment-Request (запрос назначения сервера) (SAR)/Server-Assignment-Answer (ответ назначения сервера) (SAA), и HSS может обновлять информацию подписки на услугу, подлежащую изменению, для S-CSCF с использованием команды Profile-Push-Request (запрос проталкивания профиля) (PPR)/Profile-Push-Answer (ответ проталкивания профиля) (PPA). В сообщении информация подписки на услугу включена в Diameter Attribute Value Pair (пару значений атрибута Diameter) (AVP) в качестве файла eXtensible Markup Language (расширяемого языка разметки) (XML). Здесь обмен сообщениями между HSS и S-CSCF может осуществляться посредством интерфейса Cx.
Например, если IMPU1, IMPU2 и IMPU3 принадлежат одному и тому же IRPUIS, и IMPU1 и IMPU2 имеют один и тот же SP1, тогда как IMPU3 имеет другой SP2, когда S-CSCF запрашивает данные любого из IMPU в IRPUIS, содержимое файла XML, включенного в SAA, может быть следующим:
В вышеописанном файле XML подписка IMS существует от 'начало подписки IMS' до 'конец подписки IMS'. Существует два SP в вышеописанной подписке IMS, и SP существует от 'начало SP' до 'конец SP'. Один SP включает в себя IMPU и iFC и т.д.
На фиг. 7 показана схема, демонстрирующая структуру класса Public Identity согласно уровню техники. Согласно фиг. 7 Public Identity включает в себя публичные идентичности относящиеся к SP, и публичные идентичности могут иметь вид SIP Universal Resource Identifier (универсального идентификатора ресурса) (URI) или Tel URI. Каждая Public Identity включает в себя соответствующее поле BarringIndication. Если поле BarringIndication установлено, S-CSCF будет препятствовать использованию IMPU в любой другой связи IMS за исключением Registration (регистрации) и De-registration (отмены регистрации). Public Identity также включает в себя поле IdentityType, которое используется для указания типа публичной идентичности, например IMPU или независимой Public Service Identity или PSI, согласованной с Wildcarded PSI. Здесь, IdentityType имеет перечислительный тип и может принимать 3 значения: 0 указывает, что Public Identifier является IMPU; 1 указывает, что Public Identifier является независимой PSI; и 2 указывает, что Public Identifier является PSI, которая может быть согласована с Wildcarded PSI. Кроме того, публичная идентичность также может включать в себя поле DisplayName и т.д.
В вышеописанном файле XML существует две публичные идентичности, которые включают в себя IMPU1 и IMPU2 соответственно, что свидетельствует о том, что два IMPU имеют один и тот же SP. Во втором SP существует только одна публичная идентичность IMPU3.
iFC используется для инициирования услуги и описывает, когда принятое сообщение SIP будет отправлено на конкретный сервер приложений или AS.
Кроме того, SP также может включать в себя авторизацию услуги базовой сети и iFC общего пользования, и т.д.
Согласно варианту осуществления изобретения для того, чтобы HSS мог представлять информацию ассоциации IMPU с эквивалентным поведением для S-CSCF, HSS может расширять файлы XML относящиеся к SP, которые передаются на S-CSCF. Расширение может производиться, по меньшей мере, следующими пятью способами.
Способ первый: HSS добавляет новый класс, указывающий псевдонимическую идентичность, в SP, передаваемый на S-CSCF. IMPU с эквивалентным поведением указываются в добавленном новом классе, указывающем псевдонимическую идентичность, и HSS представляет информацию ассоциации для S-CSCF посредством SP, несущего указание.
Способ второй: HSS добавляет атрибут, указывающий множество, которому принадлежит IMPU, в класс Public Identity из SP, передаваемого на S-CSCF. Множества IMPU с эквивалентным поведением, которым принадлежит каждый IMPU, указываются путем присвоения значения атрибуту. HSS представляет информацию ассоциации для S-CSCF посредством SP, несущего указание.
Способ третий: HSS добавляет новый класс, указывающий элементы множества, которому принадлежит IMPU, в класс Public Identity из SP, передаваемого на S-CSCF. IMPU с поведением, эквивалентным каждому IMPU, указываются в добавленном классе. HSS представляет информацию ассоциации для S-CSCF посредством SP, несущего указание.
Способ четвертый: при наличии одного множества IMPU с эквивалентным поведением среди IMPU с одним и тем же SP, HSS может расширять поле значения атрибута IdentityType в классе Public Identity в SP, передаваемом на S-CSCF, и указывать IdentityType для IMPU с эквивалентным поведением с использованием значения расширенного IdentityType. HSS представляет информацию ассоциации для S-CSCF посредством SP, несущего указание IdentityType.
Способ пятый: при наличии одного множества IMPU с эквивалентным поведением среди IMPU с одним и тем же SP, HSS добавляет атрибут, указывающий, имеет ли IMPU эквивалентное поведение, к классу Public Identity в SP, передаваемом на S-CSCF. Принадлежит ли IMPU множеству IMPU с эквивалентным поведением указывается путем присвоения значения атрибуту. HSS представляет информацию ассоциации для S-CSCF посредством SP, несущего указание.
В дальнейшем, способ, устройство и система для осуществления ассоциации пользовательской идентичности, воплощающие вышеозначенные пять способов осуществления, будут подробно описаны со ссылкой на варианты осуществления.
Третий вариант осуществления: используется первый способ.
Обратимся к фиг. 8, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно третьему варианту осуществления изобретения. Согласно фиг. 8 последовательность действий включает в себя следующие этапы:
Этап 801: ассоциирование пользовательских идентичностей на HSS.
Детальное осуществление этапа может быть таким же, как в описании первого или второго варианта осуществления. Оно также может принимать другой способ осуществления, который фактически требуется.
Этап 802: HSS добавляет класс, указывающий псевдонимическую идентичность, в SP, передаваемом на S-CSCF.
Согласно варианту осуществления, когда HSS расширяет файл XML, относящийся к SP, переданному на S-CSCF, класс, используемый для указания псевдонимической идентичности, аналогичный классу Public Identity, может быть добавлен к SP, как показано на фиг. 9, где показана схема, демонстрирующая структуру добавленного класса, который указывает псевдонимическую идентичность согласно варианту осуществления. Добавленный класс, который указывает псевдонимическую идентичность, может включать в себя один или несколько IMPU, имеющих эквивалентное поведение, и IMPU могут иметь вид SIP URI или TEL URI. Здесь экземпляр добавленного класса, который указывает псевдонимическую идентичность, равен 0 или больше 0.
В детальном осуществлении, если добавленный класс, который указывает псевдонимическую идентичность, называется Alias Identity List (список псевдонимических идентичностей), то реляционное отображение описания файла XML с классом, который указывает добавленную псевдонимическую идентичность, имеет вид, показанный в таблице 2.
элементов
Authorization
Extension
Extension2
В таблице 2 вновь добавленный класс, указывающий псевдонимическую идентичность, называется Alias Identity List, который получается в поле расширения tServiceProfileExtension. В отсутствие IMPU с эквивалентным поведением, номер экземпляра Alias Identity List равен 0. При наличии более одного множества IMPU с эквивалентным поведением, номер экземпляра Alias Identity List больше единицы. Один Alias Identity List может включать в себя один или несколько классов Alias Identity. Один класс Alias Identity включает в себя Identity, который аналогичен Identity в классе Public Identity, показанном на фиг. 7. Также идентичность в классе Alias Identity может иметь вид SIP URI или TEL URI; где идентичность соответствует IMPU с эквивалентным поведением и один Alias Identity List может включать в себя совокупность IMPU.
Этап 803: добавленный класс для указания псевдонимической идентичности используется для указания IMPU с эквивалентным поведением.
На этом этапе экземпляр каждого вновь добавленного класса, указывающего псевдонимическую идентичность, т.е. экземпляр класса Alias Identity List на этапе 802, включает в себя множество IMPU с эквивалентным поведением. Разные множества IMPU с эквивалентным поведением можно указывать с использованием экземпляра разных классов Alias Identity List.
Этап 804: HSS представляет информацию ассоциации IMPU с эквивалентным поведением для S-CSCF посредством SP, несущего вышеупомянутое указание.
На этом этапе HSS передает файл XML, несущий SP, указывающий IMPU с эквивалентным поведением для S-CSCF, которая анализирует информацию ассоциации IMPU с эквивалентным поведением, согласно принятому файлу XML.
Пример состоит в том, что IMPU1 и IMPU2 имеют эквивалентное поведение, и IMPU3 и IMPU4 имеют эквивалентное поведение. Рассмотрим случай, когда существует IRPUIS, и множество IMPU с эквивалентным поведением является подмножеством IRPUIS. Если IMPU1, IMPU2, IMPU3 и IMPU4 находятся в одном и том же IRPUIS, когда S-CSCF запрашивает пользовательские данные IMPU1 от HSS посредством SAR, содержимое файла XML, переносимого в SAA, имеет следующий вид:
Где экземпляр Alias Identity List существует от “начало Alias Identity List” до “конец Alias Identity List”. В вышеописанном файле XML можно видеть, что SP включает в себя два экземпляра Alias Identity List. Первый экземпляр Alias Identity List указывает два псевдонимических IMPU, т.е. IMPU1 и IMPU2 имеют эквивалентное поведение. Второй экземпляр Alias Identity List указывает два псевдонимических IMPU, т.е. IMPU3 и IMPU4 имеют эквивалентное поведение.
Когда S-CSCF принимает вышеописанный файл XML, она анализирует информацию ассоциации IMPU с эквивалентным поведением, т.е. IMPU1 и IMPU2 имеют эквивалентное поведение, и IMPU3 и IMPU4 имеют эквивалентное поведение, согласно указанию экземпляра Alias Identity List.
Способ осуществления ассоциации идентичности согласно вариантам осуществления настоящего изобретения подробно описан выше. В дальнейшем будет подробно описано устройство для осуществления ассоциации идентичности.
На основании устройства, показанного на фиг. 4, устройство согласно варианту осуществления настоящего изобретения дополнительно включает в себя модуль представления информации. Обратимся к фиг. 10, где показана блок-схема устройства для осуществления ассоциации идентичности согласно третьему варианту осуществления изобретения.
Где на основании устройства, описанного согласно фиг. 4, модуль представления указания дополнительно способен представлять указанные IMPU с эквивалентным поведением модулю представления информации.
Модуль представления информации способен представлять информацию ассоциации IMPU с эквивалентным поведением запрашивающего объекта, согласно информации IMPU с эквивалентным поведением, обеспеченной модулем представления указания. В этом варианте осуществления запрашивающий объект является S-CSCF.
Где, когда модуль представления информации реализован в деталях, он может быть таким же, как описано на этапах 802-804 на фиг. 8.
В дальнейшем, будет подробно описана система для осуществления ассоциации идентичности согласно варианту осуществления.
Обратимся к фиг. 11, где показана блок-схема системы для осуществления ассоциации идентичности согласно третьему варианту осуществления изобретения. Согласно фиг. 11 система включает в себя HSS и первый запрашивающий объект.
Где HSS способен ассоциировать IMPU с эквивалентным поведением и передавать информацию ассоциации IMPU с эквивалентным поведением на первый запрашивающий объект путем переноса информации в сообщении. В этом варианте осуществления запрашивающий объект является S-CSCF.
Первый запрашивающий объект способен анализировать сообщение от HSS и получать информацию ассоциации IMPU с эквивалентным поведением. В этом варианте осуществления запрашивающий объект является S-CSCF.
Где, в детальном осуществлении, HSS может включать в себя модуль представления указания и модуль представления информации.
Где модуль представления указания способен ассоциировать IMPU с эквивалентным поведением и предоставлять информацию указанных IMPU с эквивалентным поведением модулю представления информации.
Модуль представления информации способен представлять информацию ассоциации IMPU с эквивалентным поведением на первый запрашивающий объект путем переноса информации в сообщении, согласно информации IMPU с эквивалентным поведением, обеспеченной модулем представления указания. В этом варианте осуществления запрашивающий объект является S-CSCF.
Где, когда модуль представления информации реализован в деталях, он может быть таким же, как описано на этапах 802-804 на фиг. 8.
Кроме того, HSS может быть дополнительно способен устанавливать идентификатор пользователя с эквивалентным поведением и использовать установленный идентификатор пользователя с эквивалентным поведением для ассоциирования IMPU с эквивалентным поведением. Соответственно HSS может дополнительно включать в себя модуль установления указания, который способен устанавливать идентификатор пользователя с эквивалентным поведением. Таким образом, модуль представления указания дополнительно способен ассоциировать IMPU с эквивалентным поведением с использованием идентификатора пользователя с эквивалентным поведением, установленного модулем установления указания. В детальном осуществлении модуль установления указания может быть таким же, как описанный в первом или втором варианте осуществления.
Четвертый вариант осуществления: используется второй способ.
Обратимся к фиг. 12, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно четвертому варианту осуществления изобретения. Согласно фиг. 12 последовательность действий включает в себя следующие этапы:
Этап 1201: ассоциирование пользовательских идентичностей на HSS.
Детальное осуществление этапа может быть таким же, как в описании первого или второго варианта осуществления. Оно также может принимать другой способ осуществления, который фактически требуется.
Этап 1202: HSS добавляет атрибут, указывающий множество, которому принадлежит IMPU, в класс Public Identity из SP, передаваемого на S-CSCF.
Согласно варианту осуществления, когда HSS расширяет файл XML, относящийся к SP, переданному на S-CSCF, атрибут, указывающий множество, которому принадлежит IMPU, добавляется в класс Public Identity из SP. Обратимся к фиг. 13, где схематически показана структура класса Public Identity согласно варианту осуществления, куда добавлен атрибут, указывающий множество, которому принадлежит IMPU.
В детальном осуществлении, если добавленный атрибут, указывающий множество, которому принадлежит IMPU, называется Alias Identity Set Num, то реляционное отображение описания файла XML с добавленным атрибутом, указывающим множество, которому принадлежит IMPU, выглядит, как показано в таблицах 3 и 4.
0 (PUBLIC_USER_IDENTITY), представляющее IMPU
1 (DISTINCT_PSI), представляющее PSI
2 (WILDCARDED_PSI), представляющее wildcarded PSI
В таблице 3 атрибут, указывающий множество, которому принадлежит IMPU, называется Alias Identity Set Num, и Alias Identity Set Num имеет целый тип. Alias Identity Set Num также может иметь другой тип данных, например «строка». Alias Identity Set Num получается путем расширения поля расширения, что показано в таблице 4.
Authorization
Authorization
Extension
Extension2
Из таблицы 4 следует, что Alias Identity Set Num получается в поле расширения типа tPublicIdentityExtension2 класса Public Identity. Экземпляр класса Public Identity включает в себя не более одного Alias Identity Set Num. Когда IMPU в Public Identity не имеет ни одного IMPU с эквивалентным поведением, нет необходимости добавлять Alias Identity Set Num в Public Identity.
Этап 1203: присвоение значения для добавленного атрибута, которое указывает множество IMPU с эквивалентным поведением, которому принадлежит каждый IMPU.
Если имеется два множества IMPU с эквивалентным поведением, и если два множества IMPU с эквивалентным поведением обозначены 1 и 2 соответственно, то атрибуту Alias Identity Set Num для IMPU в двух множествах может быть присвоено значение 1 и 2 соответственно, которые используются для указания множества IMPU с эквивалентным поведением, которому принадлежит IMPU.
Этап 1204: HSS представляет информацию ассоциации IMPU с эквивалентным поведением для S-CSCF посредством SP, несущего вышеупомянутое указание.
На этом этапе HSS передает XML, несущий SP, который указывает множество IMPU с эквивалентным поведением, которому принадлежит IMPU, для S-CSCF, и S-CSCF анализирует информацию ассоциации IMPU с эквивалентным поведением согласно принятому файлу XML.
Пример состоит в том, что IMPU1 и IMPU2 имеют эквивалентное поведение, и IMPU3 и IMPU4 имеют эквивалентное поведение. Рассмотрим случай, когда существует IRPUIS, и множество IMPU с эквивалентным поведением является подмножеством IRPUIS. Если IMPU1, IMPU2, IMPU3 и IMPU4 находятся в одном и том же IRPUIS, когда S-CSCF запрашивает пользовательские данные IMPU1 от HSS посредством SAR, содержимое файла XML, переносимого в SAA, имеет следующий вид:
Множество IMPU с эквивалентным поведением, которому принадлежит IMPU, можно указывать путем присвоения значения атрибуту Alias Identity Set Num. На основании вышеупомянутого файла XML в экземпляре класса Public Identity для IMPU1, Alias Identity Set Num равен 1, и это указывает, что IMPU1 принадлежит множеству 1; в экземпляре класса Public Identity для IMPU2, Alias Identity Set Num равен 1, и это указывает, что IMPU2 принадлежит множеству 1; в экземпляре класса Public Identity для IMPU3, Alias Identity Set Num равен 2, и это указывает, что IMPU2 принадлежит множеству 2; в экземпляре класса Public Identity для IMPU4, Alias Identity Set Num равен 2, и это указывает, что IMPU2 принадлежит множеству 2.
Когда S-CSCF принимает вышеописанный файл XML, она анализирует информацию ассоциации IMPU с эквивалентным поведением, т.е. IMPU1 и IMPU2 имеют эквивалентное поведение, и IMPU3 и IMPU4 имеют эквивалентное поведение, согласно указанию в Alias Identity Set Num.
Выше подробно описан способ осуществления ассоциации идентичности согласно варианту осуществления.
Структура, отношение соединения и функция устройства согласно варианту осуществления такие же, как у устройства согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации в устройстве согласно варианту осуществления может быть таким же, как описано на этапах 1202-1204 на фиг. 12.
Кроме того, структура, отношение соединения и функция системы согласно варианту осуществления такие же, как у системы согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации HSS согласно варианту осуществления может быть таким же, как описано на этапах 1202-1204 на фиг. 12.
Пятый вариант осуществления: используется третий способ.
Обратимся к фиг. 14, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно пятому варианту осуществления изобретения. Согласно фиг. 14 последовательность действий включает в себя следующие этапы:
Этап 1401: ассоциирование пользовательских идентичностей на HSS.
Детальное осуществление этапа может быть таким же, как в описании первого или второго варианта осуществления. Оно также может принимать другой способ осуществления, который фактически требуется.
Этап 1402: HSS добавляет класс, указывающий элементы множества, которому принадлежит IMPU, в класс Public Identity в SP, передаваемом на S-CSCF.
В этом варианте осуществления, когда HSS расширяет файл XML, относящийся к SP, переданному на S-CSCF, он может указывать элементы множества, которому принадлежит IMPU, путем добавления нового класса в класс Public Identity в SP. Обратимся к фиг. 15, где схематически показана структура класса Public Identity согласно варианту осуществления, в которую добавлен класс, указывающий элементы множества, которому принадлежит IMPU.
В детальном осуществлении, если добавленный класс, указывающий элементы множества, которому принадлежит IMPU, называется Alias Identity, то реляционное отображение описания файла XML с классом, который указывает элементы множества, которому принадлежит IMPU, имеет вид, показанный в таблице 5.
Authorization
Authorization
Extension
Extension2
В таблице 5 класс, указывающий элементы множества, называется Alias Identity, который получается в поле расширения типа tPublicIdentityExtension2 в классе Public Identity. В отсутствие IMPU, имеющих поведение, эквивалентное идентичности в Public Identity, количество экземпляров класса Alias Identity равно 0. При наличии более одного IMPU, имеющего поведение, эквивалентное идентичности в Public Identity, количество экземпляров класса Alias Identity больше единицы. Один класс Alias Identity включает в себя атрибут Identity, который аналогичен Identity в классе Public Identity, показанном на фиг. 7. Также Identity в классе Alias Identity может иметь вид SIP URI или TEL URI; где Identity соответствует IMPU с эквивалентным поведением.
Этап 1403: информация IMPU с поведением, эквивалентным каждому IMPU, указывается в добавленном классе.
Если предположить, что IMPU1 и IMPU2 являются IMPU, имеющими эквивалентное поведение, то информация IMPU2 указывается в атрибуте Alias Identity для IMPU1, и информация IMPU1 указывается в атрибуте Alias Identity для IMPU2. Аналогично, если IMPU1 IMPU2 и IMPU3 являются IMPU, имеющими эквивалентное поведение, то информация IMPU2 и IMPU3 указывается в атрибуте Alias Identity для IMPU1, информация IMPU1 и IMPU3 указывается в атрибуте Alias Identity для IMPU2, и информация IMPU1 и IMPU2 указывается в атрибуте Alias Identity для IMPU3.
Этап 1404: HSS представляет информацию ассоциации IMPU с эквивалентным поведением для S-CSCF посредством SP, несущего вышеупомянутое указание.
На этом этапе HSS передает XML, несущий SP, который указывает IMPU, имеющие поведение, эквивалентное каждому IMPU, для S-CSCF, и S-CSCF анализирует информацию ассоциации IMPU с эквивалентным поведением согласно принятому файлу XML.
Пример состоит в том, что IMPU1 и IMPU2 имеют эквивалентное поведение и IMPU3 и IMPU4 имеют эквивалентное поведение. Рассмотрим случай, когда существует IRPUIS, и множество IMPU с эквивалентным поведением является подмножеством IRPUIS. Если IMPU1, IMPU2, IMPU3 и IMPU4 находятся в одном и том же IRPUIS, когда S-CSCF запрашивает пользовательские данные IMPU1 от HSS посредством SAR, содержимое файла XML, переносимого в SAA, имеет следующий вид:
В вышеописанном файле XML Alias Identity в экземпляре класса Public Identity для IMPU1 несет информацию IMPU2, и Alias Identity в экземпляре класса Public Identity для IMPU2 несет информацию IMPU1. Аналогично, Alias Identity в экземпляре класса Public Identity для IMPU3 несет информацию IMPU4, и Alias Identity в экземпляре класса Public Identity для IMPU4 несет информацию IMPU3.
Когда S-CSCF принимает вышеописанный файл XML, она анализирует информацию ассоциации IMPU с эквивалентным поведением, т.е. IMPU1 и IMPU2 имеют эквивалентное поведение, и IMPU3 и IMPU4 имеют эквивалентное поведение, согласно указанию Alias Identity.
Выше подробно описан способ осуществления ассоциации идентичности согласно варианту осуществления.
Структура, отношение соединения и функция устройства согласно варианту осуществления такие же, как у устройства согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации в устройстве согласно варианту осуществления может быть таким же, как описано на этапах 1402-1404 на фиг. 14.
Кроме того, структура, отношение соединения и функция системы согласно варианту осуществления такие же, как у системы согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации HSS согласно варианту осуществления может быть таким же, как описано на этапах 1402-1404 на фиг. 14.
Шестой вариант осуществления: используется четвертый способ.
Этот вариант осуществления лучше подходит для случая наличия только одного множества IMPU с эквивалентным поведением. Обратимся к фиг. 16, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно шестому варианту осуществления изобретения. Согласно фиг. 16, последовательность действий включает в себя следующие этапы:
Этап 1601: ассоциирование пользовательских идентичностей на HSS.
Детальное осуществление этапа может быть таким же, как в описании первого или второго варианта осуществления. Оно также может принимать другой способ осуществления, который фактически требуется.
Этап 1602: HSS расширяет поле значения для IdentityType в классе Public Identity в SP, передаваемом на S-CSCF.
На этом этапе расширяется поле значения для IdentityType, и добавляется перечислительный тип. Исходный IdentityType имеет перечислительный тип и принимает значения 0, 1 и 2. Здесь 0 представляет IMPU, 1 представляет PSI и 2 представляет wildcarded PSI. Таким образом, согласно варианту осуществления, добавляется перечислительное значение 3, представляющее IMPU с эквивалентным поведением, на основании исходного IdentityType.
В конкретном осуществлении, если расширенный IdentityType называется Alias_Public_User_Identity, то реляционное отображение описания файла XML с расширенным IdentityType имеет вид, показанный в таблице 6.
0 (PUBLIC_USER_IDENTITY), представляет IMPU
1 (DISTINCT_PSI), представляет PSI
2 (WILDCARDED_PSI) представляет wildcarded PSI
3 (ALIAS_PUBLIC_USER_IDENTITY), представляет ALIAS_PUBLIC_USER_IDENTITY
Этап 1603: тип идентичности IMPU с эквивалентным поведением указывается с использованием значения расширенного IdentityType.
Если IMPU принадлежит множеству IMPU с эквивалентным поведением, значение 3 расширенного IdentityType можно использовать для указания, что тип идентичности IMPU является IMPU с эквивалентным поведением, т.е. именуемым ALIAS_PUBLIC_USER_IDENTITY в таблице 6.
Этап 1604: HSS представляет информацию ассоциации IMPU с эквивалентным поведением для S-CSCF посредством SP, несущего вышеупомянутое указание IdentityType.
На этом этапе HSS передает XML, несущий SP, который указывает множество IMPU с эквивалентным поведением, которому принадлежит IMPU, для S-CSCF, и S-CSCF анализирует информацию ассоциации IMPU с эквивалентным поведением согласно принятому файлу XML.
Пример состоит в том, что IMPU1 и IMPU2 имеют эквивалентное поведение и существует IRPUIS, и множество IMPU с эквивалентным поведением является подмножеством IRPUIS. Если IMPU1, IMPU2, IMPU3 и IMPU4 находятся в одном и том же IRPUIS. Когда S-CSCF запрашивает пользовательские данные IMPU1 от HSS посредством SAR, содержимое файла XML, переносимого в SAA, имеет следующий вид:
IMPU с эквивалентным поведением указываются путем установления типа IMPU с эквивалентным поведением, равным значению расширенного IdentityType. В вышеописанном файле XML, в экземпляре класса Public Identity для IMPU1, значение IdentityType равно 3; в экземпляре класса Public Identity для IMPU2, значение IdentityType равно 3, и это показывает, что IMPU1 и IMPU2 имеют эквивалентное поведение.
Когда S-CSCF принимает вышеописанный файл XML, она анализирует информацию ассоциации IMPU с эквивалентным поведением, т.е. IMPU1 и IMPU2 имеют эквивалентное поведение, согласно указанию значения IdentityType.
Выше подробно описан способ осуществления ассоциации идентичности согласно варианту осуществления.
Структура, отношение соединения и функция устройства согласно варианту осуществления такие же, как у устройства согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации в устройстве согласно варианту осуществления может быть таким же, как описано на этапах 1602-1604 на фиг. 16.
Кроме того, структура, отношение соединения и функция системы согласно варианту осуществления такие же, как у системы согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации HSS согласно варианту осуществления может быть таким же, как описано на этапах 1602-1604 на фиг. 16.
Седьмой вариант осуществления: используется пятый способ.
Этот вариант осуществления лучше подходит для случая наличия только одного множества IMPU с эквивалентным поведением среди IMPU, имеющих один и тот же SP. Обратимся к фиг. 17, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно седьмому варианту осуществления изобретения. Согласно фиг. 17 последовательность действий включает в себя следующие этапы:
Этап 1701: ассоциирование пользовательских идентичностей на HSS.
Детальное осуществление этапа может быть таким же, как в описании первого или второго варианта осуществления. Оно также может принимать другой способ осуществления, который фактически требуется.
Этап 1702: HSS расширяет класс Public Identity в SP, передаваемом на S-CSCF.
На этом этапе расширяется класс Public Identity и добавляется атрибут, указывающий, является ли IMPU идентификатором IMPU с эквивалентным поведением. Атрибут имеет логический тип (Boolean).
Когда значение атрибута равно «истина» (true) или больше нуля, это указывает, что IMPU имеет поведение, эквивалентное другим IMPU, значение атрибута которых также равно «истина» или больше нуля.
Когда значение атрибута равно «ложь» (false) равно нулю, это указывает, что IMPU не имеет поведения, эквивалентного какому-либо другому IMPU.
В этом варианте осуществления, когда HSS расширяет файл XML, относящийся к SP, переданному на S-CSCF, он может добавить атрибут, указывающий, является ли IMPU идентификатором IMPU с эквивалентным поведением в классе Public Identity в SP. Обратимся к фиг. 18, где схематически показана структура класса Public Identity согласно варианту осуществления, в которую добавлен атрибут, указывающий, является ли IMPU идентификатором IMPU с эквивалентным поведением.
В детальном осуществлении, если расширенный атрибут называется AliasIndicator, то реляционное отображение описания файла XML с расширенным классом Public Identity имеет вид, показанный в таблицах 7 и 8.
0 (PUBLIC_USER_IDENTITY), представляет IMPU
1 (DISTINCT_PSI), представляет PSI
2 (WILDCARDED_PSI), представляет wildcarded PSI
AliasIndicator
0 (ложь)
1 (истина)
В таблице 7 атрибут, указывающий, называется ли IMPU идентификатором IMPU с эквивалентным поведением AliasIndicator, и добавляется ли он в Тег, соответствующий типу данных tBool.
Атрибут, указывающий, называется ли IMPU идентификатором IMPU с эквивалентным поведением AliasIndicator, и тип которого задан как тип Boolean. Alias Identity Set Number получается путем расширения поля расширения, как показано в таблице 8.
Authorization
Extension
Extension
Extension2
Extension2
Из таблицы 8 следует, что AliasIndicator получается в поле расширения типа tPublicIdentityExtension2 в классе Public Identity. Экземпляр класса Public Identity включает в себя не более одного AliasIndicator. В отсутствие IMPU, имеющего поведение, эквивалентное IMPU в Public Identity, нет необходимости добавлять AliasIndicator к Public Identity.
Этап 1703: присвоение значения добавленного атрибута, который указывает, имеет ли каждый IMPU поведение, эквивалентное другим IMPU.
Этап 1704: HSS представляет информацию ассоциации IMPU с эквивалентным поведением для S-CSCF посредством SP, несущего вышеупомянутое указание.
На этом этапе HSS передает XML, несущий SP, который указывает, является ли каждый IMPU идентификатором IMPU, имеющим эквивалентное поведение, для S-CSCF, и S-CSCF анализирует информацию ассоциации IMPU с эквивалентным поведением согласно принятому файлу XML.
Пример состоит в том, что IMPU1 и IMPU2 имеют эквивалентное поведение и существует IRPUIS, и множество IMPU с эквивалентным поведением является подмножеством IRPUIS. Если IMPU1, IMPU2 и IMPU3 находятся в одном и том же IRPUIS и имеют один и тот же SP, когда S-CSCF запрашивает пользовательские данные IMPU1 от HSS посредством SAR, содержимое файла XML, переносимого в SAA, имеет следующий вид:
Имеет ли IMPU поведение, эквивалентное другим IMPU, указывается путем присвоения значения для AliasIndicator. В вышеописанном файле XML, в экземпляре класса Public Identity для IMPU1, значение AliasIndicator равно 1, и это указывает, что IMPU1 является IMPU, имеющим эквивалентное поведение; в экземпляре класса Public Identity для IMPU2, значение AliasIndicator равно 1, и это указывает, что IMPU2 является IMPU, имеющим эквивалентное поведение; в экземпляре класса Public Identity для IMPU3, не существует AliasIndicator, который указывает, что IMPU3 не является IMPU, имеющим эквивалентное поведение.
Когда S-CSCF принимает вышеописанный файл XML, она анализирует информацию ассоциации IMPU с эквивалентным поведением, т.е. IMPU1 и IMPU2 имеют эквивалентное поведение, и IMPU3 не имеют поведения, эквивалентного другим IMPU, согласно указанию AliasIndicator.
Выше подробно описан способ осуществления ассоциации идентичности согласно варианту осуществления.
Структура, отношение соединения и функция устройства согласно варианту осуществления такие же, как у устройства согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации в устройстве согласно варианту осуществления может быть таким же, как описано на этапах 1702-1704 на фиг. 17.
Кроме того, структура, отношение соединения и функция системы согласно варианту осуществления такие же, как у системы согласно третьему варианту осуществления за исключением того, что детальное осуществление модуля представления информации HSS согласно варианту осуществления может быть таким же, как описано на этапах 1702-1704 на фиг. 17. Процедура представления информации ассоциации IMPU с эквивалентным поведением для S-CSCF посредством HSS подробно представлена в вышеприведенном описании вариантов осуществления с третьего по седьмой.
Кроме того, S-CSCF может представлять информацию ассоциации IMPU, полученную от HSS, для UE, P-CSCF и AS.
Согласно уровню техники UE может получать информацию незапрещенных IMPU, которые принадлежат тому же IRPUIS, что и IMPU, зарегистрированный путем регистрации, и затем получать состояние регистрации всех незапрещенных IMPU, относящихся к пользователю, путем подписки на пакет событий от S-CSCF.
При регистрации UE, после загрузки пользовательских данных из HSS с использованием сообщения SAR, S-CSCF может узнать информацию IMPU с поведением, эквивалентным зарегистрированному пользователю. Поскольку пользователь подписывается на извещение о событии RegEvent после приема ответа 200 OK на запрос регистрации, таким образом, чтобы S-CSCF могла представлять информацию ассоциации IMPU для UE, подписанный пакет событий можно расширять, и информация передается на UE путем добавления информации в сообщение Notify для RegEvent. Здесь обмен сообщениями между S-CSCF и UE производится посредством интерфейса Gm. В дальнейшем способ будет подробно описан со ссылкой на варианты осуществления.
Восьмой вариант осуществления.
Обратимся к фиг. 19, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно восьмому варианту осуществления изобретения. Согласно фиг. 19 последовательность действий включает в себя следующие этапы:
Этап 1901: ассоциирование пользовательских идентичностей на HSS.
Детальное осуществление этапа может быть таким же, как в описании первого или второго варианта осуществления. Оно также может принимать другой способ осуществления, который фактически требуется.
Этап 1902: HSS представляет информацию ассоциации IMPU с эквивалентным поведением для S-CSCF.
На этом этапе HSS может представлять информацию ассоциации IMPU с эквивалентным поведением для S-CSCF, когда S-CSCF передает сообщение SAR и запрашивает загрузку пользовательских данных при регистрации UE.
Здесь детальное осуществление представления информации ассоциации IMPU с эквивалентным поведением для S-CSCF посредством HSS может быть таким же, как в описании любых вариантов осуществления с третьего по седьмой.
Этап 1903: UE передает подписку на извещение о событии на S-CSCF.
На этом этапе UE может передавать подписку на извещение о RegEvent на S-CSCF.
Этап 1904: S-CSCF расширяет подписанный пакет событий и несет информацию ассоциации IMPU с эквивалентным поведением в подписанном пакете событий и представляет его для UE.
На этом этапе S-CSCF расширяет подписанный пакет событий регистрации. Например, один или несколько элементов информации (IE) можно добавить к IE регистрации в файле XML для передачи, и IE могут включать в себя IMPU с поведением, эквивалентным каждому IMPU. Например, IE может именоваться Alias Identity.
Рассматривая фиг. 2 в качестве примера, если IMPU3 и IMPU4 на фиг. 2 являются IMPU с эквивалентным поведением согласно изобретению, когда IMPU3 и IMPU4 подписываются на извещение о RegEvent в ходе процедуры регистрации, S-CSCF передает сообщение Notify на UE, и сообщение несет информацию ассоциации каждого IMPU. Рассмотрим следующее:
В сообщении Notify можно видеть, что в IE регистрации для IMPU3 добавляется IE AliasIdentity, несущий IMPU4, и в IE регистрация для IMPU4 добавляется IE AliasIdentity, несущий IMPU3.
Получив сообщение Notify, UE может получать информацию ассоциации IMPU3 и IMPU4, имеющих эквивалентное поведение, из сообщения.
Выше подробно описан способ осуществления ассоциации идентичности согласно варианту осуществления изобретения.
Устройство для осуществления ассоциации идентичности согласно изобретению может быть таким же, как в описании любого устройства согласно вариантам осуществления с третьего по седьмой.
В дальнейшем будет подробно описана система для осуществления ассоциации идентичности согласно изобретению.
Обратимся к фиг. 20, где показана блок-схема системы для осуществления ассоциации идентичности согласно восьмому варианту осуществления изобретения. Согласно фиг. 20, на основании любого из вариантов осуществления системы с третьего по седьмой, система для осуществления ассоциации идентичности согласно варианту осуществления дополнительно включает в себя второй запрашивающий объект. Согласно варианту осуществления второй запрашивающий объект представляет собой UE.
Где S-CSCF дополнительно способна запрашивать подписку на извещение о событии у второго запрашивающего объекта и представлять информацию ассоциации IMPU с эквивалентным поведением второго запрашивающего объекта путем переноса информации ассоциации в подписанном пакете событий, согласно принятой подписке на извещение о событии. Согласно варианту осуществления второй запрашивающий объект представляет собой UE.
Второй запрашивающий объект способен передавать подписку на извещение о событии на S-CSCF, принимать пакет событий от S-CSCF и анализировать информацию ассоциации IMPU с эквивалентным поведением из принятого пакета событий. Согласно варианту осуществления второй запрашивающий объект представляет собой UE.
Кроме того, если AS также подписывается на извещение о событии RegEvent через подписку третьей стороны, при регистрации пользователя, S-CSCF также может представлять информацию ассоциации IMPU с эквивалентным поведением, полученную через SAA или PPR, для AS путем добавления информации ассоциации в сообщение Notify для RegEvent. Здесь обмен информацией между AS и S-CSCF осуществляется посредством интерфейса ISC.
Аналогично, P-CSCF также может подписываться на извещение о событии RegEvent от S-CSCF при регистрации пользователя, S-CSCF также может представлять информацию ассоциации IMPU с эквивалентным поведением, полученную через SAA или PPR, для P-CSCF путем добавления информации ассоциации в сообщение Notify для RegEvent. Здесь обмен информацией между P-CSCF и S-CSCF осуществляется посредством интерфейса Mw.
Здесь способы представления информации ассоциации IMPU с эквивалентным поведением для запрашивающих объектов UE и/или AS, и/или P-CSCF, осуществляемые S-CSCF, могут быть такими же, иначе говоря, детальное осуществление может быть таким же, как в описании восьмого варианта осуществления. Отличие состоит лишь в том, что информация ассоциации IMPU с эквивалентным поведением представляется разным запрашивающим объектам согласно разным запрашивающим объектам.
Соответственно в системе вторым запрашивающим объектом является AS или P-CSCF. Процедуры здесь не описаны подробно, поскольку они аналогичны друг другу.
Кроме того, согласно уровню техники, обмен информацией между AS и HSS может осуществляться посредством интерфейса Sh и т.д. AS может указывать информацию запроса публичной идентичности пользователя путем установления значения Data-Reference AVP для IMSPublicIdentity (10) в сообщении User-Data-Request (UDR). Затем HSS возвращает соответствующую публичную идентичность на AS в User-Data-Answer (UDA), согласно типу публичной идентичности, указанному в Identity-Set AVP в сообщении.
Кроме того, AS также может подписываться на информацию публичной идентичности путем установления значения Data-Reference AVP в качестве IMSPublicIdentity (10) в сообщении Subscribe-Notification-Request (SNR). При изменении публичной идентичности, HSS передает соответствующие данные на AS посредством сообщения Push-Notification-Request (PNR), согласно типу публичной идентичности, указанному в Identity-Set AVP. Альтернативно, запрашиваемая публичная идентичность сначала передается на AS посредством сообщения Subscribe-Notifications-Answer (SNA), затем соответствующие данные передаются на AS посредством сообщения PNR при изменении публичной идентичности.
На основании вышеописанной процедуры можно видеть, что HS возвращает соответствующую информацию публичной идентичности на AS согласно типу публичной идентичности, указанному посредством Identity-Set AVP в сообщении запроса, когда AS запрашивает информацию публичной идентичности от HSS.
Здесь, Identity-Set может принимать четыре значения: ALL_IDENTITIES (0), REGISTERED_DENTITIES (1), IMPLICIT_IDENTITIES (2) или ALIAS_IDENTITIES (3).
Когда значение равно ALL_IDENTITIES, HSS возвращает незапрещенные IMPU, соответствующие всем IMPI, связанным с IMPU в сообщении запроса, на AS. Когда значение равно REGISTERED_DENTITIES, HSS возвращает незапрещенные зарегистрированные IMPU, соответствующие всем IMPI, связанным с IMPU в сообщении запроса, на AS. Когда значение равно IMPLICIT_IDENTITIES, HSS возвращает незапрещенные IMPU, принадлежащие одному и тому же IRPUIS, в качестве IMPU в сообщении запроса, на AS. Когда значение равно ALIAS_IDENTITIES, HSS возвращает незапрещенные IMPU, имеющие один и тот же SP в IRPUIS для IMPU в сообщении запроса, на AS.
Согласно варианту осуществления изобретения, чтобы HSS мог представлять AS информацию ассоциации IMPU с эквивалентным поведением, AS может передавать на HSS запрос на IMPU с эквивалентным поведением, затем HSS представляет для AS незапрещенные IMPU с эквивалентным поведением в качестве IMPU в сообщении запроса, согласно запросу. Для этого значения Identity-Set можно расширять, каковая процедура будет описана ниже со ссылкой на вариант осуществления.
Девятый вариант осуществления.
Обратимся к фиг. 21, где показана логическая блок-схема способа осуществления ассоциации пользовательской идентичности согласно девятому варианту осуществления изобретения. Согласно фиг. 21 последовательность действий включает в себя следующие этапы:
Этап 2101: ассоциирование пользовательских идентичностей на HSS.
Детальное осуществление этапа может быть таким же, как в описании первого или второго варианта осуществления. Оно также может принимать другой способ осуществления, который фактически требуется.
Этап 2102: расширение значений Identity-Set и добавление значения, указывающего запрос на информацию об IMPU с эквивалентным поведением.
Этап 2103: AS передает запрос на IMPU с эквивалентным поведением на HSS.
На этом этапе AS может передавать запрос на информацию об IMPU на HSS с использованием сообщения UDR или SNR, и значение Identity-Set устанавливается равным ALIAS_GROUP_IDENTITIES (4) в сообщении. Таким образом, Identity-Set VAP используется для указания типа идентичности эквивалентного поведения.
Этап 2104: HSS представляет IMPU с поведением, эквивалентным IMPU в сообщении запроса, для AS.
На этом этапе HSS представляет для AS незапрещенные IMPU с поведением, эквивалентным IMPU в сообщении запроса, или информацию о соответствующих измененных IMPU, с использованием сообщения UDA, сообщения SNA или сообщения PNR.
Помимо сценария, описанного на фиг. 21, также можно предусмотреть сценарий, в котором значение Identity-Set повторно задано как ALIAS_IDENTITIES (3). Таким образом, ALIAS_IDENTITIES (3) используется для указания запроса на IMPU с эквивалентным поведением вместо запроса на IMPU с одним и тем же SP в IRPUIS. Таким образом, когда AS значение Identity-Set в сообщении запроса, передаваемого с AS на HSS, равно ALIAS_IDENTITIES (3), HSS может передавать незапрещенные IMPU с поведением, эквивалентным IMPU в сообщении запроса, на AS.
Выше подробно описан способ осуществления ассоциации идентичности согласно варианту осуществления.
Структура, отношение соединения и функция устройства согласно варианту осуществления такие же, как у устройства согласно третьему варианту осуществления за исключением того, что запрашивающий объект согласно варианту осуществления представляет собой AS. При этом детальное осуществление модуля представления информации в устройстве может быть таким же, как описано на этапах 2102-2104 на фиг. 21, или таким же, как в описании, где значение Identity-Set повторно задано как ALIAS_IDENTITIES (3).
Структура, отношение соединения и функция системы согласно варианту осуществления такие же, как у системы согласно третьему варианту осуществления за исключением того, что первый запрашивающий объект согласно варианту осуществления представляет собой AS. При этом детальное осуществление модуля представления информации на HSS может быть таким же, как описано на этапах 2102-2104 на фиг. 21, или таким же, как в описании, где значение Identity-Set повторно задано как ALIAS_IDENTITIES (3).
Вышеописанные детальные осуществления дополнительно описывают задачи, технические решения и преимущества изобретения. Следует понимать, что выше описаны лишь предпочтительные варианты осуществления изобретения, которые не призваны ограничивать объем раскрытия. Любые модификации, эквивалентные подстановки и усовершенствования в рамках сущности и объема раскрытия подлежат включению в объем раскрытия.
Изобретение относится к сетям передачи данных. Технический результат заключается в осуществлении ассоциации публичной пользовательской идентичности IMS (IMPU) с установленным эквивалентным поведением, что повышает удобство пользователя. Сущность изобретения заключается в том, что устанавливают идентификатор пользователя с эквивалентным поведением на домашнем сервере подписки (HSS); ассоциируют публичные пользовательские идентичности IMS (IMPU) с эквивалентным поведением через установленный идентификатор пользователя с эквивалентным поведением. Настоящее изобретение также предусматривает систему и устройство, осуществляющие ассоциацию пользовательской идентичности. 3 н. и 15 з.п. ф-лы, 21 ил., 8 табл.
1. Способ осуществления ассоциации пользовательской идентичности, содержащий этапы, на которых
устанавливают идентификатор пользователя с эквивалентным поведением на домашнем сервере подписки (HSS),
ассоциируют публичные пользовательские идентичности IMS (IMPU) с эквивалентным поведением через установленный идентификатор пользователя с эквивалентным поведением,
причем IMPU с эквивалентным поведением имеют один и тот же профиль услуги и одни и те же данные услуги.
2. Способ по п.1, в котором IMPU с эквивалентным поведением представляют собой IMPU с одним и тем же профилем услуги (SP) и одними и теми же данными услуги и принадлежат одному и тому же множеству неявно зарегистрированных публичных пользовательских идентичностей (IRPUIS).
3. Способ по п.1, в котором на этапе установления идентификатора пользователя с эквивалентным поведением на HSS
устанавливают на HSS указание, используемое для указания множества IMPU с эквивалентным поведением, или
устанавливают с помощью IMPU для HSS указание, используемое для указания множества IMPU с эквивалентным поведением, которому принадлежит IMPU, или
устанавливают с помощью IMPU для HSS указание, используемое для указания, что IMPU принадлежит множеству IMPU с эквивалентным поведением.
4. Способ по п.1, в котором способ дополнительно содержит этап, на котором представляют, посредством HSS, информацию
ассоциации IMPU с эквивалентным поведением для обслуживающей функции управления сеансами вызова (S-CSCF).
5. Способ по п.4, в котором на этапе представления, посредством HSS, информации ассоциации для S-CSCF
добавляют, посредством HSS, класс, указывающий псевдонимическую идентичность в SP, переданном на S-CSCF,
указывают, посредством добавленного класса, IMPU с эквивалентным поведением и
представляют, посредством HSS, информацию ассоциации для S-CSCF, посредством SP, несущего указание,
или
добавляют, посредством HSS, атрибут, указывающий множество IMPU, которому принадлежит IMPU, к классу публичная идентичность в SP, переданном на S-CSCF,
указывают множество IMPU с эквивалентным поведением, которому принадлежит каждый IMPU, путем присвоения значения атрибуту, и
представляют, посредством HSS, информацию ассоциации для S-CSCF, посредством SP, несущего указание,
или
добавляют, посредством HSS, класс, указывающий элементы множества, которому принадлежит IMPU, к классу публичная идентичность в SP, переданном на S-CSCF;
указывают IMPU с эквивалентным поведением каждому IMPU в добавленном классе и
представляют, посредством HSS, информацию ассоциации для S-CSCF, посредством SP, несущего указание,
или
расширяют, посредством HSS, поле значения атрибута тип идентичности (Identity Type) класса публичная идентичность в SP, переданном на S-CSCF, и указывают тип идентичности для IMPU с эквивалентным поведением с использованием значения расширенного Identity Type, и
представляют, посредством HSS, информацию ассоциации для S-CSCF, посредством SP, несущего указание типа идентичности,
или
добавляют, посредством HSS, атрибут, указывающий, принадлежит ли IMPU множеству IMPU с эквивалентным поведением к классу публичная идентичность в SP, переданном на S-CSCF,
указывают, принадлежит ли IMPU множеству IMPU с эквивалентным поведением, путем присвоения значения атрибуту и
представляют, посредством HSS, информацию ассоциации для S-CSCF, посредством SP, несущего указание.
6. Способ по п.1, в котором атрибут, используемый для указания множества, которому принадлежит IMPU, является Alias Identity Set Number.
7. Способ по п.5, в котором способ дополнительно содержит этапы, на которых
передают в S-CSCF, посредством запрашивающего объекта, подписку на извещение о событии и
представляют запрашивающему объекту, посредством S-CSCF, информацию ассоциации IMPU с эквивалентным поведением путем переноса информации ассоциации в подписанном пакете событий согласно подписанному извещению о событии.
8. Способ по любому из пп.1-3, причем способ дополнительно содержит этапы, на которых
запрашивают, посредством AS, IMPU с эквивалентным поведением у HSS и
представляют, посредством HSS, IMPU с эквивалентным поведением для AS согласно запросу.
9. Способ по п.8, в котором на этапе запроса у HSS, посредством AS, IMPU с эквивалентным поведением, указывают, посредством AS, тип идентичности эквивалентного поведения с использованием пары значений атрибута (AVP) Identity Set, несущей Identity Set AVP, указывающую тип идентичности эквивалентного поведения в сообщении запроса, и передают Identity Set AVP на HSS,
на этапе представления, посредством HSS, IMPU с эквивалентным поведением для AS согласно запросу представляют, посредством HSS, IMPU с эквивалентным поведением в качестве IMPU в сообщении запроса на AS, согласно типу идентичности эквивалентного поведения, указанному в сообщении запроса.
10. Способ по п.9, в котором, когда значение Identity Set AVP равно ALIAS_IDENTITIES, Identity Set AVP указывает тип IMPU, запрашивающих эквивалентное поведение.
11. Способ по п.1, в котором способ дополнительно содержит этап, на котором включают информацию ассоциации IMPU с эквивалентным поведением в информацию услуги начальных критериев фильтра (iFC), относящихся к IMPU, на HSS.
12. Способ по п.11, причем способ дополнительно содержит этапы, на которых запрашивают, посредством S-CSCF,
пользовательские данные у HSS и загружают iFC с информацией услуги, которая содержит информацию ассоциации IMPU с эквивалентным поведением, из HSS, и представляют информацию услуги, включающую в себя информацию ассоциации IMPU с эквивалентным поведением, для AS путем переноса информации услуги в сообщении, при выполнении iFC.
13. Способ по п.1, в котором способ дополнительно содержит этап, на котором
сохраняют, посредством HSS, информацию ассоциации IMPU с эквивалентным поведением.
14. Устройство для осуществления ассоциации пользовательской идентичности, содержащее модуль установления указания и модуль представления указания, в котором
модуль установления указания выполнен с возможностью установления идентификатора пользователя с эквивалентным поведением на HSS и
модуль представления указания выполнен с возможностью ассоциирования IMPU с эквивалентным поведением с использованием идентификатора пользователя с эквивалентным поведением, установленного модулем установления указания,
причем IMPU с эквивалентным поведением имеют один и тот же профиль услуги и одни и те же данные услуги.
15. Устройство по п.14, в котором устройство дополнительно содержит модуль представления информации,
причем модуль представления указания обеспечивает информацию указанных IMPU с эквивалентным поведением для модуля представления информации, и
модуль представления информации выполнен с возможностью представления информации ассоциации IMPU с эквивалентным поведением запрашивающему объекту, согласно информации указанных IMPU с эквивалентным поведением, обеспеченной модулем представления указания.
16. Система для осуществления ассоциации пользовательской идентичности, содержащая домашний сервер подписки (HSS) и первый запрашивающий объект, в которой
HSS выполнен с возможностью ассоциирования IMPU с эквивалентным поведением и передачи информации ассоциации IMPU с эквивалентным поведением на первый запрашивающий объект путем переноса информации в сообщении, причем IMPU с эквивалентным поведением имеют один и тот же профиль услуги и одни и те же данные услуги, и
первый запрашивающий объект выполнен с возможностью анализа сообщения от HSS и получения информации ассоциации IMPU с эквивалентным поведением из сообщения.
17. Система по п.16, в которой HSS содержит модуль представления указания и модуль представления информации, причем
модуль представления указания выполнен с возможностью ассоциирования IMPU с эквивалентным поведением и обеспечения информации указанных IMPU с эквивалентным поведением для модуля представления информации, и
модуль представления информации выполнен с возможностью представления информации ассоциации IMPU с эквивалентным поведением запрашивающему объекту, согласно информации указанных IMPU с эквивалентным поведением, обеспеченной модулем представления указания.
18. Система по п.16 или 17, в которой первый запрашивающий объект является S-CSCF,
причем система дополнительно содержит второй запрашивающий объект,
причем S-CSCF дополнительно выполнена с возможностью приема подписки на извещение о событии от второго запрашивающего объекта и представления информации ассоциации IMPU с эквивалентным поведением второму запрашивающему объекту путем переноса информации ассоциации в подписанном пакете событий, согласно подписке на извещение о событии, и
второй запрашивающий объект выполнен с возможностью передачи подписки на извещение о событии в S-CSCF, приема пакета событий от S-CSCF и анализа информации ассоциации IMPU с эквивалентным поведением из принятого пакета событий.
| WO 03005669 A1, 16.01.2003 | |||
| RU 2006109469 A, 10.07.2006 | |||
| СПОСОБ СТАБИЛИЗАЦИИ ЛЕЙКОЗНОГО ПРОЦЕССА | 2010 |
|
RU2425685C1 |
| US 2004230697 A1, 18.11.2004 | |||
| WO 2006082528 A2, 10.08.2006 | |||
| Сырьевая смесь для производства огнеупорного бетона | 1980 |
|
SU943214A1 |
| CN 1852293 A, 25.10.2006. | |||
