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

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

Иллюстрации

Показать все

Реферат

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

Настоящая заявка является выделенной заявкой из Российской Патентной Заявки №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 включает в себя первый приемный модуль, модуль запросов, первый модуль определения и модуль обратной связи.

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