RU2426275C2 - Способ, система и элемент сети для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, или отказе элемента сети - Google Patents

Abstract

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

Description

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

Настоящая заявка является выделенной заявкой из Российской Патентной Заявки №2009129157, поданной 28 июля 2009г. и озаглавленной «СПОСОБ, СИСТЕМА И ЭЛЕМЕНТ СЕТИ ДЛЯ ОБРАБОТКИ ПРЕДОСТАВЛЕНИЯ УСЛУГ ПОСЛЕ ТОГО, КАК ДАННЫЕ ЭЛЕМЕНТА СЕТИ СТАНОВЯТСЯ НЕДОПУСТИМЫМИ, ИЛИ ОТКАЗЕ ЭЛЕМЕНТА СЕТИ». Содержание определенной выше заявки включено в данный документ посредством ссылки во всей своей полноте.

Область техники

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

Уровень техники

Подсистема передачи мультимедиа по IP-сетям (IMS) является подсистемой, накладываемой поверх существующего домена с коммутацией пакетов (PS) в сети с широкополосным множественным доступом с кодовым разделением каналов (WCDMA), добавленной в R5 Партнерского проекта третьего поколения (3GPP), и использует PS-домен в качестве однонаправленного канала для передачи управляющих служебных сигналов верхнего уровня и передачи мультимедиа. Протокол инициирования сеанса (SIP) представляется как протокол управления услугами. За счет использования преимуществ признаков, что SIP является простым, несложным в наращивании и удобным для комбинации мультимедиа, IMS предоставляет различные мультимедийные услуги через разделение управления услугами и управления однонаправленным каналом. Функциональные объекты в IMS включают в себя функцию управления сеансами и вызовами (CSCF), выполненную с возможностью осуществлять управление регистрацией пользователей и управление услугами, сервер собственных абонентов (HSS), выполненный с возможностью совместно управлять данными пользовательских подписок, сервер приложений (AS), выполненный с возможностью предоставлять различные функции управления логикой предоставления услуг, и т.д.

Фиг.1 - это схематическое представление структуры IMS-сети в предшествующем уровне техники. На фиг.1 AS - это сервер приложений, HSS - это сервер собственных абонентов, I-CSCF - это опрашивающая CSCF, P-CSCF - это прокси-CSCF, S-CSCF - это обслуживающая CSCF, и UE - это абонентское устройство (пользовательское оборудование). Как показано на фиг.1, процесс предоставления услуг пользователю заключается в следующем: после того как UE включено, UE инициирует процесс регистрации в IMS-сети; после приема запроса на регистрацию от пользователя IMS-сеть сохраняет информацию, такую как регистрационные данные и состояние регистрации пользователя в соответствующих элементах сети, например P-CSCF, S-CSCF, AS и HSS сохраняют регистрационную информацию пользователя. UE переносит параметр периода регистрации в регистрационном сообщении и после того, как UE успешно зарегистрировано, UE периодически инициирует процесс повторной регистрации в IMS-сети, чтобы обновлять регистрационные данные и состояние регистрации пользователя. Только пользователь в зарегистрированном состоянии в соответствующем элементе сети для IMS-сети может выполнять соответствующие пользовательские услуги, к примеру инициировать вызов в качестве вызывающего абонента или принимать вызов в качестве вызываемого абонента.

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

На этапе 201, после того как UE включено, UE отправляет регистрационное сообщение в P-CSCF.

На этапе 202, после локального сохранения релевантных данных пользователя P-CSCF перенаправляет регистрационное сообщение в I-CSCF в домашнем домене пользователя.

На этапе 203, I-CSCF отправляет запрос на авторизацию пользователя (UAR) в HSS и запрашивает S-CSCF, которая может предоставлять услуги пользователю.

На этапе 204, HSS возвращает ответ по авторизации пользователя (UAA), переносящий S-CSCF, которая может предоставлять услуги пользователю, в I-CSCF.

На этапе 205, I-CSCF перенаправляет регистрационное сообщение в выбранную S-CSCF.

На этапе 206, S-CSCF отправляет запрос назначения сервера (SAR) в HSS и запрашивает данные подписки пользователя из HSS.

На этапе 207, HSS возвращает ответ по назначению сервера (SAA), переносящий данные подписки пользователя, в S-CSCF.

На этапе 208, S-CSCF инициирует стороннюю регистрацию в соответствующем AS согласно данным подписки пользователя и локально сохраняет релевантные данные пользователя.

На этапе 209, AS отвечает с помощью ответа об успешной регистрации.

На этапе 210, S-CSCF отвечает с помощью ответа об успешной регистрации.

На этапе 211, I-CSCF отвечает с помощью ответа об успешной регистрации.

На этапе 212, P-CSCF отвечает с помощью ответа об успешной регистрации.

На этапе 213, после того как пользователь успешно зарегистрирован, пользователь может начинать выполнять соответствующий процесс получения услуг.

На этапе 214, после того как период регистрации UE истекает, UE инициирует процесс повторной регистрации, чтобы обновлять регистрационные данные и состояние регистрации пользователя в IMS-сети, с тем чтобы пользователь мог продолжать выполнять процесс получения услуг.

В предшествующем уровне техники, UE инициирует запрос на регистрацию в IMS-сети и после того, как регистрация успешно выполнена, UE не инициирует процесс повторной регистрации в периоде регистрации по своей инициативе. Если один из элементов сети (например, P-CSCF, S-CSCF или AS), сохраняющий регистрационные данные пользователя в IMS-сети, отказывает при работе в этот период, то регистрационные данные пользователя в элементе сети станут недопустимыми (например, регистрационные данные пользователя теряются после того, как один из элементов сети сбрасывается). Здесь, если UE инициирует запрос на получение услуг, то элемент сети должен рассматривать UE как незарегистрированное и отклонять запрос на предоставление услуг пользователю. Следовательно, UE не может выполнять услугу вызова в периоде регистрации. Помимо этого, когда осуществляется вызов пользователю, поскольку регистрационные данные пользователя в различных элементах сети отличаются (некоторые элементы сети сохраняют регистрационные данные пользователя, и пользователь находится в зарегистрированном состоянии, тогда как другие элементы сети не сохраняют регистрационные данные пользователя), вызываемый пользователь не может быть найден. Следовательно, соответствующая вызываемая услуга также не может быть выполнена.

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

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

Фиг.3 - это подробное схематическое структурное представление IMS-сети в предшествующем уровне техники. Как показано на фиг.3, IMS-сеть включает в себя CSCF и HSS.

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

HSS выполнен с возможностью сохранять набор информации по подписке IMS, когда оператор открывает учетную запись и поддерживает настройку и модификацию данных подписки оператором или конечным пользователем через интерфейс с системой управления обслуживанием. HSS регистрирует информацию маршрутизации доменных имен S-CSCF в процессе регистрации IMS через Cx-интерфейс на основе протокола Diameter между HSS и S-CSCF и поддерживает загрузку основной информации по подписке IMS в S-CSCF через Cx-интерфейс. HSS выбирает S-CSCF, обслуживающую пользователя в ходе регистрации пользователя, через Cx-интерфейс на основе протокола Diameter между HSS и I-CSCF или предоставляет имя S-CSCF, предоставляющей услуги пользователю, в настоящий момент в I-CSCF, так чтобы I-CSCF могла маршрутизировать регистрационную информацию или сеанс в корректную S-CSCF. HSS предоставляет данные подписки и интерфейс удаленного доступа к базе данных для сценариев логики предоставления услуг в SIP AS собственных дополнительных услуг или в сервер поддержки услуг (SCS) для открытой архитектуры обслуживания (OSA) через Sh-интерфейс между HSS и SIP и между HSS и AS, и HSS отвечает за прозрачное хранение данных собственных дополнительных услуг AS для конкретных абонентов, но не заключает в себе семантическую интерпретацию.

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

AS получает или обновляет данные, связанные с услугами пользователя, и информацию о состоянии пользователя через Sh-интерфейс HSS, и S-CSCF получает информацию по подписке пользователя через Cx-интерфейс между HSS и S-CSCF.

В IMS-сети, UE может использовать услуги, предоставляемые посредством IMS-сети, после регистрации в сети. Между тем, UE может выбирать подписываться на незарегистрированные услуги, и когда UE не зарегистрировано в сети, сеть по-прежнему может предоставлять незарегистрированные услуги, такие как переадресация вызовов и запись вызовов. Когда UE зарегистрировано в сети или когда пользователь является стороной входящего вызова, S-CSCF и HSS обмениваются данными аутентификации и данными об услугах пользователя через пару команд запроса назначения сервера/ответа по назначению сервера (SAR/SAA).

Сценарий приложения SAR/SAA заключается в том, что S-CSCF принимает запрос на регистрацию UE, отправленный от P-CSCF, или принимает сообщение INVITE с запросом на установление сеанса от I-CSCF.

(1) S-CSCF выполняет следующие действия для HSS через команду SAR:

- назначение S-CSCF для общедоступных идентификационных данных или очистка имени S-CSCF, назначенной для одних или нескольких общедоступных идентификационных данных;

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

- изменение состояния регистрации общедоступных пользовательских (PU) идентификационных данных, связанных с пользователем.

Server Assignment Type имеет 11 значений, два из которых поясняются следующим образом.

N0_ASSIGNMENT (0) сконфигурировано запрашивать пользовательские данные из HSS посредством S-CSCF без затрагивания состояния регистрации пользователя.

UNREGISTERED_USER (3) сконфигурировано указывать S-CSCF, что запрос INVITE для входящего вызова незарегистрированному пользователю принят.

Если имя S-CSCF в SAR, принимаемом посредством HSS, является несовместимым с именем S-CSCF, сохраненным в HSS, HSS заменяет первоначальное имя S-CSCF на новое, но возвращает код с результатами экспериментов в DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED, указывающий то, что S-CSCF назначена пользователю.

Когда тип операции в SAR, принимаемом посредством HSS, - это операция, которая не разрешена для пользователя в текущем состоянии, например, когда Server Assignment Type - это UNREGISTERED_USER, он указывает, что S-CSCF принимает запрос INVITE для входящего вызова по незарегистрированным общедоступным пользовательским идентификационным данным IMS (IMPU). Тем не менее, если IMPU зарегистрирован в HSS, в это время HSS возвращает код с результатами экспериментов в DIAMETER _ERROR_IN_ASSIGNMENT_TYPE, указывающий то, что S-CSCF назначена для пользователя, и текущее состояние пользователя состоит в том, что операция не разрешена.

(2) HSS возвращает в S-CSCF через команду SAA следующее:

- результат обработки;

- пользовательские данные;

- информация об оплате; и

- все конфиденциальные пользовательские идентификационные данные мультимедиа IMS (IMPI) подписки IMS.

HSS может загружать пользовательские данные и адрес функции оплаты только тогда, когда тип операции - это NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION или UNREGISTERED_USER.

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

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

На этапе 4001, I-CSCF принимает сообщение INVITE для входящего вызова к определенному пользователю.

На этапе 4002, I-CSCF инициирует сообщение запроса информации о местоположении (LIR), чтобы получать информацию о S-CSCF, обслуживающей пользователя, или набор характеристик требуемых S-CSCF.

На этапе 4003, если HSS записывает имя S-CSCF, обслуживающей пользователя, HSS возвращает имя S-CSCF в I-CSCF через сообщение ответа с информацией о местоположении, а если HSS не имеет записи, HSS возвращает набор характеристик S-CSCF, которые удовлетворяют требованиям по обслуживанию пользователя.

На этапе 4004, если HSS не возвращает имя S-CSCF, а возвращает набор характеристик S-CSCF, I-CSCF выбирает соответствующую S-CSCF согласно набору характеристик S-CSCF, возвращенных посредством HSS.

На этапе 4005, I-CSCF перенаправляет запрос INVITE в S-CSCF.

На этапе 4006, если S-CSCF не имеет пользовательских данных, S-CSCF отправляет SAR в HSS, чтобы запрашивать пользовательские данные, и параметр Server Assignment Type в команде SAR задается равным UNREGISTERED_USER, чтобы сообщать HSS о том, что текущим состоянием пользователя является незарегистрированный входящий вызов.

На этапе 4007, HSS загружает пользовательские данные в S-CSCF через SAA.

На этапе 4008, S-CSCF выполняет управление услугами согласно пользовательским данным и осуществляет последующую обработку.

Фиг.5 - это схематическое представление процесса реализации сеанса входящего вызова, который зарегистрирован в сети пользователя, в предшествующем уровне техники. В отличие от способа, показанного на фиг.4, процесс, показанный на фиг.5, не включает в себя этап 4004, этап 4006 и этап 4007, поскольку пользователь зарегистрирован в сети, сеть назначила S-CSCF, обслуживающую пользователя, и HSS сохраняет имя S-CSCF; поэтому процесс того, что I-CSCF выбирает S-CSCF согласно набору характеристик S-CSCF на этапе 4004, не выполняется в данном случае. Помимо этого, S-CSCF загрузила пользовательские данные из HSS, когда пользователь зарегистрирован, так что процесс того, что S-CSCF загружает пользовательские данные из HSS через SAR/SAA на этапе 4006, также не выполняется в данном случае. Дополнительно, обычно, состоянием пользователя, записанным в HSS, является "зарегистрирован", и имя связанной S-CSCF сохраняется в HSS, так что ситуация, когда S-CSCF не имеет пользовательских данных, не должна возникать, и этап 4007 не должен быть выполнен в данном случае.

Фиг.6 - это схематическое представление процесса реализации, когда AS заменяет пользователя, чтобы инициировать сеанс исходящего вызова, в предшествующем уровне техники. Как показано на фиг.6, когда AS заменяет пользователя, чтобы инициировать исходящий вызов, AS может получать имя S-CSCF, обслуживающей пользователя, из HSS через стороннюю регистрацию или через Sh-интерфейс. Если AS получает имя S-CSCF, обслуживающей пользователя, до замены пользователя, чтобы инициировать исходящий вызов, этап 601a на фиг.6 выполняется, т.е. AS напрямую маршрутизирует сеанс в S-CSCF, обслуживающую пользователя. Если имя S-CSCF, обслуживающей пользователя, не может быть получено, должен быть выполнен этап 601b1.

На этапе 601b1, сеанс маршрутизируется в I-CSCF домашнего домена пользователя.

На этапе 601b2, I-CSCF инициирует сообщение LIR в HSS, заполняет идентификационные данные вызывающего пользователя в поле заголовка P-Asserted-Identity сообщения для LIR и добавляет флаг запроса на исходящий вызов, чтобы запрашивать информацию о текущем местоположении пользователя, т.е. информацию о S-CSCF, обслуживающей пользователя.

На этапе 601b3, HSS запрашивает информацию, соответствующую пользователю в базе данных, согласно пользовательским идентификационным данным в LIR и возвращает имя S-CSCF, обслуживающей пользователя, или набор характеристик S-CSCF в I-CSCF через LIA.

На этапе 601b4, если HSS возвращает набор характеристик S-CSCF, I-CSCF должна выбирать S-CSCF согласно набору характеристик.

На этапе 601b5, I-CSCF маршрутизирует сообщение INVITE в S-CSCF, возвращенную посредством HSS, или в S-CSCF, выбранную для пользователя согласно набору характеристик S-CSCF, возвращенному посредством HSS.

На этапе 602, если S-CSCF не имеет информации о пользователе, S-CSCF переносит пользовательские идентификационные данные в поле заголовка P-Asserted-Identity в SAR, чтобы запрашивать данные подписки пользователя из HSS, а если S-CSCF имеет информацию о пользователе, этап 604 выполняется напрямую.

На этапе 603, HSS возвращает запрошенные данные подписки пользователя в S-CSCF через SAA.

На этапе 644, S-CSCF выполняет управление услугами.

На этапе 605, S-CSCF выполняет последующую обработку.

Фиг.7 - это схематическое представление процесса реализации того, что пользователь инициирует сеанс исходящего вызова, в предшествующем уровне техники. Как показано на фиг.7, процесс включает в себя следующие этапы.

На этапе 701, UE инициирует сообщение INVITE и необязательно может заполнять общедоступные пользовательские идентификационные данные, указывающие идентификационные данные UE, в поле заголовка P-Preferred-Identity.

На этапе 702, после приема сообщения INVITE, P-CSCF проверяет, содержит ли сообщение поле заголовка P-Preferred-Identity, и проверяет, совпадает ли значение поля заголовка с зарегистрированными общедоступными пользовательскими идентификационными данными, записанными в P-CSCF, и если значение поля заголовка совпадает с зарегистрированными общедоступными пользовательскими идентификационными данными, записанными в P-CSCF, P-CSCF использует общедоступные пользовательские идентификационные данные в качестве инициатора сеанса и заполняет общедоступные пользовательские идентификационные данные в P-Asserted-Identity; если совпадающие зарегистрированные общедоступные пользовательские идентификационные данные не обнаружены, или поле заголовка P-Preferred-Identity отсутствует, P-CSCF выбирает общедоступные пользовательские идентификационные данные по умолчанию в качестве инициатора сеанса для пользователя и заполняет общедоступные пользовательские идентификационные данные в P-Asserted-Identity.

На этапе 703, после приема сообщения INVITE, S-CSCF инициирует услуги согласно идентификационным данным вызывающего пользователя в поле заголовка P-Asserted-Identity из сообщения и маршрутизирует последующий сеанс согласно Request-URI (т.е. вызываемому пользователю) в сообщении INVITE.

После тщательного анализа вышеупомянутых процессов можно заметить, что в обычных ситуациях, т.е. когда состоянием пользователя, записанным в HSS, является "зарегистрирован", и имя связанной S-CSCF сохраняется, S-CSCF всегда имеет пользовательские данные. Тем не менее, когда IMPU пользователя потеряны вследствие внезапной ненормальности S-CSCF, где пользователь регистрируется, например, в случае отказа и перезагрузки системы, если UE пользователя не регистрируется в этом процессе, информация по подписке пользователя в HSS не обновляется, и зарегистрированный пользователь по-прежнему записан как зарегистрированный в первоначальной S-CSCF.

Здесь, когда S-CSCF принимает сообщение INVITE с запросом на установление сеанса, отправленное посредством I-CSCF или AS, поскольку S-CSCF не имеет соответствующие пользовательские данные, S-CSCF отправляет SAR в HSS, чтобы запрашивать пользовательские данные, и параметр Server Assignment Type в команде SAR заполняется как UNREGISTERED_USER. Тем не менее, HSS выясняет, что S-CSCF, инициирующая SAR, и S-CSCF, записанная в HSS, являются одинаковыми, но состоянием IMPU пользователя, запрашивающего операцию, является "зарегистрирован" в HSS. Здесь, HSS не должен возвращать информацию об услугах пользователя в SAA, а должен задавать код с результатами экспериментов как DIAMETER _ERROR_IN_ASSIGNMENT_TYPE и возвращать его в S-CSCF, указывая то, что S-CSCF назначена для пользователя, и текущее зарегистрированное состояние не разрешает этот тип операции. Таким образом, HSS сообщает S-CSCF о том, что IMPU находится в зарегистрированном состоянии в HSS, так что незарегистрированная операция не разрешена. S-CSCF возвращает ответ со сбоем в I-CSCF, и сеанс завершается ошибкой.

Когда S-CSCF принимает сообщение INVITE с запросом на исходящий вызов, отправленное от P-CSCF, и S-SCCF не имеет пользовательских данных IMPU, содержащегося в P-Asserted-Identity, вследствие перезагрузки, S-CSCF возвращает сбой непосредственно в P-CSCF, и сеанс завершается ошибкой.

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

Сущность изобретения

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

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

В еще одном другом аспекте, настоящее изобретение предоставляет способ и систему для возвращения пользовательских данных, HSS и S-CSCF, которые разрешают такие проблемы, что пользователь не может использовать входящий вызов, пользователь не может использовать исходящий вызов, инициированный посредством UE, или AS не может инициировать исходящий вызов от имени пользователя до повторной регистрации пользователя, когда связанные с IMPU данные пользователя в S-CSCF, в которой регистрируется пользователь, потеряны, в предшествующем уровне техники.

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

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

Сообщение о недопустимых данных переносит информацию для инициирования повторной регистрации вызывающей стороны.

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

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

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

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

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

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

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

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

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

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

Отправляющая сторона запросов на предоставление услуг и приемная сторона запросов на предоставление услуг могут быть UE или элементами сети обработки информации в сети.

Элемент сети предоставления услуг может быть P-CSCF, I-CSCF или S-CSCF.

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

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

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

Модуль приема сообщений с запросом на предоставление услуг выполнен с возможностью принимать сообщение с запросом на предоставление услуг.

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

В варианте осуществления, настоящее изобретение дополнительно предоставляет способ для возвращения пользовательских данных. Способ включает в себя следующие этапы.

HSS принимает сообщение с запросом на получение пользовательских данных от S-CSCF, и сообщение с запросом содержит пользовательские идентификационные данные.

HSS запрашивает S-CSCF, назначенную для пользователя, согласно пользовательским идентификационным данным.

Когда назначенная S-CSCF является запрашивающей S-CSCF, HSS возвращает пользовательские данные согласно сообщению с запросом.

Способ для возвращения пользовательских данных дополнительно содержит:

- выполнение запроса, посредством HSS, на предмет сохраненного состояния регистрации пользователя согласно пользовательским идентификационным данным; и

- возвращение, посредством HSS, пользовательских данных согласно сообщению с запросом, когда сохраненным состоянием регистрации пользователя является "зарегистрирован", и назначенная S-CSCF является запрашивающей S-CSCF.

Способ для возвращения пользовательских данных дополнительно содержит:

- прием, посредством S-CSCF, сообщения с запросом на установление вызова, содержащего пользовательские идентификационные данные; и

- добавление, посредством S-CSCF, пользовательских идентификационных данных к сообщению с запросом на получение пользовательских данных и отправку сообщения с запросом на получение пользовательских данных в HSS.

В способе для возвращения пользовательских данных, сообщение с запросом на установление вызова - это сообщение INVITE с запросом на незарегистрированный входящий вызов, отправленное посредством опрашивающей функции управления сеансами вызовов (I-CSCF), или сообщение INVITE с запросом на исходящий вызов, инициированное посредством сервера приложений (AS); или сообщение INVITE с запросом на исходящий вызов, отправленное посредством прокси-функции управления сеансами вызовов (P-CSCF) и инициированное посредством абонентского устройства (UE).

Способ для возвращения пользовательских данных дополнительно содержит:

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

Способ для возвращения пользовательских данных дополнительно содержит:

- выполнение, посредством S-CSCF, управления услугами согласно возвращенным пользовательским данным.

В варианте осуществления, настоящее изобретение дополнительно предоставляет систему для возвращения пользовательских данных. Система включает в себя S-CSCF и HSS и дополнительно включает в себя первый приемный модуль, модуль запросов, первый модуль определения и модуль обратной связи.

Первый приемный модуль выполнен с возможностью принимать сообщение с запросом на получение пользовательских данных, отправленное в HSS посредством S-CSCF, при этом сообщение с запросом содержит пользовательские идентификационные данные.

Модуль запросов выполнен с возможностью запрашивать S-CSCF, назначенную для пользователя, согласно пользовательским идентификационным данным.

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

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

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

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

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

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

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

Модуль запросов выполнен с возможностью запрашивать S-CSCF, назначенную для пользователя, согласно пользовательским идентификационным данным.

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

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

В варианте осуществления, настоящее изобретение дополнительно предоставляет S-CSCF. S-CSCF включает в себя первый модуль добавления.

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

S-CSCF дополнительно содержит:

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

В варианте осуществления, настоящее изобретение дополнительно предоставляет способ для возвращения пользовательских данных. Способ включает в себя следующие этапы.

S-CSCF принимает сообщение об ошибке системы S-CSCF.

S-CSCF принимает сообщение с запросом на установление вызова, содержащее пользовательские идентификационные данные.

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

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

Способ для возвращения пользовательских данных дополнительно содержит:

- выполнение запроса, посредством HSS, на предмет состояния регистрации пользователя, согласно пользовательским

идентификационным данным; и

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

В варианте осуществления, настоящее изобретение дополнительно предоставляет систему для возвращения пользовательских данных. Система включает в себя S-CSCF и HSS и дополнительно включает в себя второй приемный модуль, модуль сообщений об ошибках, второй модуль определения, второй модуль добавления, третий модуль определения и модуль обратной связи.

Второй приемный модуль выполнен с возможностью принимать сообщение с запросом на установление вызова, отправленное в S-CSCF, при этом сообщение с запросом содержит пользовательские идентификационные данные.

Модуль сообщений об ошибках выполнен с возможностью инициировать второй модуль определения после приема сообщения об ошибке системы S-CSCF.

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

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

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

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

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

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

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

В варианте осуществления, настоящее изобретение дополнительно предоставляет S-CSCF. S-CSCF включает в себя второй приемный модуль, модуль сообщений об ошибках, второй модуль определения и второй модуль добавления.

Второй приемный модуль выполнен с возможностью принимать сообщение с запросом на установление вызова, отправленное в S-CSCF, при этом сообщение с запросом содержит пользовательские идентификационные данные.

Модуль сообщений об ошибках выполнен с возможностью инициировать второй модуль определения после приема сообщения об ошибке системы S-CSCF.

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

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

Варианты осуществления настоящего изобретения имеют следующие преимущества.

(1) Варианты осуществления настоящего изобретения преодолевают недостатки в стандартах 3GPP. Когда элемент сети (такой как P-CSCF, S-CSCF и AS), содержащий регистрационные данные пользователя, является анормальным, и регистрационные данные пользователя в элементе сети становятся недопустимыми, если UE принимает сообщение о недопустимых пользовательских данных после отправки запроса на предоставление услуг, UE может идентифицировать сообщение о недопустимых пользовательских данных и инициировать процесс повторной регистрации согласно сообщению о недопустимых пользовательских данных. Если другие элементы сети принимают сообщение о недопустимых пользовательских данных после отправки запроса на предоставление услуг, другие элементы сети могут идентифицировать сообщение о недопустимых пользовательских данных и инициировать незарегистрированные услуги пользователя согласно сообщению о недопустимых пользовательских данных. Таким образом, время недоступности услуги пользователя сокращается, и обслуживание пользователя может быть быстро восстановлено. Дополнительно, через способ для обработки предоставления услуг после того, как элемент сети отказывает при работе, в случае сетевого сбоя, текущий процесс предоставления услуг может быть остановлен своевременно, и вызывающему терминалу может быть сообщено об этом. Таким образом, меньше системных ресурсов элементов сети расходуется впустую.

(2) Согласно вариантам осуществления настоящего изобретения, когда HSS принимает сообщение с запросом на получение пользовательских данных, содержащее пользовательские идентификационные данные, от S-CSCF, HSS обнаруживает, что S-CSCF, инициирующая операцию, и S-CSCF, записанная в HSS, являются одинаковыми, или определяет, что сообщение с запросом переносит идентификатор ошибки, и состояние IMPU пользователя, запрашивающего операцию, сохраняется как "зарегистрирован" в HSS, HSS возвращает пользовательские данные согласно сообщению с запросом. Таким образом, даже если связанные с IMPU данные пользователя потеряны в S-CSCF, в которой регистрируется пользователь, пользователь по-прежнему может использовать любой входящий вызов и использовать исходящий вызов, инициированный посредством UE, и AS может заменять пользователя, чтобы инициировать услугу исходящего вызова до повторной регистрации пользователя.

Технические решения настоящего изобретения подробно описываются ниже со ссылками на варианты осуществления и прилагаемые чертежи.

Краткое описание чертежей

Фиг.1 - это представление структуры IMS-сети в предшествующем уровне техники;

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

Фиг.3 - это подробное схематическое структурное представление IMS-сети в предшествующем уровне техники;

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

Фиг.5 - это схематическое представление процесса реализации сеанса входящего вызова, который зарегистрирован в сети пользователя, в предшествующем уровне техники;

Фиг.6 - это схематическое представление процесса реализации, когда AS заменяет пользователя, чтобы инициировать сеанс исходящего вызова, в предшествующем уровне техники;

Фиг.7 - это схематическое представление процесса реализации, когда пользователь инициирует сеанс исходящего вызова, в предшествующем уровне техники;

Фиг.8 - это схематическое структурное представление системы для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно первому варианту осуществления настоящего изобретения;

Фиг.9 - это схематическое структурное представление системы для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно второму варианту осуществления настоящего изобретения;

Фиг.10 - это схематическое структурное представление системы для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно третьему варианту осуществления настоящего изобретения;

Фиг.11 - это схематическое структурное представление системы для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно четвертому варианту осуществления настоящего изобретения;

Фиг.12 - это схематическое структурное представление системы для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно пятому варианту осуществления настоящего изобретения;

Фиг.13 - это блок-схема последовательности сигналов способа для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно первому варианту осуществления настоящего изобретения;

Фиг.14 - это блок-схема последовательности сигналов способа для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно второму варианту осуществления настоящего изобретения;

Фиг.15 - это схематическое структурное представление элемента сети для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно первому варианту осуществления настоящего изобретения;

Фиг.16 - это схематическое структурное представление элемента сети для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно второму варианту осуществления настоящего изобретения;

Фиг.17 - это схематическое структурное представление элемента сети для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно третьему варианту осуществления настоящего изобретения;

Фиг.18 - это блок-схема последовательности операций способа для возвращения пользовательских данных после того, как данные элемента сети становятся недопустимыми, согласно первому варианту осуществления настоящего изобретения;

Фиг.19 - это блок-схема последовательности операций способа для возвращения пользовательских данных после того, как данные элемента сети становятся недопустимыми, согласно второму варианту осуществления настоящего изобретения;

Фиг.20 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса входящего вызова от I-CSCF после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению;

Фиг.21 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса исходящего вызова от I-CSCF или AS после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению;

Фиг.22 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса от P-CSCF и выполняет обработку как для зарегистрированного пользователя после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению;

Фиг.23 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса от P-CSCF после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению;

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

Фиг.25 - это схематическое структурное представление HSS в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению;

Фиг.26 - это схематическое структурное представление S-CSCF в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению;

Фиг.27 - это схематическое структурное представление системы для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно второму варианту осуществления настоящего изобретения;

Фиг.28 - это схематическое структурное представление другого HSS в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению; и

Фиг.29 - это схематическое структурное представление другой S-CSCF в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению.

Подробное описание изобретения

В первом варианте осуществления настоящего изобретения, способ для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, является следующим.

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

В фактической системе, вызывающей стороной первого варианта осуществления может быть P-CSCF, а элементом сети предоставления услуг может быть S-CSCF. Чтобы обеспечивать, что вызывающая сторона может восстанавливать нормальные услуги связи своевременно, в способе согласно первому варианту осуществления, сообщение о недопустимых данных может переносить информацию для инициирования вызывающей стороны, чтобы выполнять повторную регистрацию, и таким образом, вызывающая сторона может выполнять повторную регистрацию сразу после приема сообщения о недопустимых данных. В частности, способ согласно первому варианту осуществления может быть следующим. P-CSCF отправляет сообщение INVITE для исходящего вызова в S-CSCF, и когда S-CSCF не содержит пользовательские данные, S-CSCF отправляет сообщение о недопустимых данных, переносящее информацию для инициирования вызывающей стороны, чтобы выполнять повторную регистрацию, в P-CSCF.

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

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

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

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

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

Фиг.8 - это схематическое структурное представление системы для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно первому варианту осуществления настоящего изобретения. В этом варианте осуществления, система включает в себя отправляющую сторону 2 запросов на предоставление услуг, приемную сторону 3 запросов на предоставление услуг и элемент 1 сети предоставления услуг, сконфигурированный в сети. Элемент сети предоставления услуг включает в себя модуль хранения пользовательских данных и модуль сравнения пользовательских данных и дополнительно включает в себя модуль 11 отправки сообщений о недопустимости, выполненный с возможностью отправлять сообщение о недопустимых пользовательских данных отправляющей стороне запросов на предоставление услуг.

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

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

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

Фиг.12 - это схематическое структурное представление системы для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно пятому варианту осуществления настоящего изобретения. В отличие от варианта осуществления, показанного на фиг.9, в варианте осуществления, показанном на фиг.12, сеть дополнительно включает в себя модуль 6 перенаправления сообщений о недопустимости, выполненный с возможностью перенаправлять сообщение о недопустимых пользовательских данных отправляющей стороне запросов на предоставление услуг. Модуль выполнен с возможностью сообщать вызывающему пользователю или элементу сети, посредством которого обслуживается вызывающий пользователь после того, как данные вызываемого пользователя становятся недопустимыми, когда вызывающий пользователь и вызываемый пользователь находятся не в зоне покрытия одного элемента сети.

Во всех вышеописанных вариантах осуществления, отправляющая сторона запросов на предоставление услуг и приемная сторона запросов на предоставление услуг могут быть UE или элементом сети обработки информации в сети, например CSCF или AS. Элемент сети предоставления услуг может быть P-CSCF, I-CSCF или S-CSCF.

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

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

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

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

Для элементов сети без механизма обнаружения сбоев обработка предоставления услуг может быть следующей. После приема сообщения с запросом на предоставление услуг элемент сети предыдущего участка относительно отказавшего элемента сети перенаправляет запрос на предоставление услуг к элементу сети следующего участка. Если ответное сообщение от отказавшего элемента сети не принято в рамках предварительно определенного периода времени, текущий процесс предоставления услуг заканчивается, и сообщение о неработоспособном элементе сети отправляется в вызывающий терминал, отправляющий сообщение с запросом на предоставление услуг. Например, когда S-CSCF отказывает при работе, и пользователь, зарегистрированный с помощью отказавшей S-CSCF, инициирует запрос на предоставление услуг, если элементом сети предыдущего участка относительно S-CSCF является P-CSCF, то P-CSCF должна возвращать сообщение о неработоспособности в вызывающий терминал после приема запроса на предоставление услуг.

Фиг.13 - это блок-схема последовательности сигналов способа для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно первому варианту осуществления настоящего изобретения. Способ включает в себя следующие этапы.

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

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

На этапе 1303, после приема сообщения о неработоспособном элементе сети вызывающий терминал инициирует повторную регистрацию.

Фиг.14 - это блок-схема последовательности сигналов способа для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно второму варианту осуществления настоящего изобретения. Способ включает в себя следующие этапы.

На этапе 1401, вызывающий терминал инициирует начальный запрос на предоставление услуг.

На этапе 1402, элемент сети предыдущего участка относительно отказавшего элемента сети перенаправляет начальное сообщение с запросом на предоставление услуг к элементу сети следующего участка (т.е. отказавшему элементу сети).

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

На этапе 1404, после приема сообщения о неработоспособном элементе сети вызывающий терминал инициирует повторную регистрацию.

Фиг.15 - это схематическое структурное представление элемента сети для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно первому варианту осуществления настоящего изобретения. Элемент сети включает в себя модуль 151 приема сообщений с запросом на предоставление услуг и модуль 152 отправки сообщений о неработоспособных элементах сети.

Модуль 151 приема сообщений с запросом на предоставление услуг выполнен с возможностью принимать сообщение с запросом на предоставление услуг.

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

Фиг.16 - это схематическое структурное представление элемента сети для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно второму варианту осуществления настоящего изобретения. Помимо компонентов на фиг.15, элемент сети дополнительно включает в себя модуль 153 обнаружения сбоев.

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

Фиг.17 - это схематическое структурное представление элемента сети для обработки предоставления услуг после того, как элемент сети отказывает при работе, согласно третьему варианту осуществления настоящего изобретения. Помимо компонентов на фиг.15, элемент сети дополнительно включает в себя модуль 154 перенаправления сообщений с запросом на предоставление услуг и модуль 155 обнаружения и приема ответных сообщений.

Модуль 154 перенаправления сообщений с запросом на предоставление услуг выполнен с возможностью перенаправлять сообщение с запросом на предоставление услуг к элементу сети следующего участка относительно текущего элемента сети.

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

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

На этапе 1801, S-CSCF принимает сообщение с запросом на установление вызова, содержащее пользовательские идентификационные данные.

На этапе 1802, S-CSCF обнаруживает, что пользовательские данные не могут быть получены, согласно пользовательским идентификационным данным.

На этапе 1803, S-CSCF добавляет пользовательские идентификационные данные к сообщению с запросом на получение пользовательских данных и отправляет сообщение с запросом на получение пользовательских данных, содержащее пользовательские идентификационные данные, в HSS.

На этапе 1804, HSS принимает сообщение с запросом на получение пользовательских данных от S-CSCF.

На этапе 1805, HSS запрашивает сохраненное состояние регистрации пользователя и назначенную S-CSCF для пользователя согласно пользовательским идентификационным данным.

На этапе 1806, когда сохраненным состоянием регистрации пользователя является "зарегистрирован", и назначенная S-CSCF является запрашивающей S-CSCF, HSS возвращает пользовательские данные согласно сообщению с запросом.

На этапе 1807, S-CSCF выполняет управление услугами согласно возвращенным пользовательским данным.

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

На этапе 1901, S-CSCF принимает сообщение об ошибке системы S-CSCF.

На этапе 1902, S-CSCF принимает сообщение с запросом на установление вызова, содержащее пользовательские идентификационные данные.

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

На этапе 1904, сообщение с запросом на получение пользовательских данных отправляется в HSS.

На этапе 1905, HSS запрашивает состояние регистрации пользователя, сохраненное в нем, согласно пользовательским идентификационным данным.

На этапе 1906, после приема сообщения с запросом на получение пользовательских данных от S-CSCF, HSS определяет, что сообщение с запросом содержит идентификатор ошибки, и возвращает пользовательские данные согласно сообщению с запросом, когда сохраненным состоянием регистрации пользователя является "зарегистрирован".

На этапе 1907, S-CSCF выполняет управление услугами согласно возвращенным пользовательским данным.

Фиг.20 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса входящего вызова от I-CSCF после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. В этом варианте осуществления, описывается процесс для возвращения пользовательских данных, когда пользовательские данные потеряны вследствие отказа и перезагрузки системы. Как показано на фиг.20, процесс, когда S-CSCF принимает запрос на установление сеанса входящего вызова от I-CSCF, включает в себя следующие этапы.

На этапе 2001, I-CSCF принимает сообщение INVITE для входящего вызова к пользователю.

На этапе 2002, I-CSCF инициирует сообщение LIR к HSS, чтобы получать информацию о S-CSCF, обслуживающей пользователя, или требуемый набор характеристик S-CSCF.

На этапе 2003, если состоянием регистрации пользователя, записанным в HSS, является "зарегистрирован", и HSS сохраняет имя S-CSCF, обслуживающей пользователя, HSS возвращает имя S-CSCF в I-CSCF через LIA.

На этапе 2004, I-CSCF перенаправляет запрос INVITE в S-CSCF.

На этапе 2005, поскольку S-CSCF не имеет данных пользователя, S-CSCF отправляет SAR в HSS, чтобы запрашивать пользовательские данные; параметр Server Assignment Type в команде SAR задается равным UNREGISTERED_USER, чтобы сообщать HSS о том, что это запрос для незарегистрированного входящего вызова; в конкретной реализации, S-CSCF может переносить идентификатор ошибки в SAR, отправленном в HSS.

На этапе 2006, если HSS обнаруживает, что состоянием IMPU в запросе SAR, сохраненном в HSS, является "зарегистрирован", и S-CSCF, инициирующая операцию SAR, и S-CSCF, записанная в HSS, являются одинаковыми, HSS загружает пользовательские данные в S-CSCF через SAA.

HSS необязательно может определять сначала то, подписан ли IMPU на незарегистрированную услугу, и если IMPU подписан на незарегистрированную услугу, HSS загружает пользовательские данные в S-CSCF через SAA; если IMPU не подписан на незарегистрированную услугу, HSS возвращает ошибку в S-CSCF согласно предшествующему уровню техники.

Необязательно, когда S-CSCF переносит идентификатор ошибки в SAR, HSS также может загружать пользовательские данные в S-CSCF через SAA; в противном случае, HSS возвращает ошибку в S-CSCF согласно предшествующему уровню техники.

На этапе 2007, S-CSCF выполняет управление услугами согласно пользовательским данным.

На этапе 2008, S-CSCF выполняет последующую обработку.

Фиг.21 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса исходящего вызова от I-CSCF или AS после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. В этом варианте осуществления, описывается процесс реализации для возвращения пользовательских данных, когда пользовательские данные потеряны вследствие отказа и перезагрузки системы. Как показано на фиг.21, процесс, когда S-CSCF принимает запрос на установление сеанса исходящего вызова от I-CSCF или AS, включает в себя следующие этапы.

До того как AS инициирует исходящий вызов от имени пользователя, AS может получать имя S-CSCF, посредством которой пользователь обслуживается, из HSS посредством сторонней регистрации или через Sh-интерфейс. Если AS получает имя S-CSCF, посредством которой обслуживается пользователь, до того как AS инициирует исходящий вызов от имени пользователя, выполняется этап 2101a, т.е. AS маршрутизирует сеанс напрямую в S-CSCF, посредством которой пользователь обслуживается. Если имя S-CSCF, посредством которой пользователь обслуживается, не может быть получено, выполняется этап 2101b1.

На этапе 2101bl, сеанс маршрутизируется в I-CSCF в домашнем домене пользователя.

На этапе 2101b2, I-CSCF инициирует сообщение LIR к HSS, заполняет идентификационные данные вызывающего пользователя в поле заголовка P-Asserted-Identity принимаемого сообщения в LIR и добавляет флаг запроса исходящего вызова, чтобы запрашивать информацию о текущем местоположении пользователя, т.е. информацию о S-CSCF, посредством которой обслуживается пользователь.

На этапе 2101b3, HSS обнаруживает, что состоянием регистрации пользователя, сохраненным в HSS, является "зарегистрирован".

На этапе 2101b4, HSS сохраняет имя S-CSCF, обслуживающей пользователя, затем возвращает имя S-CSCF, посредством которой пользователь обслуживается, в I-CSCF через LIA.

На этапе 2101b5, I-CSCF маршрутизирует сообщение INVITE в S-CSCF, возвращенную посредством HSS.

На этапе 2102, поскольку S-CSCF не имеет данных пользователя, S-CSCF переносит в SAR пользовательские идентификационные данные как, например, поле заголовка P-Asserted-Identity сообщения, чтобы запрашивать данные подписки пользователя из HSS; параметр Server Assignment Type в команде SAR задается равным UNREGISTERED_USER; и в конкретной реализации, S-CSCF может переносить идентификатор ошибки в SAR, отправленном в HSS.

На этапе 2103, если HSS обнаруживает, что состоянием IMPU в запросе SAR, сохраненном в HSS, является "зарегистрирован", и S-CSCF, инициирующая операцию SAR, и S-CSCF, записанная в HSS, являются одинаковыми, HSS загружает пользовательские данные в S-CSCF через SAA.

Здесь, когда S-CSCF переносит идентификатор ошибки в SAR, HSS может загружать пользовательские данные в S-CSCF через SAA.

На этапе 2104, S-CSCF выполняет управление услугами.

На этапе 2105, S-CSCF выполняет последующую обработку.

Можно заметить из двух вышеописанных вариантов осуществления, что, когда HSS принимает команду SAR, отправленную посредством S-CSCF, чтобы запрашивать пользовательские данные, если S-CSCF, инициирующая операцию SAR, и S-CSCF, сохраненная в HSS, являются одинаковыми, и состоянием IMPU пользователя, запрашивающего операцию, сохраненную в HSS, является "зарегистрирован", но параметр Server Assignment Type в SAR - это UNREGISTERED_USER, HSS загружает данные об услугах пользователя в S-CSCF через SAA. HSS сначала может определять, подписан или нет IMPU в SAR на незарегистрированную услугу. Если IMPU подписан на незарегистрированную услугу, HSS загружает данные об услугах пользователя в S-CSCF через SAA. В конкретной реализации, если определяется то, что SAR S-CSCF переносит идентификатор ошибки, здесь, HSS может загружать пользовательские данные в S-CSCF через SAA, и S-CSCF предоставляет соответствующие услуги пользователю.

Фиг.22 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса от P-CSCF и выполняет обработку как для зарегистрированного пользователя после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. В этом варианте осуществления, описывается процесс реализации для возвращения пользовательских данных, когда пользовательские данные потеряны вследствие отказа и перезагрузки системы. Как показано на фиг.22, процесс, когда S-CSCF принимает запрос на установление сеанса от P-CSCF и выполняет обработку как для зарегистрированного пользователя, включает в себя следующие этапы.

На этапе 2201, UE инициирует сообщение INVITE и необязательно может заполнять общедоступные пользовательские идентификационные данные, идентифицирующие UE, в поле заголовка P-Preferred-Identity.

На этапе 2202, после приема сообщения INVITE, P-CSCF проверяет, содержит ли сообщение поле заголовка P-Preferred-Identity, и проверяет, совпадает ли значение поля заголовка с зарегистрированными общедоступными пользовательскими идентификационными данными, записанными в P-CSCF; если значение поля заголовка совпадает с зарегистрированными общедоступными пользовательскими идентификационными данными, записанными в P-CSCF, P-CSCF использует общедоступные пользовательские идентификационные данные в качестве инициатора сеанса и заполняет общедоступные пользовательские идентификационные данные в P-Asserted-Identity; если совпадающие зарегистрированные общедоступные пользовательские идентификационные данные не обнаружены, или поле заголовка P-Preferred-Identity отсутствует, P-CSCF выбирает общедоступные пользовательские идентификационные данные по умолчанию в качестве инициатора сеанса для пользователя и заполняет общедоступные пользовательские идентификационные данные в P-Asserted-Identity.

На этапе 2203, после приема сообщения INVITE, если S-CSCF не обнаруживает информации пользователя, идентифицированного в P-Asserted-Identity, S-CSCF переносит в SAR пользовательские идентификационные данные, как, например, поле заголовка P-Asserted-Identity сообщения, чтобы запрашивать данные подписки пользователя из HSS; параметр Server Assignment Type в команде SAR задается равным NO_ASSIGNMENT; в конкретной реализации S-CSCF может переносить идентификатор ошибки в SAR, отправленном в HSS.

На этапе 2204, если HSS обнаруживает, что S-CSCF, инициирующая операцию SAR, и S-CSCF, сохраненная в HSS, являются одинаковыми, HSS загружает пользовательские данные в S-CSCF через SAA; или, если HSS обнаруживает, что переносится идентификатор ошибки, HSS загружает пользовательские данные в S-CSCF через SAA.

На этапе 2205, S-CSCF инициирует соответствующие услуги согласно пользовательским данным, загруженным в SAA, и маршрутизирует последующие сеансы согласно Request-URI (т.е. вызываемой стороне) в сообщении INVITE.

Можно заметить из вышеописанного варианта осуществления, что когда S-CSCF принимает сообщение INVITE с запросом на исходящий вызов и не обнаруживает информации пользователя, комбинируя сведения об ошибке, запрошенные посредством своей системы, S-CSCF переносит в SAR пользовательские идентификационные данные, как, например, поле заголовка P-Asserted-Identity сообщения, чтобы запрашивать данные подписки пользователя из HSS; параметр Server Assignment Type в команде SAR задается равным NO_ASSIGNMENT; S-CSCF также может переносить идентификатор ошибки в SAR, отправленном в HSS, и инициирует нормальные услуги и маршрутизирует последующие сеансы после приема пользовательских данных.

Фиг.23 - это схематическое представление процесса реализации, когда S-CSCF принимает запрос на установление сеанса от P-CSCF после отказа и перезагрузки системы в способе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. В этом варианте осуществления, описывается процесс реализации для возвращения пользовательских данных, когда пользовательские данные потеряны вследствие отказа и перезагрузки системы. Как показано на фиг.23, процесс, когда S-CSCF принимает запрос на установление сеанса от P-CSCF и активирует повторную регистрацию UE, включает в себя следующие этапы.

На этапе 2301, UE инициирует сообщение INVITE и необязательно может заполнять общедоступные пользовательские идентификационные данные, идентифицирующие UE, в поле заголовка P-Preferred-Identity.

На этапе 2302, после приема сообщения INVITE, P-CSCF проверяет, содержит ли сообщение поле заголовка P-Preferred-Identity, и проверяет, совпадает ли значение поля заголовка с зарегистрированными общедоступными пользовательскими идентификационными данными, записанными в P-CSCF; если сообщение содержит поле заголовка P-Preferred-Identity, и значение поля заголовка совпадает с зарегистрированными общедоступными пользовательскими идентификационными данными, записанными в P-CSCF, P-CSCF использует общедоступные пользовательские идентификационные данные в качестве инициатора сеанса и заполняет общедоступные пользовательские идентификационные данные в P-Asserted-Identity; если совпадающие зарегистрированные общедоступные пользовательские идентификационные данные не обнаружены, или поле заголовка P-Preferred-Identity отсутствует, P-CSCF выбирает общедоступные пользовательские идентификационные данные по умолчанию в качестве инициатора сеанса для пользователя и заполняет общедоступные пользовательские идентификационные данные в P-Asserted-Identity.

На этапе 2303, после приема сообщения INVITE, S-CSCF не обнаруживает информацию пользователя и возвращает 401 ответ и запрашивает аутентификацию UE.

На этапе 2304, P-CSCF перенаправляет 401 ответное сообщение об отсутствии авторизации в UE.

На этапе 2305, UE инициирует запрос на повторную регистрацию.

На этапе 2306, P-CSCF перенаправляет запрос на повторную регистрацию в I-CSCF.

На этапе 2307, I-CSCF запрашивает имя S-CSCF, назначенной для пользователя, или набор характеристик S-CSCF, требуемых для того, чтобы обслуживать пользователя, из HSS через запрос на авторизацию пользователя (UAR).

На этапе 2308, HSS возвращает имя S-CSCF, в которой пользователь зарегистрирован первоначально, в I-CSCF через ответ по авторизации пользователя (UAA).

На этапе 2309, I-CSCF отправляет сообщение REGISTER в S-CSCF.

На этапе 2310, после приема запроса на повторную регистрацию от UE, S-CSCF обрабатывает запрос согласно начальному процессу регистрации, т.е. заполняет общедоступные пользовательские идентификационные данные в запросе авторизации на мультимедиа (MAR) с IMPU в поле заголовка TO регистрационного сообщения и заполняет конфиденциальные пользовательские идентификационные данные в запросе авторизации на мультимедиа (MAR) с именем пользователя в поле заголовка Authorization регистрационного сообщения, чтобы запрашивать данные аутентификации пользователя из HSS.

На этапе 2311, HSS получает соответствующие данные аутентификации согласно IMPI пользователя в MAR и возвращает данные аутентификации в S-CSCF через ответ по авторизации на мультимедиа (MAA).

На этапе 2312, S-CSCF отправляет 401 ответное сообщение об отсутствии авторизации в UE через I-CSCF; ответное сообщение содержит случайный оклик (RAND) и маркер аутентификации в сети (AUTN); между тем, ключ шифрования и ключ целостности отправляются в P-CSCF, чтобы устанавливать сопоставление безопасности между P-CSCF и UE для защиты целостности при последующем обмене служебными сигналами.

На этапе 2313, I-CSCF отправляет 401 ответное сообщение об отсутствии авторизации в P-CSCF.

На этапе 2314, P-CSCF отправляет 401 ответное сообщение об отсутствии авторизации в UE.

На этапе 2315, UE выполняет последующий процесс регистрации.

На этапе 2316, S-CSCF инициирует соответствующие услуги согласно пользовательским данным, полученным из HSS в процессе регистрации, и маршрутизирует последующие сеансы согласно Request-URI (т.е. вызываемой стороне) в сообщении INVITE.

Можно заметить из вышеописанного варианта осуществления, что после приема сообщения INVITE с запросом на исходящий вызов, если S-CSCF не обнаруживает информацию пользователя, S-CSCF может возвращать 401 ответное сообщение об отсутствии авторизации или другие сообщения об ошибках, чтобы запрашивать аутентификацию UE. Таким образом, S-CSCF может инициировать UE, чтобы выполнять повторную регистрацию и аутентификацию, чтобы восстанавливать пользовательские данные, инициировать нормальные услуги и маршрутизировать последующие сеансы.

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

Фиг.24 - это схематическое структурное представление системы для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно первому варианту осуществления настоящего изобретения. Как показано на фиг.24, система включает в себя S-CSCF, HSS и дополнительно включает в себя первый приемный модуль 2403, модуль 2404 запросов, первый модуль 2405 определения и модуль 2406 обратной связи.

Первый приемный модуль 2403 выполнен с возможностью принимать сообщение с запросом на получение пользовательских данных, отправленное в HSS посредством S-CSCF, при этом сообщение с запросом содержит пользовательские идентификационные данные.

Модуль 2404 запросов выполнен с возможностью запрашивать S-CSCF, назначенную для пользователя, согласно пользовательским идентификационным данным.

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

Модуль 2406 обратной связи выполнен с возможностью возвращать пользовательские данные согласно сообщению с запросом.

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

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

Затем, S-CSCF отправляет сообщение с запросом на получение пользовательских данных, содержащее добавленные пользовательские идентификационные данные, в HSS.

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

Фиг.25 - это схематическое структурное представление HSS в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. Как показано на фиг.25, HSS 241 включает в себя первый приемный модуль 2403, модуль 2404 запросов, первый модуль 2405 определения и модуль 2406 обратной связи.

Первый приемный модуль 2403 выполнен с возможностью принимать сообщение с запросом на получение пользовательских данных, отправленное посредством S-CSCF, при этом сообщение с запросом содержит пользовательские идентификационные данные.

Модуль 2404 запросов выполнен с возможностью запрашивать S-CSCF, назначенную для пользователя, согласно пользовательским идентификационным данным.

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

Модуль 2406 обратной связи выполнен с возможностью возвращать пользовательские данные согласно сообщению с запросом.

Фиг.26 - это схематическое структурное представление S-CSCF в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. Как показано на фиг.26, S-SCSF 242 включает в себя первый модуль 2401 добавления.

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

Дополнительно, после выполнения запроса относительно сохраненного состояния регистрации пользователя согласно пользовательским идентификационным данным, HSS определяет, является или нет сохраненным состоянием регистрации пользователя "зарегистрирован", и если сохраненным состоянием регистрации пользователя является "зарегистрирован", и назначенная S-CSCF является запрашивающей S-CSCF, HSS возвращает пользовательские данные согласно сообщению с запросом.

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

Фиг.27 - это схематическое структурное представление системы для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно второму варианту осуществления настоящего изобретения. Как показано на фиг.27, система включает в себя S-CSCF, HSS и дополнительно включает в себя второй приемный модуль 2409, модуль 2408 сообщений об ошибках, второй модуль 2402 определения, второй модуль 2410 добавления, третий модуль 2407 определения и модуль 2406 обратной связи.

Второй приемный модуль 2409 выполнен с возможностью принимать сообщение с запросом на установление вызова, отправленное в S-CSCF, при этом сообщение с запросом содержит пользовательские идентификационные данные.

Модуль 2408 сообщений об ошибках выполнен с возможностью инициировать второй модуль определения после приема сообщения об ошибке системы S-CSCF.

Второй модуль 2402 определения выполнен с возможностью определять, может ли S-CSCF обнаруживать пользовательские данные согласно пользовательским идентификационным данным, и инициировать второй модуль добавления, когда пользовательские данные не могут быть обнаружены согласно пользовательским идентификационным данным.

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

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

Модуль 2406 обратной связи выполнен с возможностью возвращать пользовательские данные согласно сообщению с запросом.

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

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

Фиг.28 - это схематическое структурное представление другого HSS в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. Как показано на фиг.28, HSS включает в себя третий модуль 2407 определения и модуль 2406 обратной связи.

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

Модуль 2406 обратной связи выполнен с возможностью возвращать пользовательские данные согласно сообщению с запросом.

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

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

Фиг.29 - это схематическое структурное представление другой S-CSCF в системе для возвращения пользовательских данных в системе для обработки предоставления услуг после того, как данные элемента сети становятся недопустимыми, согласно настоящему изобретению. Как показано на фиг.29, S-CSCF включает в себя второй приемный модуль 2409, модуль 2408 сообщений об ошибках, второй модуль 2402 определения и второй модуль 2410 добавления.

Второй приемный модуль 2409 выполнен с возможностью принимать сообщение с запросом на установление вызова, отправленное в S-CSCF, при этом сообщение с запросом содержит пользовательские идентификационные данные.

Модуль 2408 сообщений об ошибках выполнен с возможностью инициировать второй модуль определения после приема сообщения об ошибке системы S-CSCF.

Второй модуль 2402 определения выполнен с возможностью определять, может ли S-CSCF обнаруживать пользовательские данные согласно пользовательским идентификационным данным, и инициировать второй модуль добавления, когда пользовательские данные не могут быть обнаружены согласно пользовательским идентификационным данным.

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

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

Можно заметить из вышеописанных вариантов осуществления, что варианты осуществления настоящего изобретения усовершенствуют функции HSS и S-CSCF, повышают устойчивость к сбоям HSS и S-CSCF; в случае если пользовательские данные потеряны вследствие ошибки S-CSCF, если запрос на установление сеанса INVITE для IMPU, первоначально зарегистрированного в S-CSCF, отправленный посредством I-CSCF или AS, принят после перезагрузки, когда S-CSCF запрашивает пользовательские данные из HSS, HSS не возвращает ошибку напрямую в S-CSCF, а напрямую загружает данные об услугах пользователя в S-CSCF через SAA при обнаружении того, что запрашивающая S-CSCF и назначенная S-CSCF являются одинаковыми или переносится идентификатор ошибки. Между тем, когда пользовательские данные потеряны вследствие ошибки S-CSCF, если запрос на установление сеанса INVITE для IMPU, первоначально зарегистрированного в S-CSCF, отправленный посредством P-CSCF, принят после перезагрузки, S-CSCF отправляет SAR, чтобы запрашивать пользовательские данные из HSS, и инициирует услуги и устанавливает сеанс вместо возвращения ответа со сбоем напрямую в P-CSCF. Таким образом, в случае если S-CSCF содержит ошибку, такую как отказ системы, и перезагружается, незарегистрированный входящий вызов или исходящий вызов, инициированный посредством UE, или исходящий вызов, инициированный посредством AS от имени пользователя, по-прежнему может предоставляться.

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

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

Claims (9)

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

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

3. Способ по п.2, отличающийся тем, что сообщение с запросом на установление вызова - это сообщение INVITE с запросом на незарегистрированный входящий вызов, отправленное посредством опрашивающей функции управления сеансами вызовов (I-CSCF), или сообщение INVITE с запросом на исходящий вызов, инициированное посредством сервера приложений (А8); и/или сообщение INVITE с запросом на исходящий вызов, отправленное посредством прокси-функции управления сеансами вызовов (P-CSCF) и инициированное посредством абонентского устройства (UE).

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

5. Способ по любому из пп.1-4, отличающийся тем, что дополнительно содержит этап, на котором выполняют, посредством S-CSCF, управление услугами согласно возвращенным пользовательским данным.

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

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

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

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

Images