Управление профилями услуг в ims
Изобретение относится к системе IP-мультимедиа. Технический результат заключается в повышении эффективности использования ресурсов системы. Домашний сервер абонентов для управления подписками подсистемы мультимедиа IP содержит средство для поддержки ассоциаций между публичными идентификационными информациями пользователя и профилями услуг, где две или более публичных идентификационных информаций пользователя могут быть ассоциированными с общим профилем услуги, и средство для идентификации для сетевого узла всех публичных идентификационных информаций пользователя, которые ассоциированы с общим профилем услуги. 11 н. и 22 з.п. ф-лы, 9 ил.
Область техники
Изобретение относится к способу и устройству для управления профилями услуг в подсистеме мультимедиа IP.
Уровень техники
Подсистема мультимедиа IP (IMS) - это технология, определенная проектом партнерства третьего поколения (3GPP), чтобы предоставлять мультимедийные услуги IP через сети мобильной связи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329 выпуск 5 и выпуск 6). IMS предоставляет ключевые функциональные возможности, чтобы предоставить конечному пользователю возможности персональной связи от пользователя к пользователю посредством интеграции и взаимодействия услуг. IMS обеспечивает новые широкие возможности связи между пользователями (клиент-клиент), а также связи пользователь-контент (клиент-сервер) через сеть, базирующуюся на IP. IMS использует протокол установления сеансов связи (SIP), чтобы устанавливать и управлять вызовами или сеансами между пользовательскими терминалами (UE) или между терминалами UE и серверами приложений (AS). Протокол описания сеанса (SDP), переносимый посредством сигнализации SIP, используется, чтобы описывать и согласовывать компоненты среды сеанса. В то время как SIP был создан как протокол для связи пользователь-пользователь, IMS позволяет операторам и поставщикам услуг управлять доступом пользователей к услугам и взимать платежи с пользователей, соответственно.
Фиг.1 схематически показывает архитектуру 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, используя определенный метод SIP REGISTER. Это механизм для присоединения к IMS и объявления подсистеме IMS адреса, по которому может быть получена идентификационная информация пользователя SIP. В 3GPP, когда терминал SIP выполняет регистрацию, IMS аутентифицирует пользователя и назначает S-CSCF этому пользователю из набора доступных функций S-CSCF. Пока критерии для назначения функций S-CSCF не определены проектом 3GPP, они могут включать в себя требования к распределению нагрузки и услугам. Следует отметить, что назначение S-CSCF является ключом к управлению доступом пользователя к базирующимся на IMS услугам и соответствующему взиманию платы. Операторы могут предоставлять механизм для предотвращения прямых сеансов SIP между пользователями, которые в противном случае будут обходить S-CSCF.
В течение процесса регистрации функция I-CSCF выбирает функцию S-CSCF, если какая-либо функция S-CSCF еще не выбрана. I-CSCF принимает требуемые возможности функции S-CSCF от домашнего сервера абонентов домашней сети (HSS) и выбирает соответствующую S-CSCF, базируясь на принятых возможностях. Следует заметить, что назначение S-CSCF также определяется для пользователя функцией I-CSCF, если пользователь вызывается другой стороной, и пользователю в текущее время не назначена какая-либо S-CSCF. Когда зарегистрированный пользователь впоследствии посылает запрос сеанса к IMS, P-CSCF способна передать запрос выбранной S-CSCF, базируясь на информации, принятой от S-CSCF в течение процесса регистрации.
Каждый пользователь IMS имеет одну или более закрытую идентификационную информацию пользователя. Закрытая идентификационная информация пользователя назначается оператором домашней сети и используется подсистемой IMS, например, для регистрации, авторизации, администрирования и целей учета. Эта идентификационная информация имеет форму идентификатора сетевого доступа (NAI), как определено в RFC 2486. Представление идентификационной информации международного мобильного абонента (IMSI) может содержаться NAI для закрытой идентификационной информации. 3GPP TS 23.228 определяет следующие свойства закрытой идентификационной информации пользователя:
- Закрытая идентификационная информация пользователя не используется для маршрутизации сообщений SIP.
- Закрытая идентификационная информация пользователя должна содержаться во всех запросах регистрации (включая сюда запросы повторной регистрации и отмены регистрации), передаваемых от UE домашней сети.
- Приложение модуля идентификационной информации услуг мультимедиа IP (ISIM) должно защищенным образом хранить одну закрытую идентификационную информацию пользователя. Не должно быть возможным для UE модифицировать информацию закрытой идентификационной информации пользователя, сохраненную в приложении ISIM.
- Закрытая идентификационная информация пользователя является уникальной глобальной идентификационной информацией, определенной оператором домашней сети, которая может использоваться внутри домашней сети, чтобы идентифицировать подписку пользователя (например, возможность услуги IM) с точки зрения сети. Закрытая идентификационная информация пользователя идентифицирует подписку, а не пользователя.
- Закрытая идентификационная информация пользователя должна быть постоянно назначена подписке пользователя (она не является динамической идентификационной информацией) и является действительной в течение продолжительности подписки пользователя в домашней сети.
- Закрытая идентификационная информация пользователя используется, чтобы идентифицировать информацию пользователя (например, информацию аутентификации), сохраненную внутри HSS (для использования, например, в течение регистрации).
- Закрытая идентификационная информация пользователя может быть представлена в записях взимания оплаты на основе стратегии оператора.
- Закрытая идентификационная информация пользователя аутентифицируется только в течение регистрации пользователя (включая сюда повторную регистрацию и отмену регистрации).
- HSS должен хранить закрытую идентификационную информацию пользователя.
- S-CSCF должна получать и хранить закрытую идентификационную информацию пользователя после регистрации и незарегистрированного завершения.
В дополнение к закрытой идентификационной информации пользователя каждый пользователь IMS должен иметь одну или более публичных идентификационных информаций пользователя IMS (IMPU). Информации IMPU используются любым пользователем, чтобы запрашивать связь с другими пользователями. Пользователь может, например, включать IMPU (но не закрытую идентификационную информацию пользователя) в визитную карточку. 3GPP TS 23.228 определяет следующие свойства информации IMPU:
- Как схема назначения номеров телефонной связи, так и схема назначения имен сети Интернет могут использоваться, чтобы адресовать пользователей в зависимости от IMPU, которые пользователи имеют.
- Информация (информации) IMPU должна принимать форму SIP URI (как определено в RFC 3261 и RFC 2396) или формат "tel:"-URI, определенный в RFC 3966.
- Приложение ISIM должно защищенным образом хранить, по меньшей мере, одну IMPU (UE не должно иметь возможности модифицировать IMPU), но не требуется, чтобы все дополнительные IMPU хранились в приложении ISIM.
- IMPU должна регистрироваться либо явно, либо неявно, прежде чем идентификационная информация сможет использоваться для инициирования сеансов IMS и процедур, не связанных с сеансами IMS.
- IMPU должна регистрироваться либо явно, либо неявно, прежде чем завершаемые сеансы IMS и процедуры, не связанные с завершаемыми сеансами IMS, смогут доставляться терминалу UE пользователя, которому принадлежит IMPU.
- Должна иметься возможность глобальной регистрации (т.е. посредством одного единичного запроса UE) пользователя, который имеет более чем одну IMPU, посредством механизма IMS (например, посредством использования набора неявной регистрации). Это не должно препятствовать индивидуальной регистрации пользователем какой-либо информации IMPU, если нужно.
- Информации IMPU не аутентифицируются сетью в течение регистрации.
- Информации IMPU могут использоваться, чтобы идентифицировать информацию пользователя на сервере HSS (например, в течение установки сеанса связи с мобильным терминалом).
- Информации IMPU могут использоваться серверами AS IMS, чтобы идентифицировать данные конфигурации услуги, которые должны применяться к пользователю.
Фиг.2 схематически показывает иллюстративные отношения между подпиской пользователя (IMS) и публичными и закрытыми идентификационными информациями пользователя. В показанном примере абонент имеет две закрытые идентификационные информации пользователя, причем обе ассоциированы с двумя публичными идентификационными информациями пользователя (одна из публичных идентификационных информаций пользователя, публичная идентификационная информация-2 пользователя ассоциирована с обеими закрытыми идентификационными информациями пользователя). Профиль услуги ассоциирован с каждой публичной идентификационной информацией пользователя, причем этот профиль определяет данные услуги для ассоциированных публичных идентификационных информаций пользователя. Профиль услуги создается или модифицируется, когда сервер приложений предоставляется для пользователя в домашнем сервере абонентов. Каждый профиль услуги содержит один или более начальных критериев фильтра (iFC), которые используются, чтобы включать предоставление или ограничение услуг IMS. Различия между услугами, предлагаемыми профилем-1 услуги и профилем-2 услуги, зависят от оператора, но могут включать в себя разные серверы приложений (AS) и даже разные схемы взимания платежей/определения стоимости.
В этом примере публичная идентификационная информация-1 пользователя ассоциирована с профилем-1 услуги, в то время как публичная идентификационная информация-2 пользователя и публичная идентификационная информация-3 пользователя ассоциированы с профилем-2 услуги. В обычном сценарии публичная идентификационная информация-1 пользователя может быть идентификационной информацией, которую пользователь дает друзьям и семье, например, "Big_Joe@priv.operator.com", в то время как публичная идентификационная информация-2 пользователя и публичная идентификационная информация-3 пользователя могут быть идентификационными информациями, которые пользователь дает для деловых контактов, например, "+46111222333@operator.com" и "joe.black@operator.com".
В сети услуг IMS серверы приложений (AS) предоставляются для реализации функциональности услуг IMS. Для любого заданного UE один или более серверов AS могут ассоциироваться с этим терминалом. Фиг.3a показывает интерфейс управления услугами IMS (ISC) между AS и S-CSCF и другие интерфейсы IMS. Хотя AS на фиг.3a показан как имеющий только единичный интерфейс с S-CSCF, следует принять во внимание, что на практике интерфейс ISC будет обеспечивать взаимодействие во всей сети связи, к которой подключены многие (или все) из серверов CSCF сети заданного оператора, позволяя AS осуществлять связь со всеми из этих функций CSCF. [Другие объекты, показанные на фиг.3a, должны быть хорошо известны специалистам в данной области техники.]
Между AS и UE (TS23.002) существует дополнительный интерфейс (Ut), как показано на фиг.3b. Интерфейс Ut позволяет пользователю управлять информацией, относящейся к его услугам, например, созданию и назначению публичных идентификационных информаций услуг, управлению стратегией авторизации, используемой, например, услугами "присутствие", конференции, управлением стратегией и т.д.
Сущность изобретения
Согласно TS 23.228 ассоциация между информациями IMPU и профилями услуг, и, в частности, привязка многочисленных информаций IMPU к единичному профилю услуги, известна домашнему серверу абонентов (HSS). Однако эта привязка указывает только информации IMPU, которые совместно используют один и тот же набор критериев фильтра; медиа-данные по подписке и т.д., и не предоставляет никакого указания относительно общих профилей пользователя, сохраненных вне HSS (например, в серверах приложений), и не делает никаких предположений относительно отношений между информациями IMPU, которые совместно используют один и тот же профиль услуги (т.е. являются ли они "альтернативными" или нет).
Изобретатели исходили из того, что объектам, другим нежели HSS и S-CSCF, включая сюда любой сервер (серверы) приложений, ассоциированный с UE, и сам UE, не предоставляется информация, связывающая профили услуг с информациями IMPU, но все же эти другие объекты могут использовать упомянутую информацию. Например, сервер приложений может связать вместе информацию конфигурации услуги, ассоциированную с двумя информациями IMPU, на основе этих двух информаций IMPU, совместно использующих единичный профиль услуги.
В примере, описанном выше со ссылкой на фиг.2, публичная идентификационная информация-1 пользователя ассоциирована с персональным профилем некоммерческого использования, а публичная идентификационная информация-2 пользователя и публичная идентификационная информация-3 пользователя предназначены для коммерческих целей, и ожидается, что они имеют одни и те же данные конфигурации услуги. Необходимо рассматривать действия и данные, относящиеся к публичной идентификационной информации-1 пользователя, иначе, чем действия и данные, относящиеся к публичной идентификационной информации-2 пользователя или публичной идентификационной информации-3 пользователя, при рассмотрении действий и данных, ассоциированных с публичной идентификационной информацией-2 пользователя и публичной идентификационной информацией-3 пользователя, одинаковым образом. Поэтому, например, инициирование сеансов и завершение сеансов для публичной идентификационной информации-2 пользователя и публичной идентификационной информации-3 пользователя рассматриваются таким же образом, как данные добавочных настроек услуг, такие как "не беспокоить" для базирующейся на IMS услуги многоточечной полудуплексной связи в сети сотовой связи (PoC), или допущение в мультимедийной телефонии переадресации вызова.
Не имея знания, что множество информаций IMPU ассоциированы, сервер приложений должен хранить в своей памяти конфигурацию услуги для каждой IMPU. Это имеет серьезное влияние на требования к памяти, когда большие количества, например, миллионы, информаций IMPU являются активными. Аналогично, если UE не имеет этого знания, терминал не будет знать, например, должна ли операция по интерфейсу Ut повторяться для каждого публичного идентификатора пользователя. Там где пользователь обновляет номер переадресации вызова через интерфейс Ut для мультимедийной телефонии, терминал не имеет достаточной информации в отношении того, для каких информаций IMPU он должен делать это, например, влечет ли обновление номера переадресации вызова для публичной идентификационной информации-3 пользователя, что он автоматически обновляется для публичной идентификационной информации-2 пользователя, или должен ли терминал также посылать запросы интерфейса Ut для публичной идентификационной информации-2 пользователя: это неправильное понимание может вызвать проблемы при некоторых запросах интерфейса Ut, таких как добавление пользователя к группе (на уровне приложения), в случае, когда сеть и UE имеют разное понимание.
Для в текущее время определенных выпусков 3GPP объекты IMS (включающие в себя терминалы UE) предполагают, что все информации IMPU рассматриваются независимо.
Целью настоящего изобретения является предоставить средство для информирования объектов, других нежели HSS, об отношениях между информациями IMPU и профилями услуг.
Согласно первому аспекту настоящего изобретения предоставляется домашний сервер абонентов для управления подписками подсистемы мультимедиа IP, и содержащий:
средство для поддержания ассоциаций между публичными идентификационными информациями пользователя и профилями услуг, причем две или более публичных идентификационных информаций пользователя могут быть ассоциированными с общим профилем услуги; и
средство для идентификации для сетевого узла всех публичных идентификационных информаций пользователя, которые ассоциированы с общим профилем услуги.
Варианты осуществления настоящего изобретения обеспечивают как уменьшение требований к памяти в сервере приложений SIP или другом сетевом узле, так и уменьшение нагрузки сигнализации в подсистеме мультимедиа IP и ассоциированных сетях.
Предпочтительно, упомянутое средство для идентификации посылает уведомление сетевому узлу в ответ на процедуру регистрации или повторной регистрации, завершения вызова или изменение контента в профиле услуги.
Предпочтительно, упомянутое средство для идентификации для сетевого узла всех публичных идентификационных информаций пользователя, ассоциированных с общим профилем услуги, содержит средство для отправки сообщения сетевому узлу, содержащего один или более профилей услуг, причем каждый профиль услуги идентифицирует все публичные идентификационные информации пользователя, с которыми он ассоциирован.
Согласно одному варианту осуществления настоящего изобретения упомянутое сообщение также содержит, вне профилей услуг, набор публичных идентификационных информаций пользователя, принадлежащих общему набору неявной регистрации.
Согласно одному варианту осуществления настоящего изобретения упомянутое сообщение идентифицирует один или более профилей услуг, содержащихся в сообщении, причем публичные идентификационные информации пользователя каждого идентифицированного профиля услуги рассматриваются как альтернативные публичные идентификационные информации пользователя.
Термин "альтернативный", как здесь используется, рассматривается как термин данной области техники. Это означает, что использование или указание на одну из альтернативных публичных идентификационных информаций пользователя IMS является также использованием или указанием на другую альтернативную публичную идентификационную информацию (информации) пользователя, т.е. поведение сети является, как правило, идентичным для всех альтернативных идентификационных информаций. Например, запрос изменения данных/конфигурации услуги, посланный серверу приложений в отношении одной альтернативной публичной идентификационной информации пользователя IMS, должен рассматриваться как запрос изменения также для другой альтернативной публичной идентификационной информации (информаций) пользователя. Конечно, могут иметься исключительные случаи, где изменение данных/конфигурации услуги является подходящим только для одной альтернативной публичной идентификационной информации (информаций) пользователя, например, удаление одной альтернативной публичной идентификационной информации (информаций) пользователя из сети или изменение назначенного профиля услуги для альтернативной публичной идентификационной информации пользователя IMS.
Упомянутый сетевой узел может быть обслуживающей функцией управления вызовами и сеансами.
Упомянутое средство для идентификации может передавать требуемую информацию обслуживающей функции управления вызовами и сеансами в ответе назначения сервера Cx или сообщении запроса профиля передачи.
Согласно второму аспекту настоящего изобретения предоставляется домашний сервер абонентов для управления подписками подсистемы мультимедиа IP, и содержащий:
средство для поддержки группирований публичных идентификационных информаций пользователя, которые должны рассматриваться как альтернативные публичные идентификационные информации пользователя; и
средство для отправки сетевому узлу идентификации групп альтернатив.
Предпочтительно, упомянутое средство для отправки сетевому узлу идентификации групп альтернатив посылает эту информацию в ответ на процедуру регистрации или повторной регистрации, завершения вызова или изменение контента в профиле услуги.
Упомянутый сетевой узел может быть обслуживающей функцией управления вызовами и сеансами или сервером приложений.
Согласно третьему аспекту настоящего изобретения предоставляется функция управления вызовами и сеансами для обслуживания пользователя в сети подсистемы мультимедиа IP, причем функция управления вызовами и сеансами содержит:
средство для приема от домашнего сервера абонентов сообщения, содержащего один или более профилей услуг, причем этот или каждый профиль услуги идентифицирует все публичные идентификационные информации пользователя, с которыми профиль услуги ассоциирован; и
средство для ассоциирования публичных идентификационных информаций пользователя, по меньшей мере, одного профиля услуги как альтернативных публичных идентификационных информаций пользователя.
Упомянутая функция управления вызовами и сеансами может содержать средство для идентификации публичных идентификационных информаций пользователя, принадлежащих набору неявной регистрации, использующему список публичных идентификационных информаций пользователя, содержащийся вне принятого профиля (профилей) услуги.
Упомянутая функция управления вызовами и сеансами может содержать средство для идентификации профилей услуг, к которым должна применяться ассоциация альтернатив.
Предпочтительно, упомянутая функция управления вызовами и сеансами содержит средство для отправки уведомления пользовательскому терминалу или сетевому узлу, идентифицирующего публичные идентификационные информации пользователя, идентифицированные как альтернативные публичные идентификационные информации пользователя.
Упомянутая функция управления вызовами и сеансами может быть обслуживающей функцией управления вызовами и сеансами.
Согласно четвертому аспекту настоящего изобретения предоставляется сервер приложений для исполнения услуг в сети подсистемы мультимедиа IP, причем сервер приложений содержит:
средство для приема от обслуживающей функции управления вызовами и сеансами или домашнего сервера абонентов уведомления, что две или более публичных идентификационных информаций пользователя рассматриваются как альтернативные публичные идентификационные информации пользователя.
Согласно пятому аспекту настоящего изобретения предоставляется пользовательский терминал, предназначенный для обеспечения пользователю доступа к сети подсистемы мультимедиа IP, причем пользовательский терминал содержит:
средство для приема от сети подсистемы мультимедиа IP уведомления, что две или более публичных идентификационных информаций пользователя терминала рассматриваются как альтернативные публичные идентификационные информации пользователя.
Предпочтительно, упомянутое средство выполняется с возможностью при использовании принимать упомянутое уведомление от обслуживающей функции управления вызовами и сеансами.
Согласно шестому аспекту настоящего изобретения предоставляется способ управления подсистемой мультимедиа IP, чтобы информировать сетевые узлы и/или пользовательские терминалы о публичных идентификационных информациях пользователя, чтобы они рассматривались как альтернативные публичные идентификационные информации пользователя, причем способ содержит:
поддержку в домашнем сервере абонентов группирований публичных идентификационных информаций пользователя, чтобы они рассматривались как альтернативные публичные идентификационные информации пользователя; и
распределение информации группирований сетевым узлам и/или пользовательским терминалам.
Предпочтительно, упомянутые группирования поддерживаются в профилях услуг как публичные идентификационные информации пользователя, ассоциированные с профилями услуг.
Предпочтительно, упомянутый способ содержит отправку от домашнего сервера абонентов к обслуживающей функции управления вызовами и сеансами сообщения, содержащего один или более профилей услуг, причем этот или каждый профиль услуги идентифицирует все публичные идентификационные информации пользователя, ассоциированные с профилем услуги, и обслуживающая функция управления вызовами и сеансами идентифицирует все публичные идентификационные информации пользователя, ассоциированные с, по меньшей мере, одним профилем услуги, как альтернативные публичные идентификационные информации пользователя.
Упомянутое сообщение может быть ответом назначения сервера Cx или сообщением запроса профиля передачи.
Обслуживающая функция управления вызовами и сеансами может информировать сервер приложений или пользовательский терминал о группе публичных идентификационных информаций пользователя, которые должны рассматриваться как альтернативные публичные идентификационные информации пользователя.
Публичные идентификационные информации пользователя, принадлежащие набору неявной регистрации, могут перечисляться в упомянутом сообщении, но вне профиля (профилей) услуги.
Сообщение может идентифицировать те профили услуг, для которых ассоциированные публичные идентификационные информации пользователя должны рассматриваться как альтернативные публичные идентификационные информации пользователя.
Упомянутый этап распределения может выполняться в течение или после регистрации пользовательского терминала в подсистеме мультимедиа IP, или при или после завершения вызова к пользовательскому терминалу, или при изменении контента профиля услуги.
Упомянутый этап распределения может содержать отправку информации группирований серверу приложений через интерфейс Sh.
Пользовательский терминал может уведомляться, что две или более из его публичных идентификационных информаций пользователя являются альтернативными публичными идентификационными информациями пользователя, посредством сигнализации, посылаемой от сервера приложений через интерфейс Ut.
Согласно седьмому аспекту настоящего изобретения предоставляется способ управления пользовательским терминалом, сконфигурированным для использования с подсистемой мультимедиа IP, причем способ содержит:
прием от подсистемы уведомления, что две или более публичных идентификационных информаций пользователя терминала должны рассматриваться как альтернативные публичные идентификационные информации пользователя.
Согласно восьмому аспекту настоящего изобретения предоставляется сервер приложений протокола установления сеансов связи подсистемы мультимедиа IP, причем способ содержит:
прием от обслуживающей функции управления вызовами/сеансами или сервера домашних абонентов уведомления, что две или более публичных идентификационных информаций пользователя должны рассматриваться как альтернативные публичные идентификационные информации пользователя, с целью управления конфигурациями услуги.
Согласно девятому аспекту настоящего изобретения предоставляется способ управления домашним сервером абонентов в подсистеме мультимедиа IP, причем способ содержит:
поддержку в домашнем сервере абонентов группирований публичных идентификационных информаций пользователя, которые должны рассматриваться как альтернативные публичные идентификационные информации пользователя; и
распределение информации группирований сетевым узлам и/или пользовательским терминалам.
Согласно десятому аспекту настоящего изобретения предоставляется подсистема мультимедиа IP, содержащая:
домашний сервер абонентов, выполненный с возможностью поддерживать группирования публичных идентификационных информаций пользователя, которые должны рассматриваться как альтернативные публичные идентификационные информации пользователя, и имеющий средство, выполненное с возможностью, в течение или после регистрации пользовательского терминала в подсистеме мультимедиа IP, или при или после завершения вызова к пользовательскому терминалу, информировать терминал и/или сетевой узел о группировании, содержащем публичную пользовательскую идентификационную информацию терминала или пользователя терминала.
Краткое описание чертежей
Фиг.1 схематически показывает архитектуру подсистемы мультимедиа IP.
Фиг.2 схематически показывает иллюстративные отношения между подпиской IMS пользователя и публичными и закрытыми идентификационными информациями пользователя.
Фиг.3a и 3b схематически показывают некоторые объекты подсистемы мультимедиа IP, включая сервер приложений и обслуживающую функцию управления вызовами/сеансами.
Фиг.4 схематически показывает структуру профиля услуги.
Фиг.5 схематически показывает, как данные профиля услуги загружаются в обслуживающую функцию управления вызовами/сеансами.
Фиг.6 схематически показывает структуру пользовательских данных, переносимых по интерфейсу Cx.
Фиг.7 схематически показывает отношение и интерфейсы между объектами подсистемы мультимедиа IP.
Фиг.8 схематически показывает структуру профиля услуги согласно одному варианту осуществления настоящего изобретения.
Подробное описание некоторых вариантов осуществления
Как уже было описано, архитектура подсистемы мультимедиа IP (IMS) идентифицирует пользователей IMS, используя закрытые идентификационные информации пользователя. Это закрытая идентификационная информация пользователя, которая используется, чтобы аутентифицировать пользователя при начальной регистрации в IMS. Местоположение пользователя, с другой стороны, идентифицируется одной или более публичными идентификационными информациями пользователя IMS (IMPU), именно эта информация IMPU используется третьими сторонами, чтобы осуществлять контакты с владельцем IMPU. На домашнем сервере абонентов (HSS), расположенном в домашней сети (например, базовой сети 3G), каждая IMPU ассоциирована с некоторым профилем услуги. Профиль услуги содержит данные услуги для этих информаций IMPU, включая в себя набор начальных критериев фильтра (iFC), которые используются, чтобы включать предоставление или ограничение услуг IMS. 3GPP определяет структуру профиля услуги, показанную на фиг.4, и показывает способ, которым эти данные загружаются в функцию S-CSCF, как показано на фиг.5 и 6. Дополнительные детали могут быть найдены в TS 29.228 и TS 29.229.
Внутри HSS одна или более информаций IMPU могут ассоциироваться с одним и тем же профилем услуги. Информации IMPU, ассоциированные с одним и тем же профилем услуги, указываются здесь как "альтернативные" информации IMPU. 3GPP предписывает, чтобы всякий раз, когда пользователь регистрируется в сети IMS с некоторой IMPU, HSS посылал функции S-CSCF профиль услуги, ассоциированный с этой IMPU. 3GPP дополнительно предписывает, чтобы всякий раз, когда незарегистрированный пользователь принимает терминирующий вызов от сети IMS, HSS посылал функции S-CSCF профиль услуги, ассоциированный с IMPU вызванного пользователя. Всякий раз, когда профиль услуги модифицируется в HSS, HSS должен посылать модифицированный профиль услуги функции S-CSCF для каждой ассоциированной IMPU.
3GPP определяет так называемое понятие "набор неявной регистрации", чтобы идентифицировать набор информаций IMPU, которые работают как группа, и которые регистрируются и отменяют регистрацию вместе, когда какая-либо из информаций IMPU из набора регистрируется или отменяет регистрацию. 3GPP предписывает, чтобы HSS посылал набор неявной регистрации функции S-CSCF при регистрации пользователя или при завершении вызова. Понятно, что (при регистрации или завершении вызова) HSS идентифицирует все информации IMPU в наборе неявной регистрации и затем идентифицирует все профили услуг, ассоциированные с этими информациями IMPU. Профили услуг (или выбранные данные из профилей услуг), содержащие информации IMPU, с которыми они ассоциированы, затем посылаются функции S-CSCF. Это показано на фиг.6. Как результат этой операции, S-CSCF знает все информации IMPU, которые принадлежат одному и тому же набору неявной регистрации, также как их профили услуг.
Как уже было отмечено, факт, что две или более информации IMPU ассоциированы с единичным профилем услуги (внутри HSS), может использоваться, чтобы ассоциировать данные конфигурации услуги для этих информаций IMPU в других сетевых узлах или в пользовательском терминале (UE). Можно представить, что понятие набора неявной регистрации предоставляет соответствующее транспортное средство для распределения ассоциаций между информациями IMPU и профилями услуг через IMS (по меньшей мере, между HSS и S-CSCF). Однако такой подход будет использовать счетчик для предполагаемой цели набора неявной регистрации, т.е. чтобы неявно регистрировать некоторое количество информаций IMPU независимо от профилей услуг, с которыми информации IMPU ассоциированы. Например, может быть очень желательным включать как персональные, так и относящиеся к бизнесу информации IMPU в набор неявной регистрации пользователя, при этом поддерживая отдельные профили услуг для двух типов идентификационных информаций. Это будет ясно из примера по фиг.6, где информации IMPU: публичная идентификационная информация 1, публичная идентификационная информация 2 и публичная идентификационная информация 3 - принадлежит одному и тому же набору неявной регистрации, но не все ассоциированы с одним и тем же профилем услуги. Важно, поэтому, что альтернативные информации IMPU не привязываются к набору неявной регистрации.
Предпочтительный подход состоит в том, чтобы показывать информации IMPU, ассоциированные с профилем услуги, через интерфейсы Ut, Sh, ISC и/или Gm, и чтобы информировать сетевые узлы или терминалы UE, получающие эту информацию, что информации IMPU, ассоциированные с одним и тем же профилем услуги, должны рассматриваться как альтернативные публичные идентификационные информации пользователя. Фиг.7 показывает различные интерфейсы, которые могут использоваться, чтобы распределять отношение между информациями IMPU и профилями услуг от HSS к объектам, таким как S-CSCF, AS и терминал. HSS обеспечивает доступность информации для функции S-CSCF через интерфейс Cx, и для серверов AS через интерфейс Sh после регистрации (возможно инициированной вследствие процесса регистрации). S-CSCF обеспечивает доступность информации для функции P-CSCF через интерфейс Mw (не показан на чертежах), и P-CSCF показывает ее терминалу через интерфейс Gm в течение регистрации. S-CSCF также делает ее доступной серверу AS через интерфейс ISC.
Интерфейс Sh также должен распознавать, что информации IMPU, ассоциированные с одним и тем же профилем услуги, осуществляют доступ к одним и тем же данным в HSS. Операции, выполняемые через интерфейсы Ut и Sh для одной IMPU, рассматриваются как выполняемые для всех информаций IMPU, ассоциированных с тем же профилем услуги. [Профиль услуги может полностью содержаться в наборе неявной регистрации, хотя неявная регистрация может охватывать более чем один профиль услуги.]
- Предполагается некоторое количество разных решений в отношении того, как S-CSCF может принимать и интерпретировать набор группирования от HSS.
Решение A1: Объявлять информации IMPU, принадлежащие профилю услуги, внутри профиля услуги
Группирование информаций IMPU, принадлежащих профилю услуги, должно сосуществовать с набором неявной регистрации внутри одних и тех же команд через интерфейс Cx, и должно объявляться всякий раз, когда профиль пользователя загружается из HSS, т.е. при регистрации (или повторной регистрации), завершении вызова, или когда профиль пользователя изменяется в HSS.
Это решение требует, чтобы набор неявной регистрации объявлялся в новом элементе информации (атрибутная пара значений или AVP) рядом с профилем услуги. Понятие группирования (альтернативных публичных идентификационных информаций пользователя) объявляется внутри профиля услуги, как передаваемое по интерфейсу Cx, всякий раз, когда профиль пользователя загружается. То есть, набор неявной регистрации явно указывается через интерфейс Cx; и информации IMPU, включенные в профиль услуги (как передаваемые по интерфейсу Cx), указывают группирование альтернатив. Сообщения Cx, которые несут профили услуг, являются ответом назначения сервера (SAA) и запросом профиля передачи (PPR). В этом решении, профиль услуги, сохраненный в HSS, остается неизменным, как это определяется в TS 29.228 (см. фиг.5), но указывается, что экземпляр публичной идентификации указывает на информации IMPU, которые относятся к этому профилю услуги.
Интерфейс Cx модифицируется следующим образом, где подчеркнутый текст идентифицирует новые пары AVP:
загрузка профиля во время регистрации или терминирующего вызова (SAA)
<Server-Assignment-Answer>::=<Diameter Header: 301, PXY, 16777216>
<Session-Id>
{Vendor-Specific-Application-Id}
[Result-Code]
[Experimental-Result]
{Auth-Session-State}
{Origin-Host}
{Origin-Realm}
[User-Name]
*[Public-Identity]->набор набора неявной регистрации, если существует
*[Supported-Features]
[User-Data]->содержит информации IMPU, относящиеся к SP, согласно 29.228 дополнение D
[Charging-Information]
*[AVP]
*[Failed-AVP]
*[Proxy-Info]
*[Route-Record]
загрузка профиля, когда профиль изменяется (PPR)
<Push-Profile-Request>::=<Diameter Header: 305, REQ, PXY, 16777216>
<Session-Id>
{Vendor-Specific-Application-Id}
{Auth-Session-State}
{Origin-Host}
{Origin-Realm}
{Destination-Host}
{Destination-Realm}
{User-Name}
*[Public-Identity]->набор набора неявной регистрации, если существует
*[Supported-Features]
[User-Data]->содержит информации IMPU, относящиеся к SP, согласно 29.228 дополнение D
[Charging-Information]
*[AVP]
*[Proxy-Info]
*[Route-Record]
где пользовательские данные соответствуют TS 29.228 и как показано на фиг.6.
Решение A2: Определить понятие группирования внутри интерфейсов
Этот подход состоит в том, чтобы ввести новое понятие группирования в HSS, которое идентифицирует, какие информации IMPU ассоциированы. Это требует, чтобы профиль услуги, как определено в TS 29.228, модифицировался посредством добавления нового экземпляра, называемого идентификатор SProfile. Это показано на фиг.8. Экземпляр идентификатора SProfile указывает все информации IMPU, принадлежащие этому профилю услуги. Набор неявной регистрации содержится внутри профиля услуги. Это дает результатом дополнительную AVP на интерфейсе Cx (внутри SAA или PPR), которая будет транспортировать информацию о информациях IMPU, которые рассматриваются как альтернативные публичные идентификационные информации пользователя.
Решение A3: Ввести индикацию интерпретации альтернатив
Дополнительно рассматривая решение A1, оно может быть упрощено посредством предположения, что информации IMPU, ассоциированные с единичным профилем услуги, всегда будут принадлежать одному и тому же набору неявной регистрации. Предполагая, что понятие альтернативности активировано для всех профилей услуг, нет необходимости идентифицировать какие-либо информации IMPU вне данных профиля услуги, переносимых по линии. Однако, если понятие альтернативности не активировано по умолчанию, будет необходимо идентифицировать те профили услуг, к которым альтернативность применяется. Согласно фиг.6, может быть, например, что альтернативность активирована только для профиля 1 услуги.
- Предусматриваются разные решения в отношении того, как сервер приложений может принимать набор группирования.
Решение B1: S-CSCF докладывает информацию через ISC. Возможно некоторое количество вариантов осуществления.
a) Объявлять информации IMPU, принадлежащие единичному профилю услуги, в регистрации 3-й стороны.
Согласно существующим спецификациям 3GPP функции S-CSCF может даваться команда посылать сообщение SIP REGISTER серверу приложений. Это известно как регистрация 3-й стороны. Этот подход должен включать новые данные в сообщение регистрации между S-CSCF и сервером приложений, которое переносит информацию о том, какие информации IMPU являются альтернативными публичными идентификационными информациями пользователя.
b) Объявлять информации IMPU, принадлежащие единичному профилю услуги, посредством подписки на событие регистрации.
В текущее время, чтобы для сервера приложений получать информацию о неявно зарегистрированных информациях IMPU, сервер приложений может подписываться (посылать сообщение SUBSCRIBE) на S-CSCF, которая ранее послала сообщение REGISTER серверу приложений. S-CSCF затем посылает сообщение NOTIFY серверу приложений, содержащее информацию о зарегистрированных информациях IMPU. Предложение состоит в том, чтобы расширить содержимое сообщения NOTIFY, чтобы включить туда информацию о том, какие информации IMPU являются альтернативными публичными идентификационными информациями пользователя.
Решение B2: AS принимает информацию через Sh
AS запрашивает альтернативную информацию IMPU через интерфейс Sh таким же способом, как она уже запрашивает информации IMPU, принадлежащие набору неявной регистрации, или информации IMPU под той же IMPI.
В текущее время AS посылает Sh-Read серверу HSS, указывающее внутри AVP Identity-Set:
ALL_IDENTITIES(0)
REGISTERED_IDENTITIES(1)
IMPLICIT_IDENTITIES(2)
Чтобы вызвать загрузку группирования профиля услуги, добавляется новое значение к сообщению:
SERVICE_PROFILE_IDENTITIES(3)
Следовательно, HSS принимает Public-Identity как входной ключ (когда какая-либо операция делается через Ut, например), и возвращает все другие информации IMPU, ассоциированные с тем же профилем, что и IMPU, которую HSS указал в запросе.
- Также предусматриваются разные решения в отношении того, как мобильный терминал может принимать набор группирования.
Например, два возможных решения это:
Решение C1: Включать группирование информаций IMPU в сообщение 200 OK фазы регистрации.
Включать информацию группирования публичных идентификаторов пользователя в 200 OK, посылаемое в ответ на сообщение Registration. Это будет в форме дополнительного заголовка SIP к набору неявной регистрации.
Решение B2: Включать группирование информаций IMPU в пакет события регистрации.
Включать информацию группирования информаций IMPU в сообщение NOTIFY, посылаемое в ответ на пакет события регистрации.
Решения B1 и B2 дополняют друг друга и, таким образом, не являются необходимо взаимно исключающими альтернативами.
В то время как механизмы, описанные выше, относятся к распределению данных внутри одной сети оператора и мобильным терминалам, которые подсоединяются к этой сети, лежащий в основе принцип совместного использования информации группирования простирается до передачи информации группирования другим сетям (посредством включения туда соответствующей информации через интерфейс сеть-сеть), например, между сетью оператора A и сетью оператора B. Здесь даны два примера, чтобы показать, когда может быть полезно передавать информацию группирования из одной сети в другую сеть.
1. Присутствие:
Абонент оператора A (пользователь A) имеет абонента оператора B как разрешенного наблюдателя присутствия (пользователь B), т.е. пользователь A авторизовал пользователя B (используя конкретный публичный идентификатор пользователя для пользователя B) иметь возможность наблюдать присутствие пользователя A. Однако пользователь B имеет две (или более) информации IMPU, и та, которая используется (пользователем B), чтобы наблюдать присутствие пользователя A, не является той, которую пользователь A авторизовал. Посредством транспортировки информации группирования для пользователя B в сеть A, так что пользователь B способен (используя любую из своих информаций IMPU, совместно использующих один и тот же профиль услуги) наблюдать присутствие пользователя A.
2. Принять списки отклонения:
В, например, многоточечной полудуплексной связи в сети сотовой связи (PoC) сервер AS, завершающий PoC, может осуществлять доступ к спискам допуска и отклонения в XDMS для завершающего пользователя, чтобы определять, может ли запрос завершения PoC выполняться для пользователя. До настоящего времени, это могло не работать должным образом в случае, когда пользователь может идентифицироваться посредством более чем одного средства (публичного идентификатора пользователя). Один вариант осуществления этого изобретения предоставляет решение этой проблемы посредством включения данных группирования в сообщение SIP, которое создает новый сеанс SIP (например, INVITE). Семантика таких данных может быть "Пользователь X также известен как {список сгруппированных публичных идентификаторов пользователя}".
Специалисты в данной области техники должны принять во внимание, что с вышеописанными вариантами осуществления могут делаться различные модификации без отхода от объема настоящего изобретения.
1. Домашний сервер абонентов для управления подписками подсистемы мультимедиа IP, содержащий:
средство для поддержки ассоциаций между публичными идентификационными информациями пользователя и профилями услуг, причем каждая публичная идентификационная информация пользователя ассоциирована с некоторым профилем услуги, причем две или более публичных идентификационных информаций пользователя могут быть ассоциированы с общим профилем услуги; и
средство для идентификации для сетевого узла всех публичных идентификационных информаций пользователя, других, нежели тех, которые принадлежат набору неявной регистрации, которые ассоциированы с общим профилем услуги.
2. Домашний сервер абонентов по п.1, содержащий средство для дополнительной идентификации для сетевого узла всех публичных идентификационных информаций пользователя вне профиля услуги, принадлежащих набору неявной регистрации.
3. Домашний сервер абонентов по п.1, в котором упомянутое средство для идентификации посылает уведомление сетевому узлу в ответ на процедуру регистрации или повторной регистрации, завершение вызова или изменение содержимого в профиле услуги.
4. Домашний сервер абонентов по п.1, в котором упомянутое средство для идентификации для сетевого узла всех публичных идентификационных информаций пользователя, ассоциированных с общим профилем услуги, содержит средство для отправки сообщения сетевому узлу, содержащего один или более профилей услуг, причем каждый профиль услуги идентифицирует все публичные идентификационные информации пользователя, другие, нежели те, которые принадлежат набору неявной регистрации, с которыми он ассоциирован.
5. Домашний сервер абонентов по п.4, в котором упомянутое сообщение идентифицирует один или более профилей услуг, содержащихся в сообщении, причем публичные идентификационные информации пользователя каждого идентифицированного профиля услуги рассматриваются как альтернативные публичные идентификационные информации пользователя.
6. Домашний сервер абонентов по п.1, в котором упомянутый сетевой узел является обслуживающей функцией управления сеансом вызова.
7. Домашний сервер абонентов по п.1, в котором упомянутое средство для идентификации передает требуемую информацию обслуживающей функции управления сеансом вызова в ответе назначения сервера Сх или сообщении запроса профиля передачи.
8. Домашний сервер абонентов для управления подписками подсистемы мультимедиа IP, содержащий:
средство для поддержки группирований публичных идентификационных информаций пользователя, других, нежели тех, которые принадлежат набору неявной регистрации и которые должны рассматриваться как альтернативные публичные идентификационные информации пользователя; и
средство для отправки сетевому узлу идентификации групп альтернатив.
9. Домашний сервер абонентов по п.8, котором упомянутое средство для отправки сетевому узлу идентификации групп альтернатив, посылает эту информацию в ответ на процедуру регистрации или повторной регистрации, завершение вызова или изменение содержимого в профиле услуги.
10. Домашний сервер абонентов по п.8, в котором упомянутый сетевой узел является обслуживающей функцией управления сеансом вызова или сервером приложений.
11. Сервер осуществления функции управления сеансом вызова для обслуживания пользователя в сети подсистемы мультимедиа IP, причем сервер осуществления функции управления сеансом вызова содержит:
средство для приема от домашнего сервера абонентов, сообщения, содержащего один или более профилей услуг, причем этот один или каждый профиль услуги идентифицирует все публичные идентификационные информации пользователя, другие, нежели те, которые принадлежат набору неявной регистрации, с которыми профиль услуги ассоциирован; и
средство для ассоциирования публичных идентификационных информаций пользователя, по меньшей мере, одного профиля услуги как альтернативных публичных идентификационных информаций пользователя.
12. Сервер осуществления функции управления сеансом вызова по п.11, дополнительно содержащий средство для идентификации публичных идентификационных информаций пользователя, принадлежащих набору неявной регистрации, использующему список публичных идентификационных информаций пользователя, содержащихся вне принятого профиля (профилей) услуги.
13. Сервер осуществления функции управления сеансом вызова по п.11, дополнительно содержащий средство для идентификации профилей услуг, к которым ассоциация альтернатив должна применяться.
14. Сервер осуществления функции управления сеансом вызова по п.11, дополнительно содержащий средство для отправки уведомления пользовательскому терминалу или сетевому узлу, идентифицирующего публичные идентификационные информации пользователя, другие, нежели те, которые принадлежат набору неявной регистрации, и идентифицированные как альтернативные публичные идентификационные информации пользователя.
15. Сервер осуществления функции управления сеансом вызова по п.11, причем сервер осуществления функции управления сеансом вызова является обслуживающим сервером осуществления функции управления сеансом вызова.
16. Сервер приложений для исполнения услуг в сети подсистемы мультимедиа IP, причем сервер приложений содержит: средство для приема от обслуживающей функции управления сеансом вызова или домашнего сервера абонентов уведомления, что две или более публичных идентификационных информаций пользователя, других, нежели тех, которые принадлежат набору неявной регистрации, рассматриваются как альтернативные публичные идентификационные информации пользователя и, таким образом, ассоциированы с общим профилем услуги.
17. Пользовательский терминал для обеспечения пользователю возможности доступа к сети подсистемы мультимедиа IP, причем пользовательский терминал содержит:
средство для приема от сети подсистемы мультимедиа IP уведомления, что две или более публичных идентификационных информаций пользователя терминала, других, нежели тех, которые принадлежат набору неявной регистрации, рассматриваются как альтернативные публичные идентификационные информации пользователя и, таким образом, ассоциированы с общим профилем услуги.
18. Пользовательский терминал по п.17, в котором упомянутое средство выполнено с возможностью при использовании принимать упомянутое уведомление от обслуживающей функции управления сеансом вызова.
19. Способ управления подсистемой мультимедиа IP, чтобы информировать сетевые узлы и/или пользовательские терминалы о публичных идентификационных информациях пользователя, чтобы они рассматривались как альтернативные публичные идентификационные информации пользователя, причем способ содержит:
поддержку в домашнем сервере абонентов группирований публичных идентификационных информаций пользователя, других, нежели тех, которые принадлежат набору неявной регистрации, чтобы они рассматривались как альтернативные публичные идентификационные информации пользователя; и распределение информации группирования сетевым узлам и/или пользовательским терминалам.
20. Способ по п.19, в котором упомянутые группирования поддерживаются в профилях услуг как публичные идентификационные информации пользователя, ассоциированные с профилями услуг.
21. Способ по п.20, дополнительно содержащий отправку от домашнего сервера абонентов к обслуживающей функции управления сеансом вызова сообщения, содержащего один или более профилей услуг, причем этот один или каждый профиль услуги идентифицирует все публичные идентификационные информации пользователя, другие, нежели те, которые принадлежат набору неявной регистрации, и ассоциированные с профилем услуги, и обслуживающую функцию управления сеансом вызова, идентифицирующую эти публичные идентификационные информации пользователя, ассоциированные с, по меньшей мере, одним профилем услуги как альтернативные публичные идентификационные информации пользователя.
22. Способ по п.21, в котором упомянутое сообщение является ответом назначения сервера Сх или сообщением запроса профиля передачи.
23. Способ по п.21, в котором обслуживающая функция управления сеансом вызова информирует сервер приложений или пользовательский терминал о группе публичных идентификационных информаций пользователя, других, нежели тех, которые принадлежат набору неявной регистрации, чтобы они рассматривались как альтернативные публичные идентификационные информации пользователя.
24. Способ по п.21, в котором публичные идентификационные информации пользователя, принадлежащие набору неявной регистрации, перечислены в упомянутом сообщении, но вне профиля (профилей) услуги.
25. Способ по п.21, в котором сообщение идентифицирует те профили услуг, для которых ассоциированные публичные идентификационные информации пользователя должны рассматриваться как альтернативные публичные идентификационные информации пользователя.
26. Способ по п.19, в котором упомянутый этап распределения выполняется в течение или после регистрации пользовательского терминала в подсистеме мультимедиа IP, или при или после завершения вызова к пользовательскому терминалу, или при изменении содержимого профиля услуги.
27. Способ по п.20, в котором упомянутый этап распределения содержит отправку информации группирования серверу приложений через интерфейс Sh.
28. Способ по п.23, в котором пользовательский терминал уведомляется, что две или более его публичные идентификационные информации пользователя, другие, нежели те, которые принадлежат набору неявной регистрации, являются альтернативными публичными идентификационными информациями пользователя, посредством сигнализации, отправляемой от сервера приложений через интерфейс Ut.
29. Способ управления пользовательским терминалом, сконфигурированным для использования с подсистемой мультимедиа IP, причем способ содержит:
прием от подсистемы уведомления, что две или более публичных идентификационных информаций пользователя терминала, других, нежели тех, которые принадлежат набору неявной регистрации, должны рассматриваться как альтернативные публичные идентификационные информации пользователя.
30. Способ управления сервером приложений протокола установления сеансов связи подсистемы мультимедиа IP, причем способ содержит:
прием от обслуживающей функции управления сеансом вызова или домашнего сервера абонентов уведомления, что две или более публичных идентификационных информаций пользователя, других, нежели тех, которые принадлежат набору неявной регистрации, должны рассматриваться как альтернативные публичные идентификационные информации пользователя для управления конфигурациями услуги.
31. Способ управления сервером домашних абонентов в подсистеме мультимедиа IP, причем способ содержит:
поддержку в домашнем сервере абонентов группирований публичных идентификационных информаций пользователя, других, нежели тех, которые
принадлежат набору неявной регистрации, чтобы рассматривались как альтернативные публичные идентификационные информации пользователя; и распределение информации группирования сетевым узлам и/или пользовательским терминалам.
32. Подсистема мультимедиа IP, содержащая: домашний сервер абонентов, выполненный с возможностью поддерживать группирования публичных идентификационных информаций пользователя, других, нежели тех, которые принадлежат набору неявной регистрации, чтобы они рассматривались как альтернативные публичные идентификационные информации пользователя, и имеет средство, выполненное с возможностью, в течение или после регистрации пользовательского терминала в подсистеме мультимедиа IP, или при или после завершения вызова к пользовательскому терминалу, информировать терминал и/или сетевой узел о группировании, содержащем публичную идентификационную информацию пользователя терминала или пользователя терминала.
33. Домашний сервер абонентов для управления подписками подсистемы мультимедиа IP, и содержащий:
средство для поддержки ассоциаций между публичными идентификационными информациями пользователя и профилями услуг, причем каждая публичная идентификационная информация пользователя ассоциирована с профилем услуги, при этом две или более публичных идентификационных информаций пользователя могут быть ассоциированными с общим профилем услуги;
средство для идентификации для сетевого узла всех публичных идентификационных информаций пользователя, принадлежащих набору неявной регистрации; и
отличающийся средством для идентификации для сетевого узла всех публичных идентификационных информации пользователя, не принадлежащих набору неявной регистрации и ассоциированных с общим профилем услуги.
