СПОСОБ, УСТРОЙСТВО И СИСТЕМА АВАРИЙНОГО ВОССТАНОВЛЕНИЯ IMS Российский патент 2012 года по МПК H04W8/30 

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

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

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

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

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

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

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

Решение вышеизложенных проблем существует в уровне техники. А именно в ходе регистрация S-CSCF создает резервную копию пользовательских данных, связанных с регистрацией, например, информации приватного идентификатора пользователя IMS (IMPI), информации публичного идентификатора пользователя IMS (IMPU), зарегистрированного адреса контакта и информации пути (Path), на сервере домашних абонентов (HSS). Когда S-CSCF дает сбой и UE использует сеть, опрашивающая CSCF (I-CSCF) может выбрать другую S-CSCF для предоставления UE сеансовых услуг, и новая S-CSCF может получить пользовательские данные резервного копирования IMPU, который использует услуги, для восстановления соответствующих услуг UE, таким образом, реализовав аварийное восстановление S-CSCF.

В настоящее время, ID пользователя, применяемые в сети IMS, в основном, включают в себя IMPI и IMPU, которые сохраняются на HSS в режиме подписки. Когда пользователь осуществляет соответствующую операцию услуги, соответствующие объекты в сети, например, I-CSCF, S-CSCF и сервер приложений (AS) получают данные подписки пользователя через ID пользователя. В IMS существует сложная взаимосвязь между ID пользователей и данными подписки. Согласно фиг.1 одна подписка IMS включает в себя всю информацию подписки, которую одно UE может передавать по интерфейсу Cx. Одна подписка IMS может включать в себя множественные IMPI, но один IMPI принадлежит только одной подписке IMS; один IMPI может включать в себя множественные IMPU, и один IMPU может совместно использоваться множественными IMPI. Таким образом, взаимосвязь между подпиской IMS и IMPI является соответствием «один в многие», и взаимосвязь между IMPI и IMPU является соответствием «многие в многие». Это позволяет гибко реализовать логику услуг, например, «один IMPI - много IMPU», «один IMPU - много IMPI» и «много IMPI - много IMPU».

Следующая проблема становится очевидной из вышеизложенного технического решения аварийного восстановления IMS: согласно уровню техники никакое детальное решение восстановления не прорабатывалось в отношении комплексной модели пользовательских данных в IMS; поэтому при использовании вышеизложенного технического решения услуги «один MPU - много IMPI» и «много IMPI - много IMPU» пользователей могут быть потеряны, что ухудшает ощущение непрерывности услуг пользователя. Например, при рассмотрении модели пользовательских данных, представленной на фиг.2, решение обработки аварийного восстановления IMS согласно уровню техники выглядит следующим образом:

Предполагается, что все экземпляры IMPI и IMPU в подписке IMS, показанные на фиг.2, зарегистрированы на S-CSCF1. Если S-CSCF1 дает сбой и если UE (IMPI1 и IMPU3), связанное с услугой, осуществляет периодическую перерегистрацию, запрос регистрации пересылается на S-CSCF2 согласно вышеизложенному техническому решению. S-CSCF2 успешно регистрирует IMPI1 и IMPU3 посредством стандартного процесса регистрации и восстанавливает пользовательские данные резервного копирования IMPI1 и IMPU3 в S-CSCF2. Кроме того, HSS изменяет имя сервера, сохраненное для подписки IMS, с S-CSCF1 на S-CSCF2, после чего может отправлять сообщение Ответа завершения регистрации (RTA) на начальную S-CSCF (S-CSCF1) для извещения, что процесс миграции UE является необязательным и что даже в случае отправки сообщения RTA, отправка дает сбой вследствие сбоя начальной S-CSCF. На этом процесс аварийного восстановления, обусловленный регистрацией UE (IMPI1 и IMPU3), завершается. В случае вызова IMPU3: после приема запроса вызова, I-CSCF осуществляет поиск в HSS на предмет S-CSCF (S-SCCF2), которая обслуживает IMPU3 (фактически, подписку IMS); S-CSCF2 находится в нормальном состоянии, и поэтому I-CSCF не добавляет флаг аварийного восстановления в запрос вызова, но маршрутизирует запрос непосредственно на S-CSCF2; после приема запроса S-CSCF2 определяет, что IMPU3 зарегистрировал терминал IMPI1 локально и что запрос вызова не содержит флаг аварийного восстановления, поэтому S-CSCF2 не осуществляет аварийное восстановление, но решает, отправлять ли запрос вызова на IMPI1; в результате услуга «один IMPU - много IMPI» (IMPI1 и IMPI2) для IMPU3 теряется.

Раскрытие изобретения

Изобретение предусматривает способ, устройство и систему аварийного восстановления IMS, позволяющие избежать потери услуги «один IMPU - много IMPI», «один IMPI - много IMPU» или «много IMPI - много IMPU», которая связана с комплексной моделью пользовательских данных в IMS в ходе аварийного восстановления.

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

запускают резервную CSCF;

получают посредством резервной CSCF пользовательские данные резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данные конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения пользователя; и

восстанавливают посредством резервной CSCF соответствующую услугу согласно пользовательским данным резервного копирования зарегистрированных IMPI и данным конфигурации пользовательских услуг IMPU в подписке IMS.

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

запускают посредством CSCF резервное копирование данных аварийного восстановления, и

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

Согласно третьему аспекту изобретения CSCF включает в себя в первой форме реализации:

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

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

Согласно третьему аспекту изобретения CSCF включает в себя во второй форме реализации:

модуль получения данных аварийного восстановления, сконфигурированный для получения пользовательских данных резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данных конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения пользователя после того, как услуга запускает аварийное восстановление; и

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

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

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

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

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

модуль принятия решения, сконфигурированный для принятия решения, осуществлять ли аварийное восстановление для CSCF; и

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

Согласно пятому аспекту изобретения IMS, в общем случае, включает в себя CSCF и сетевой объект хранения. Сетевой объект хранения включает в себя в первой форме реализации:

модуль хранения пользовательских данных, сконфигурированный для хранения данных конфигурации пользовательских услуг, пользовательских данных резервного копирования для восстановления пользовательских услуг и информации CSCF, где зарегистрирован пользователь.

Сетевой объект хранения дополнительно включает в себя модуль обработки аварийного восстановления. Модуль обработки аварийного восстановления включает в себя:

модуль принятия решения, сконфигурированный для принятия решения, осуществлять ли аварийное восстановление для CSCF; и

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

IMS включает в себя CSCF и сетевой объект хранения. Сетевой объект хранения включает в себя во второй форме реализации:

модуль хранения пользовательских данных, сконфигурированный для хранения данных конфигурации пользовательских услуг, пользовательских данных резервного копирования для восстановления пользовательских услуг и информации CSCF, где зарегистрирован пользователь, и

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

Сетевой объект хранения дополнительно включает в себя в этой форме реализации:

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

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

CSCF включает в себя, в этой форме реализации:

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

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

Согласно вышеприведенному решению после того как CSCF дает сбой или перезапускается, пользовательские данные с пользователем и данные конфигурации пользовательских услуг IMPU можно восстановить путем единовременного запуска услуги пользователя. Данные конфигурации пользовательских услуг других зарегистрированных IMPU и пользовательские данные резервного копирования IMPI пользователя, не восстановленные в этом запуске услуги, восстанавливаются по прошествии времени. Таким образом, можно восстанавливать услуги «один IMPU - много IMPI», «один IMPI - много IMPU» или «много IMPI - много IMPU», и это дает пользователю лучшее ощущение непрерывности услуги.

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

Фиг.1 - модель пользовательских данных согласно уровню техники.

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

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

Фиг.4 - модель данных расширенного сообщения Ответа назначения сервера (SAA) или Запроса профиля активной доставки (PPR) согласно варианту осуществления настоящего изобретения.

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

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

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

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

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

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

Фиг.11 - блок-схема последовательности операций способа аварийного восстановления согласно шестому варианту осуществления настоящего изобретения.

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

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

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

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

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

Фиг.17 - сетевая структура IMS, подлежащая аварийному восстановлению согласно варианту осуществления настоящего изобретения.

Фиг.18 - структура модуля обработки аварийного восстановления согласно варианту осуществления настоящего изобретения.

Фиг.19 - структура модуля принятия решения согласно варианту осуществления настоящего изобретения.

Фиг.20 - структура модуля принятия решения, показанного на фиг.19, согласно другому варианту осуществления настоящего изобретения.

Фиг.21 - структура модуля принятия решения, показанного на фиг.19, согласно еще одному варианту осуществления настоящего изобретения.

Фиг.22 - другая сетевая структура IMS, подлежащая аварийному восстановлению, согласно варианту осуществления настоящего изобретения.

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

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

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

Фиг.26 - структура CSCF согласно варианту осуществления изобретения.

Осуществление изобретения

Нужно заранее сделать резервную копию пользовательских данных, необходимых для аварийного восстановления. Можно применять множественные режимы резервного копирования пользовательских данных. Например, когда UE зарегистрировано нормально, S-CSCF, которая предоставляет услуги пользователю, отправляет пользовательские данные резервного копирования на сетевой объект хранения, например HSS, посредством расширенной пары атрибут-значение (AVP): Пользователь-Данные резервного копирования (User-Backup-Data) в Запросе назначения сервера (SAR) регистрации. Сетевой объект хранения может хранить пользовательские данные резервного копирования, например может хранить пользовательские данные резервного копирования с использованием индекса IMPI. Для каждого IMPI необходимо сохранять только один фрагмент данных резервного копирования.

В вышеупомянутом процессе реализации резервного копирования пользовательских данных S-CSCF может создавать резервную копию данных, связанных с регистрацией пользователя, в том числе, но без ограничения, адреса контакта и информации пути. Кроме того, S-CSCF может создавать резервную копию данных подписки состояния регистрации UE, в том числе, но без ограничения, информацию Call-ID (Идентификатор Вызова), From (Откуда), To (Куда), Cseq (С_послед.) и Record-Route (Запись-Направление).

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

Этапы 1-3: S-CSCF обрабатывает запрос регистрации UE и, в конце концов, соглашается с запросом регистрации UE.

Этапы 4-6: S-CSCF проверяет, изменяются ли ключевые данные регистрации UE.

A. Если UE не создало информацию регистрации локально, информация регистрации создается путем этой регистрации.

B. Если UE создало информацию регистрации локально, но ключевые данные регистрации изменяются, например, если зарегистрированная информация пути или зарегистрированная информация контакта (Contact) изменяется или если зарегистрированная информация пути и зарегистрированная информация контакта изменяются, S-CSCF должна создать резервную копию ключевых данных регистрации (информации пути и информации контакта) на HSS посредством сообщения SAR (REGISTRATION или RE_REGISTRATION); кроме того, при наличии ключевых данных подписки регистрации (информация Call-ID, From, To, Cseq и Record-Route) необходимо создать и их резервную копию.

Если на этапе 4 на HSS не создается резервная копия данных, этапы 5 и 6 можно опустить.

Если на HSS хранятся данные резервного копирования зарегистрированного UE, и сообщение SAR (REGISTRATION (Регистрация) или RE_REGISTRATION (Повторная_регистрация)) не несет данные резервного копирования, то HSS может проверить, является ли S-CSCF, которая посылает запрос, той же функцией, которая носит ранее сохраненное имя S-CSCF. Если нет, то HSS может удалить сохраненные данные резервного копирования. Этот случай может иметь место, когда сбойная начальная S-CSCF имеет возможность отправлять данные резервного копирования, а новая S-CSCF не имеет такой возможности.

Этапы 7 и 8: S-CSCF возвращает сообщение 200 OK на UE.

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

Этапы 9-12: S-CSCF принимает запрос подписки регистрации от UE и соглашается с запросом подписки регистрации, после чего возвращает сообщение успешной подписки на UE.

Этапы 13-15: S-CSCF проверяет, изменяются ли ключевые данные подписки регистрации UE.

A. Если UE не создало информацию подписки локально, информация подписки регистрации создается через эту подписку регистрации.

B. Если UE создало информацию подписки регистрации локально, но ключевые данные подписки регистрации изменяются, например, в случае изменения одного или нескольких фрагментов информации подписки регистрации, например информации Call-ID, From, To и Record-Route, S-CSCF создает резервную копию вышеозначенных ключевых данных подписки регистрации на HSS посредством сообщения SAR (REGISTRATION, RE_REGISTRATION или другого вновь расширенного значения типа назначения услуги); кроме того, S-CSCF может создавать резервную копию ключевых данных регистрации на HSS. В запросе S-CSCF может задать параметр "User-Data-Already-Available" (Пользователь-Данные-Уже-Доступно), равным значению "USER_DATA_ALREADY_AVAILABLE", во избежание повторной отправки данных конфигурации услуг.

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

Этап 1: После запуска аварийного восстановления S-CSCF получает пользовательские данные резервного копирования от HSS.

Этап 2: S-CSCF анализирует данные подписки регистрации, содержащиеся в пользовательских данных резервного копирования. Согласно данным подписки регистрации S-CSCF отправляет сообщение NOTIFY (Извещения) на UE для извещения UE о незамедлительной регистрации.

Этап 3: UE возвращает сообщение 200 OK.

Этап 4: Согласно указанию сети UE немедленно инициирует регистрацию для восстановления сетевых услуг.

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

Заметим, что, когда S-CSCF запрашивает HSS восстановить данные конфигурации услуг и данные резервного копирования IMPU, HSS может возвратить данные резервного копирования множественных IMPI, поскольку один IMPU может быть связан с множественными IMPI. Данные резервного копирования можно передавать через новую AVP Associated-Back-Info (Связанное - Обратная информация) в расширенном сообщении SAA или PPR. Например, добавив новую AVP под именем "Associated-Registered-Identities" (Связанное - Зарегистрированные идентификаторы) в сообщение SAA, HSS возвращает информацию всех зарегистрированных IMPI, которые связаны с IMPU; альтернативно, добавив флаговый бит в начальную AVP: Associated-Identities (Связанное - идентификаторы), HSS возвращает информацию зарегистрированных IMPI, которые связаны с IMPU.

В ходе фактической реализации Associated-Back-Info может приобретать составную структуру AVP. Составная структура AVP выглядит следующим образом:

Associated-Back-Info::= < AVP header: TBD >

{ User-Name }

*{User-Backup-Data}

Вышеописанная AVP структура включает в себя две AVP, а именно User-Name (Имя пользователя) и User-Backup-Data. User-Name несет информацию IMPI; User-Backup-Data несет данные резервного копирования IMPI, переносимого в User-Name. Когда один IMPU связан с множественными IMPI, HSS может возвращать сообщение, несущее множественные AVP Associated-Back-Info.

Альтернативно Associated-Back-Info можно задать как AVP, содержащую текстовую информацию. Модель данных показана на фиг.4. Каждый экземпляр Associated-Back-Info включает в себя от одного до n экземпляров User-Back-Info. Каждый экземпляр User-Back-Info включает в себя один экземпляр User-Name и, по меньшей мере, один экземпляр User-Backup-Data. Каждый экземпляр User-Backup-Data включает в себя данные резервного копирования IMPI, переносимого в User-Name, по меньшей мере, информацию пути и контакта, связанную с регистрацией IMPI.

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

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

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

Этап S102: Резервная CSCF получает пользовательские данные резервного копирования зарегистрированных IMPI, которые связаны с IMPU пользователя, и данные конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения пользователя, например HSS. В этом варианте осуществления в ходе восстановления данных вновь выбранной S-CSCF или успешно перезапущенной S-CSCF, восстанавливаются не только данные конфигурации услуг IMPU и пользовательские данные резервного копирования IMPI, которые связаны с этим/ой вызовом или регистрацией, но также пользовательские данные резервного копирования всех зарегистрированных IMPI, которые связаны с пользователем, и данных конфигурации пользовательских услуг IMPU в подписке IMS.

Этап S103: Резервная S-CSCF восстанавливает соответствующую услугу пользователя согласно полученным пользовательским данным резервного копирования зарегистрированных IMPI и данным конфигурации пользовательских услуг IMPU в подписке IMS.

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

На фиг.6 показана блок-схема последовательности операций способа аварийного восстановления согласно первому варианту осуществления изобретения.

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

Согласно фиг.6 UE регистрируется (от этапа 1. REGISTER до этапа 17. 200 OK). Конкретный процесс регистрации идентичен стандартному процессу IMS, где:

Этап L2: Согласно стандартному процессу HSS может отправлять сообщение Запроса завершения регистрации (RTR) на начальную S-CSCF (S-CSCF1) UE после изменения ServerName (Имя сервера) согласно сообщению Запроса аутентификации мультимедиа (Multimedia-Authentication-Request) (MAR). В первом варианте осуществления после того, как HSS отправляет сообщение RTR (SERVER_CHANGE (Сервер_изменился)) на другие связанные зарегистрированные UE, которые затронуты, HSS не изменяет состояние регистрации UE, если начальная S-CSCF (S-CSCF1) UE не отвечает; если HSS узнает, что начальная S-CSCF (S-CSCF1) UE дала сбой, посредством механизма обнаружения сбоя, HSS не нужно отправлять сообщение RTR и не нужно изменять состояние регистрации UE.

В первом варианте осуществления, определив, что S-CSCF1 дала сбой (например, S-CSCF1 не отвечает на сообщение RTR или сбой S-CSCF1 обнаружен посредством механизма обнаружения сбоя), HSS отправляет сообщение PPR (этап 18. PPR) на S-CSCF2 для восстановления пользовательских данных в подписке IMS. По сравнению со стандартным сообщением PPR, отправленное сообщение PPR содержит дополнительную AVP: User-Backup-Data, которая используется для переноса пользовательских данных резервного копирования и для предписания S-CSCF2, осуществлять аварийное восстановление для пользовательской информации в сообщении PPR.

В общем случае одно сообщение PPR несет только один профиль пользователя, который инкапсулирован в одну AVP: Пользователь-Данные; т.е. одно сообщение PPR несет только одну Пользователь-Данные. Когда множественные IMPU, зарегистрированные по одному IMPI, находятся в разных наборах неявной регистрации, HSS должен отправить сообщение PPR, несущее пользовательские данные резервного копирования, разным наборам неявной регистрации.

Для снижения трафика сообщений на интерфейсе Cx вариант осуществления изобретения предусматривает другой необязательный режим расширения для сокращения повторной передачи данных резервного копирования. Таким образом, в сообщении PPR могут переноситься множественные AVP под именем Пользователь-Данные, и каждая Пользователь-Данные содержит данные конфигурации пользовательских услуг (профиль обслуживания) всех IMPU в одном наборе неявной регистрации. Таким образом, пользовательские данные резервного копирования одного IMPI и профили обслуживания всех зарегистрированных IMPU, связанных с IMPI, можно восстанавливать путем однократного обмена сообщением PPR. Данные конфигурации пользовательских услуг определяют тип услуги пользовательского приложения.

После приема сообщения PPR S-CSCF2 сохраняет пользовательские данные резервного копирования и данные конфигурации пользовательских услуг, переносимые в сообщении PPR, и возвращает сообщение Ответа профиля активной доставки (Push Profile Answer) (PPA) (этап 19. PPA) на HSS. S-CSCF2 осуществляет операции восстановления для пользователя согласно пользовательским данным резервного копирования и данным конфигурации пользовательских услуг, переносимым в сообщении PPR; например, S-CSCF2 отправляет сообщение NOTIFY на UE для запуска немедленной перерегистрации (этап 20. обработка восстановления); альтернативно при наличии запроса услуги, связанного с пользователем, S-CSCF2 определяет тип услуги пользовательского приложения согласно данным конфигурации пользовательских услуг и осуществляет восстановление услуги согласно пользовательским данным резервного копирования.

Если другие зарегистрированные IMPU или IMPI, которые затронуты на HSS, подлежат восстановлению, этапы 18-20 повторяются, пока на будут восстановлены данные всех зарегистрированных IMPU и IMPI (этап 21. PPR - этап 23. обработка восстановления).

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

На фиг.7 показана блок-схема последовательности операций способа аварийного восстановления согласно второму варианту осуществления изобретения.

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

Согласно фиг.7 конкретный процесс аварийного восстановления включает в себя следующие этапы:

Этапы 1-5: После приема запроса завершения услуги от UE или запроса инициирования услуги от AS вместо UE, I-CSCF отправляет сообщение запроса на HSS для получения текущей S-CSCF. Если текущая S-CSCF дает сбой, I-CSCF взаимодействует с HSS для выбора другой S-CSCF и затем пересылает запрос услуги с флагом аварийного восстановления на новую S-CSCF; если текущая S-CSCF, указанная HSS, успешно перезапускается после сбоя, I-CSCF пересылает запрос услуги на успешно перезапущенную S-CSCF.

S-CSCF (резервная S-CSCF), которая принимает запрос услуги, определяет, что аварийное восстановление необходимо осуществлять, согласно флагу аварийного восстановления в принятом запросе услуги. Альтернативно запрос услуги может не нести флаг аварийного восстановления, и когда резервная S-CSCF обнаруживает, что UE не зарегистрировано локально, резервная S-CSCF отправляет сообщение SAR (UNREGISTERED_USER (Незарегистрированный пользователь)) на HSS. После приема сообщения, HSS обнаруживает, что UE не находится в состояние UNREGISTERED, после чего возвращает сообщение SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (Ошибка диаметра в типе назначения)). Резервная S-CSCF может осуществлять аварийное восстановление после приема сообщения SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE).

Этапы 6-7: HSS может определить, что резервная S-CSCF должна восстановить пользовательские данные согласно запросу RESTORE, поданному резервной S-CSCF на этапе 3, и затем отправить сообщение PPR для восстановления пользовательских данных (по аналогии с этапами 18 и 9 в первом варианте осуществления).

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

(1) Если с S-CSCF, полученной от HSS, нельзя контактировать, AS может направлять сеанс на I-CSCF для дальнейшего направления. Процесс аварийного восстановления такой же, как описано выше.

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

На фиг.8 показана блок-схема последовательности операций способа аварийного восстановления согласно третьему варианту осуществления изобретения.

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

Согласно фиг.8 конкретный процесс аварийного восстановления включает в себя следующие этапы:

Этапы 1-6: UE регистрируется в процессе переключения с S-CSCF1 на S-CSCF2 (резервную S-CSCF).

Этап L1: Этот этап идентичен этапу L2 в первом варианте осуществления. Если HSS не обнаруживает, что S-CSCF1 дала сбой, HSS отправляет сообщение RTR; если HSS не принимает сообщение RTA, HSS не изменяет состояние регистрации UE.

Этапы 7-9: UE посылает запрос регистрации; I-CSCF отправляет запрос регистрации на S-CSCF2 путем обмена сообщением UAR или UAA с HSS; и S-CSCF2 отправляет сообщение SAR на HSS после аутентификации UE.

Этап 10: HSS отправляет на S-CSCF2 сообщение SAA, несущее информацию всех зарегистрированных IMPI в подписке IMS в дополнение к Associated-Identities (всем IMPI в подписке IMS); в третьем варианте осуществления информация зарегистрированных IMPI может возвращаться путем добавления AVP: Associated-Registered-Identities или добавления флагового бита в начальную AVP: Associated-Identities.

Этапы 11-12: S-CSCF возвращает сообщение 200 OK на UE после приема сообщения SAA.

Этап 13: Получив список зарегистрированных IMPI, S-CSCF2 проверяет локально зарегистрированные UE в подписке IMS. Если зарегистрированные UE, указанные в пользовательской информации зарегистрированного IMPI, которая обеспечена HSS, не зарегистрированы в S-CSCF2, S-CSCF2 может отправлять сообщение Запроса восстановления услуги (SRR) или SAR, несущее информацию индикации аварийного восстановления, на HSS. Сообщение SRR или SAR несет один IMPI, который не зарегистрирован в списке зарегистрированных IMPI, для запрашивания HSS восстановить пользовательские данные резервного копирования IMPI.

Этап 14: После приема запроса для восстановления пользовательских данных незарегистрированного IMPI в списке зарегистрированных IMPI, HSS возвращает ответ, несущий пользовательские данные резервного копирования IMPI, и данные конфигурации пользовательских услуг IMPU, связанного с IMPI.

В третьем варианте осуществления сообщение SRA или SAA можно расширить таким образом, чтобы оно могло нести множественные AVP Пользователь-Данные и, таким образом, возвращать данные конфигурации пользовательских услуг IMPU, которые связаны с одним IMPI, но принадлежат разным наборам неявной регистрации.

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

Этапы 15-16: Если список зарегистрированных IMPI, возвращаемый на этапе 10, содержит множественные IMPI, операции восстановления на этапах 13 и 14 можно осуществлять для каждого IMPI.

На фиг.9 показана блок-схема последовательности операций способа аварийного восстановления согласно четвертому варианту осуществления изобретения.

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

Согласно фиг.9 конкретный процесс аварийного восстановления включает в себя следующие этапы:

Этапы 1-11: UE посылает запрос регистрации после успешного перезапуска S-CSCF; I-CSCF отправляет запрос регистрации на перезапущенную S-CSCF путем обмена сообщением UAR или UAA с HSS; и S-CSCF отправляет сообщение SAR на HSS после аутентификации UE.

Этапы 12-18: Эти этапы идентичны этапам 10-16 в третьем варианте осуществления. Перезапущенная S-CSCF может полностью восстанавливать все пользовательские данные в подписке IMS.

На фиг.10 показана блок-схема последовательности операций способа аварийного восстановления согласно пятому варианту осуществления изобретения.

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

Согласно фиг.10 конкретный процесс аварийного восстановления включает в себя следующие этапы:

Этапы 1-3: После приема запроса завершения услуги от UE или запроса инициирования услуги от AS вместо UE, I-CSCF отправляет сообщение запроса на HSS для получения текущей S-CSCF. Если текущая S-CSCF дает сбой, I-CSCF взаимодействует с HSS для выбора другой S-CSCF и затем пересылает запрос услуги с флагом аварийного восстановления на новую S-CSCF; если текущая S-CSCF, указанная HSS, успешно перезапускается после сбоя, I-CSCF пересылает запрос услуги на успешно перезапущенную S-CSCF.

S-CSCF, которая принимает запрос услуги, определяет, что аварийное восстановление необходимо осуществлять согласно флагу аварийного восстановления в принятом запросе услуги. Альтернативно запрос услуги может не нести флаг аварийного восстановления, и, когда S-CSCF обнаруживает, что UE не зарегистрировано локально, S-CSCF отправляет сообщение SAR (UNREGISTERED_USER) на HSS. После приема сообщения HSS обнаруживает, что UE не находится в состояние UNREGISTERED, после чего возвращает сообщение SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE). S-CSCF может осуществлять аварийное восстановление после приема сообщения SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE).

Этап 4: В ответе аварийного восстановления от HSS, помимо профиля обслуживания IMPU или профилей обслуживания всех IMPU в наборе неявной регистрации IMPU и пользовательских данных резервного копирования IMPI, должна возвращаться информация зарегистрированных IMPI в подписке IMS. В пятом варианте осуществления, например, AVP: Associated-Registered-Identities может добавляться к ответу восстановление для переноса информации зарегистрированных IMPI.

Этапы 6-9: Этапы идентичны этапам 13-16 (обработки восстановления) в третьем варианте осуществления.

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

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

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

Кроме того, запрос аварийного восстановления можно подавать с индексом IMPU, в соответствии со способом аварийного восстановления согласно шестому варианту осуществления изобретения, показанному на фиг.11.

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

Согласно фиг.11 процесс полного восстановления данных подписки IMS включает в себя следующие этапы:

Этап 1: Резервная S-CSCF отправляет сообщение SRR или SAR на HSS.

Этап 2: HSS возвращает сообщение SRA или SAA, несущее данные резервного копирования всех зарегистрированных IMPI, которые непосредственно связаны с IMPU, переносимые в сообщении SRR или SAR; через AVP: Пользователь-Данные, HSS возвращает данные конфигурации пользовательских услуг всех IMPU в UE или наборе неявной регистрации IMPU. Кроме того, HSS возвращает список других зарегистрированных IMPU в подписке IMS.

Этап 3: S-CSCF восстанавливает пользовательские данные, переносимые в сообщении SRA или SAA. Получив список зарегистрированных IMPU, S-CSCF последовательно восстанавливает полные данные IMPU через Server-Assignment-Type (Сервер - Тип назначения) в расширенном сообщении SAR; например, S-CSCF добавляет новый тип операции (RESTORE_ONE (Восстановить один)) в сообщение SAR, чтобы запросить у HSS последовательное восстановление полных данных IMPU.

Этап 4: После приема сообщения SAR типа RESTORE_ONE, HSS возвращает данные резервного копирования (User-Backup-Data) всех зарегистрированных IMPI, которые непосредственно связаны с IMPU, переносимые в сообщении SAR. Посредством AVP Пользователь-Данные HSS возвращает профиль пользователя UE IMPU или UE в наборе неявной регистрации IMPU. S-CSCF восстанавливает пользовательские данные согласно данным.

Если IMPU список, возвращаемый на этапе 2, содержит множественные IMPU, операции восстановления на этапах 3 и 4 осуществляются для каждого IMPU.

На фиг.12 показана блок-схема последовательности операций способа аварийного восстановления согласно седьмому варианту осуществления изобретения.

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

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

Этап 1: S-CSCF отправляет сообщение SRR или SAR на HSS.

Этап 2: HSS запрашивает экземпляры регистрации всех IMPI и IMPU в подписке IMS IMPU, переносимые в сообщении SRR или SAR, после чего возвращает все пользовательские данные резервного копирования и данные конфигурации пользовательских услуг в экземплярах регистрации на S-CSCF через сообщение SRA или SAA.

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

На фиг.13 показана блок-схема последовательности операций способа аварийного восстановления согласно восьмому варианту осуществления изобретения.

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

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

Этап 1: S-CSCF взаимодействует с HSS посредством сообщения MAR или MAA, SRR или SRA, или SAR или SAA.

Этап 2: HSS может изменить ServerName путем обмена сообщением MAR или MAA или определить, что начальная S-CSCF дала сбой (например, в отсутствие ответа на отправленное сообщение RTR). Затем HSS отправляет все пользовательские данные резервного копирования и данные конфигурации пользовательских услуг в подписке IMS затронутого IMPU на резервную S-CSCF посредством сообщения PPR.

Альтернативно HSS может узнать, что текущим сценарием является сценарий аварийного восстановления, путем обмена сообщением SRR или SRA, или SAR или SAA. Затем HSS отправляет все пользовательские данные резервного копирования и данные конфигурации пользовательских услуг в подписке IMS затронутого IMPU на резервную S-CSCF посредством сообщения PPR.

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

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

На фиг.14 показана блок-схема последовательности операций способа аварийного восстановления согласно девятому варианту осуществления изобретения.

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

Согласно фиг.14 конкретный процесс аварийного восстановления включает в себя следующие этапы:

Этапы 1-6: UE регистрируется в процессе переключения с S-CSCF1 к новой S-CSCF (S-CSCF2).

Этап L1: Этот этап идентичен этапу L2 в первом варианте осуществления. Если HSS не обнаруживает, что начальная S-CSCF (S-CSCF1), где зарегистрировано UE, дает сбой, HSS отправляет сообщение RTR на начальную S-CSCF UE; если HSS не принимает сообщение RTA, HSS не изменяет состояние регистрации UE.

Этапы 7-9: UE посылает запрос регистрации; I-CSCF отправляет запрос регистрации на S-CSCF2 путем обмена сообщением UAR или UAA с HSS; и S-CSCF2 посылает сообщение SAR на HSS после аутентификации UE.

Этап 10: HSS возвращает сообщение SAA на S-CSCF2, несущее информацию зарегистрированных IMPI, которые непосредственно связаны с IMPU, переносимыми в сообщении SAR. Если ни один зарегистрированный IMPI не связан с IMPU за исключением IMPI, переносимых в сообщении SAR, HSS не нужно возвращать информацию зарегистрированных IMPI. В девятом варианте осуществления, информация зарегистрированных IMPI, которые связаны с IMPU, может возвращаться путем добавления AVP: Associated-Registered-Identities или добавления флагового бита в начальную AVP: Associated-Identities.

Если HSS не возвращает информацию зарегистрированных IMPI, которые связаны с IMPU, этап 13 и последующие не требуются.

Этап 13: Получив список зарегистрированных IMPI, S-CSCF2 проверяет зарегистрированные IMPI, которые связаны с IMPU локально. Если зарегистрированные IMPI, обеспеченные HSS, не зарегистрированы в S-CSCF2, S-CSCF2 может отправлять сообщение SRR или SAR, несущее информацию индикации аварийного восстановления, на HSS. Сообщение SRR или SAR несет IMPU запроса регистрации для запрашивания HSS восстановить пользовательские данные резервного копирования IMPU. Также можно запрашивать данные конфигурации услуг IMPU. Если данные конфигурации пользовательских услуг (профиль обслуживания) уже возвращены в сообщении SAA, параметру User-Data-Already-Available в запросе можно присвоить значение "USER_DATA_ALREADY_AVAILABLE", чтобы HSS не передавал повторно профиль обслуживания, но все же отправлял пользовательские данные резервного копирования.

Этап 14: После приема запроса для восстановления пользовательских данных IMPU, HSS возвращает пользовательские данные резервного копирования IMPU или пользовательские данные резервного копирования всех IMPI в наборе неявной регистрации IMPU и профиль обслуживания IMPU или профили обслуживания всех IMPU в наборе неявной регистрации IMPU. Если S-CSCF присваивает параметру User-Data-Already-Available значение "USER_DATA_ALREADY_AVAILABLE", HSS может не возвращать профиль обслуживания.

После приема ответа S-CSCF2 осуществляет операции восстановления согласно данным резервного копирования в ответе.

На фиг.15 показана блок-схема последовательности операций способа аварийного восстановления согласно десятому варианту осуществления изобретения.

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

Согласно фиг.15 конкретный процесс аварийного восстановления включает в себя следующие этапы:

Этапы 1-11: UE посылает запрос регистрации после успешного перезапуска S-CSCF; I-CSCF отправляет запрос регистрации на перезапущенную S-CSCF путем обмена сообщением UAR или UAA с HSS; и S-CSCF посылает сообщение SAR на HSS после аутентификации UE.

Этапы 12-16: Эти этапы идентичны этапам 10-14 в девятом варианте осуществления. Перезапущенная S-CSCF может полностью восстанавливать все данные регистрации и данные услуги IMPU и IMPU в наборе неявной регистрации IMPU в одной операции.

На фиг.16 показана блок-схема последовательности операций способа аварийного восстановления согласно одиннадцатому варианту осуществления изобретения.

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

Согласно фиг.16 конкретный процесс аварийного восстановления включает в себя следующие этапы:

Этапы 1-3: I-CSCF принимает запрос завершения услуги от UE или запрос инициирования услуги от AS вместо UE, после чего посылает сообщение запроса на HSS для получения текущей S-CSCF. Если текущая S-CSCF дает сбой, I-CSCF взаимодействует с HSS для выбора другой S-CSCF, и затем пересылает запрос услуги с флагом аварийного восстановления на новую S-CSCF; если текущая S-CSCF, указанная HSS, успешно перезапускается после сбоя, I-CSCF пересылает запрос услуги на успешно перезапущенную S-CSCF.

S-CSCF, которая принимает запрос услуги, определяет, что аварийное восстановление необходимо осуществлять, согласно флагу аварийного восстановления в принятом запросе услуги. Альтернативно запрос услуги может не нести флаг аварийного восстановления, и когда S-CSCF обнаруживает, что UE не зарегистрировано локально, S-CSCF посылает запрос SAR (UNREGISTERED_USER) на HSS. После приема запроса HSS обнаруживает, что UE находится в состоянии REGISTERED, после чего возвращает сообщение SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE). S-CSCF может осуществлять аварийное восстановление после приема сообщения SAA (DIAMETER_ERROR_IN_ASSIGNMENT_TYPE).

Этап 4: В сообщении SAA HSS возвращает профиль обслуживания IMPU или профили обслуживания всех IMPU в наборе неявной регистрации IMPU и пользовательские данные резервного копирования всех IMPI, связанных с IMPU, или пользовательские данные резервного копирования всех IMPI в наборе неявной регистрации IMPU. HSS может возвращать сообщение SAA, несущее профиль обслуживания IMPU или профили обслуживания всех IMPU в наборе неявной регистрации IMPU и пользовательские данные резервного копирования всех IMPI, связанных с IMPU, или пользовательские данные резервного копирования всех IMPI, связанных со всеми IMPU в наборе неявной регистрации IMPU, а также DIAMETER_ERROR_IN_ASSIGNMENT_TYPE, описанный на этапе 3, на S-CSCF.

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

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

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

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

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

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

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

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

Модуль 21 хранения пользовательских данных предназначен для хранения данных конфигурации пользовательских услуг, пользовательских данных резервного копирования для восстановления пользовательских услуг и информации CSCF, где зарегистрирован пользователь.

Модуль 22 обработки аварийного восстановления предназначен для осуществления аварийного восстановления. Конкретная структура модуля обработки аварийного восстановления показана на фиг.18. В частности, модуль обработки аварийного восстановления включает в себя модуль 221 принятия решения и модуль 222 передачи данных.

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

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

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

Кроме того, другая конкретная структура модуля 221 принятия решения, показанная на фиг.20, включает в себя:

модуль обнаружения 2211b, сконфигурированный для обнаружения, изменилась ли CSCF, где зарегистрирован пользователь, и принял ли сетевой объект хранения пользователя сообщение RTA, возвращенное CSCF, после отправки сообщения RTR на начальную CSCF, где зарегистрирован пользователь; и

модуль определения 2212b, сконфигурированный для определения, что аварийное восстановление необходимо осуществлять для CSCF, если результат обнаружения в модуле обнаружения 2211b показывает, что CSCF, где зарегистрирован пользователь, изменилась, и что сетевой объект хранения пользователя не принимает сообщение RTA, возвращенное CSCF.

Кроме того, еще одна конкретная структура модуля 221 принятия решения, показанная на фиг.21, включает в себя:

модуль обнаружения 2211c, сконфигурированный для обнаружения, изменилась ли CSCF, где зарегистрирован пользователь, и дала ли сбой начальная CSCF, где зарегистрирован пользователь; и

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

Модуль 222 передачи данных предназначен для передачи пользовательских данных резервного копирования зарегистрированных IMPI, которые связаны с пользователем, и данных конфигурации пользовательских услуг IMPU в подписке IMS на резервную CSCF путем однократного или многократного взаимодействия с резервной CSCF, если в модуле 221 принятия решения принято положительное решение.

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

В этом варианте осуществления IMS включает в себя CSCF 1, например S-CSCF, и сетевой объект хранения 2, например HSS. Сетевой объект хранения 1 включает в себя модуль 11 получения данных аварийного восстановления и модуль 12 обработки аварийного восстановления.

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

Модуль 12 обработки аварийного восстановления предназначен для восстановления соответствующей услуги согласно пользовательским данным резервного копирования зарегистрированных IMPI и данных конфигурации пользовательских услуг IMPU в подписке IMS, которые получены с помощью модуля 11 получения данных аварийного восстановления.

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

модуль анализа 111a, сконфигурированный для анализа информации зарегистрированных IMPI, которые связаны с IMPU пользователя, в подписке IMS, переданной от HSS пользователя;

модуль 112a принятия решения, сконфигурированный для определения IMPI, подлежащего восстановлению, согласно принятой информации зарегистрированных IMPI;

модуль запрашивания 113a, сконфигурированный для запрашивания пользовательских данных резервного копирования IMPI и данных конфигурации пользовательских услуг IMPU, связанного с IMPI, определенным модулем 112a принятия решения, от HSS пользователя; и

модуль приема 114a, сконфигурированный для приема пользовательских данных резервного копирования IMPI и данных конфигурации пользовательских услуг IMPU, связанного с IMPI, переносимых в ответе, возвращаемом HSS пользователя.

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

модуль анализа 111b, сконфигурированный для анализа информации зарегистрированных IMPU, которые связаны с IMPU пользователя, в подписке IMS, переданной от HSS пользователя;

модуль 112b принятия решения, сконфигурированный для определения IMPU, подлежащего восстановлению, согласно принятой информации зарегистрированных IMPU;

модуль запрашивания 113b, сконфигурированный для запрашивания пользовательских данных резервного копирования зарегистрированного IMPI, который непосредственно связан с IMPU, определенным модулем 112b принятия решения, и данных конфигурации пользовательских услуг IMPU, связанного с IMPI, от HSS пользователя; и

модуль приема 114b, сконфигурированный для приема пользовательских данных резервного копирования зарегистрированного IMPI, который непосредственно связан с IMPU, и данных конфигурации пользовательских услуг IMPU, переносимых в ответе, возвращаемом HSS пользователя.

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

модуль анализа 111c, сконфигурированный для анализа информации зарегистрированных IMPI, которые связаны с IMPU пользователя, в подписке IMS, переданной сетевым объектом хранения пользователя;

модуль 112c принятия решения, сконфигурированный для определения IMPU, подлежащего восстановлению, согласно принятой информации зарегистрированных IMPI;

модуль запрашивания 113c, сконфигурированный для запрашивания пользовательских данных резервного копирования зарегистрированного IMPI, который непосредственно связан с IMPU, подлежащим восстановлению, который определен модулем 112c принятия решения, и данных конфигурации пользовательских услуг IMPU из сетевого объекта хранения пользователя; и

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

Сетевой объект хранения 2 включает в себя:

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

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

Кроме того, сетевой объект хранения 2 дополнительно включает в себя:

модуль 23 инкапсуляции сообщения, сконфигурированный для инкапсуляции ответа, несущего информацию зарегистрированных IMPI или IMPU, где ответом может быть любое сообщение, например сообщение SAA, которое несет информацию зарегистрированных IMPI или IMPU в виде AVP: Associated-Registered-Identities сообщения SAA или путем добавления флагового бита в AVP: Associated-Identities сообщения SAA; и

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

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

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

модуль 14 обработки принятия решения, сконфигурированный для: принятия решения, создавать ли резервную копию данных подписки регистрации после того, как модуль 13 обработки запуска запускает резервное копирование данных аварийного восстановления и резервное копирование данных подписки регистрации, если принято решение, создать резервную копию данных подписки регистрации.

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

Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении возможности восстановления услуги «один публичный идентификатор пользователя (IMPU) - много приватных идентификаторов пользователя (IMPI)», «один IMPI - много IMPU» или «много IMPI - много IMPU», что дает пользователю лучшее ощущение непрерывности услуги. Способ аварийного восстановления, содержащий этапы, на которых получают, при запуске резервной функции управления сеансом вызова (CSCF), посредством резервной CSCF, пользовательские данные резервного копирования зарегистрированных IMPI Подсистемы IP-мультимедиа (IMS), которые связаны с IMPU IMS, и данные конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения, и осуществляют, посредством резервной CSCF, соответствующую услугу согласно полученным пользовательским данным резервного копирования зарегистрированных IMPI и данным конфигурации пользовательских услуг IMPU в подписке IMS. 5 н. и 18 з.п. ф-лы, 26 ил.

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

2. Способ по п.1, в котором на этапе получения посредством резервной CSCF пользовательских данных резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данных конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения пользователя:
получают посредством резервной CSCF путем взаимодействия с сетевым объектом хранения пользователя, по меньшей мере, один раз пользовательские данные резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данные конфигурации пользовательских услуг IMPU в подписке IMS, переданные сетевым объектом хранения пользователя, после того, как сетевой объект хранения определяет, что аварийное восстановление необходимо осуществлять для CSCF.

3. Способ по п.2, в котором при определении, что аварийное восстановление необходимо осуществлять для CSCF:
определяют, что аварийное восстановление необходимо осуществлять для CSCF согласно индикации восстановления, переносимой в сообщении Запроса назначения сервера (SAR), после приема сообщения SAR, несущего индикацию восстановления, от резервной CSCF, или
определяют, что аварийное восстановление необходимо осуществлять для CSCF, когда CSCF, где зарегистрирован пользователь, изменяется, и когда сетевой объект хранения пользователя создает сообщение Запроса завершения регистрации (RTR) для начальной CSCF, где зарегистрирован пользователь, но не принимает сообщение Ответа завершения регистрации (RTA) от начальной CSCF, или
определяют, что аварийное восстановление необходимо осуществлять для CSCF, когда CSCF, где зарегистрирован пользователь, изменяется, и когда сетевой объект хранения пользователя определяет, что начальная CSCF, где зарегистрирован пользователь, дала сбой, без отправки сообщения RTR на начальную CSCF.

4. Способ по п.2, в котором на этапе получения посредством резервной CSCF путем однократного взаимодействия с сетевым объектом хранения пользователя, пользовательских данных резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данных конфигурации пользовательских услуг IMPU в подписке IMS, переданных сетевым объектом хранения пользователя:
получают посредством резервной CSCF пользовательские данные резервного копирования зарегистрированных IMPI и данные конфигурации пользовательских услуг IMPU в подписке IMS путем приема расширенного сообщения Запроса профиля активной доставки (PPR), которое поддерживает множественные AVP Пользователь-Данные, или получают посредством резервной CSCF пользовательские данные резервного копирования зарегистрированных IMPI и данные конфигурации пользовательских услуг IMPU в подписке IMS путем приема расширенного сообщения Ответа восстановления услуги (SRA) или Ответа назначения сервера (SAA), которое поддерживает множественные AVP Пользователь-Данные.

5. Способ по п.1, в котором на этапе получения посредством резервной CSCF пользовательских данных резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данных конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения пользователя:
получают посредством резервной CSCF информацию зарегистрированных IMPI, которые связаны с IMPU, в подписке IMS, переданную сетевым объектом хранения пользователя
определяют посредством резервной CSCF IMPI, подлежащий восстановлению, согласно принятой информации зарегистрированных IMPI, и запрашивают сетевой объект хранения пользователя, чтобы восстановить пользовательские данные резервного копирования IMPI, и
принимают посредством резервной CSCF пользовательские данные резервного копирования IMPI и данные конфигурации пользовательских услуг IMPU, связанного с IMPI, переносимые в ответе, возвращаемом сетевым объектом хранения пользователя.

6. Способ по п.1, в котором на этапе получения посредством резервной CSCF пользовательских данных резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данных конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения пользователя:
получают посредством резервной CSCF информацию зарегистрированных IMPI, которые связаны с IMPU, в подписке IMS, переданную сетевым объектом хранения пользователя,
определяют посредством резервной CSCF IMPU, подлежащий восстановлению, согласно принятой информации зарегистрированных IMPI, и запрашивают сетевой объект хранения пользователя, чтобы восстановить данные конфигурации пользовательских услуг IMPU и пользовательские данные резервного копирования зарегистрированного IMPI, непосредственно связанного с IMPU, и
принимают посредством резервной CSCF данные конфигурации пользовательских услуг IMPU и пользовательские данные резервного копирования зарегистрированного IMPI, непосредственно связанного с IMPU, переносимые в ответе, возвращаемом сетевым объектом хранения пользователя.

7. Способ по п.5 или 6, в котором на этапе получения посредством резервной CSCF информации зарегистрированных IMPI, которые связаны с IMPU, в подписке IMS, переданной сетевым объектом хранения пользователя:
получают посредством резервной CSCF информацию зарегистрированных IMPI, которые непосредственно связаны с IMPU, передаваемую сетевым объектом хранения пользователя, или
получают посредством резервной CSCF информацию зарегистрированных IMPI, переносимую в существующих ассоциированных приватных идентификаторах сообщения Ответа назначения сервера (SAA), передаваемого сетевым объектом хранения пользователя, или
получают посредством резервной CSCF информацию зарегистрированных IMPI, переносимую в новом параметре расширенного сообщения SAA, передаваемого сетевым объектом хранения пользователя, или
получают посредством резервной CSCF информацию зарегистрированных IMPI, переносимую в новом параметре расширенного сообщения PPR, передаваемого сетевым объектом хранения пользователя.

8. Способ по п.1, в котором на этапе получения посредством резервной CSCF пользовательских данных резервного копирования зарегистрированных IMPI, которые связаны с IMPU, и данных конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения пользователя:
получают посредством резервной CSCF информацию зарегистрированных IMPU, которые связаны с IMPU, в подписке IMS, переданную сетевым объектом хранения пользователя, определяют посредством резервной CSCF IMPU, подлежащий восстановлению, согласно принятой информации зарегистрированных IMPU, и запрашивают сетевой объект хранения пользователя, чтобы восстановить пользовательские данные резервного копирования IMPI, непосредственно связанного с IMPU, и
принимают посредством резервной CSCF пользовательские данные резервного копирования IMPI, непосредственно связанного с IMPU, и данные конфигурации пользовательских услуг IMPU, переносимые в ответе, возвращаемом сетевым объектом хранения пользователя.

9. Способ по п.8, в котором на этапе получения посредством резервной CSCF информации зарегистрированных IMPU, которые связаны с IMPU, в подписке IMS, переданной сетевым объектом хранения пользователя:
получают посредством резервной CSCF информацию зарегистрированных IMPU, переносимую в новом параметре расширенного сообщения SAA, передаваемого сетевым объектом хранения пользователя, или
получают посредством резервной CSCF информацию зарегистрированных IMPU, переносимую в новом параметре расширенного сообщения SRA, передаваемого сетевым объектом хранения.

10. Способ по п.1, в котором резервная CSCF запускается в процессе регистрации услуги, или инициирования услуги, или завершения услуги посредством пользовательского оборудования (UE), или инициирования услуги посредством сервера приложений (AS) вместо UE.

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

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

13. Способ по п.1, в котором
пользовательские данные резервного копирования содержат:
адрес CSCF-посредника (P-CSCF), адрес контакта UE и данные подписки состояния регистрации UE в ходе регистрации UE; и
на этапе осуществления посредством резервной CSCF, соответствующей услуги согласно полученным пользовательским данным резервного копирования зарегистрированных IMPI и данным конфигурации пользовательских услуг IMPU в подписке IMS:
отправляют посредством резервной CSCF сообщение NOTIFY (Извещения) на все или некоторые связанные зарегистрированные UE согласно адресу контакта и данным подписки состояния регистрации UE в пользовательских данных резервного копирования, для извещения UE, для регистрации в сети.

14. Способ по п.1, в котором на этапе осуществления посредством резервной CSCF, соответствующей услуги согласно полученным пользовательским данным резервного копирования зарегистрированных IMPI и данным конфигурации пользовательских услуг IMPU в подписке IMS:
при приеме связанного запроса услуги пользователя определяют посредством резервной CSCF тип услуги согласно полученным данным конфигурации пользовательских услуг и осуществляют связанную услугу пользователя согласно пользовательским данным резервного копирования.

15. Сетевой объект с функцией управления сеансом вызова (CSCF), содержащий:
модуль получения данных аварийного восстановления, сконфигурированный для получения пользовательских данных резервного копирования зарегистрированных приватных идентификаторов пользователя (IMPI) Подсистемы IP-мультимедиа (IMS), которые связаны с публичными идентификаторами пользователя (IMPU) IMS, и данных конфигурации пользовательских услуг IMPU в подписке IMS из сетевого объекта хранения; и
модуль обработки аварийного восстановления, сконфигурированный для осуществления соответствующей услуги согласно пользовательским данным резервного копирования зарегистрированных IMPI и данным конфигурации пользовательских услуг IMPU в подписке IMS, которые получены с помощью модуля получения данных аварийного восстановления.

16. Сетевой объект по п.15, в котором модуль получения данных аварийного восстановления содержит:
модуль анализа, сконфигурированный для анализа информации зарегистрированных IMPI, которые связаны с IMPU, в подписке IMS, переданной сетевым объектом хранения пользователя;
модуль принятия решения, сконфигурированный для определения IMPI, подлежащего восстановлению, согласно принятой информации зарегистрированных IMPI;
модуль запрашивания, сконфигурированный для запрашивания сетевого объекта хранения пользователя, чтобы восстановить пользовательские данные резервного копирования IMPI, подлежащего восстановлению, который определен модулем принятия решения, и данные конфигурации пользовательских услуг IMPU, связанного с IMPI; и
модуль приема, сконфигурированный для приема пользовательских данных резервного копирования IMPI и данных конфигурации пользовательских услуг IMPU, связанного с IMPI, переносимых в ответе, возвращаемом сетевым объектом хранения пользователя.

17. Сетевой объект по п.15, в котором модуль получения данных аварийного восстановления содержит:
модуль анализа, сконфигурированный для анализа информации зарегистрированных IMPI, которые связаны с IMPU, в подписке IMS, переданной сетевым объектом хранения пользователя;
модуль принятия решения, сконфигурированный для определения IMPU, подлежащего восстановлению, согласно принятой информации зарегистрированных IMPI;
модуль запрашивания, сконфигурированный для запрашивания сетевого объекта хранения пользователя, чтобы восстановить пользовательские данные резервного копирования зарегистрированного IMPI, непосредственно связанного с IMPU, подлежащим восстановлению, который определен модулем принятия решения, и данные конфигурации пользовательских услуг IMPU; и
модуль приема, сконфигурированный для приема пользовательских данных резервного копирования зарегистрированного IMPI, непосредственно связанного с IMPU, и данных конфигурации пользовательских услуг IMPU, переносимых в ответе, возвращаемом сетевым объектом хранения пользователя.

18. Сетевой объект по п.15, в котором модуль получения данных аварийного восстановления содержит:
модуль анализа, сконфигурированный для анализа информации зарегистрированных IMPU, которые связаны с IMPU, в подписке IMS, переданной сетевым объектом хранения пользователя;
модуль принятия решения, сконфигурированный для определения IMPU, подлежащего восстановлению, согласно принятой информации зарегистрированных IMPU;
модуль запрашивания, сконфигурированный для запрашивания сетевого объекта хранения пользователя, чтобы восстановить пользовательские данные резервного копирования зарегистрированного IMPI, непосредственно связанного с IMPU, подлежащим восстановлению, который определен модулем принятия решения, и данные конфигурации пользовательских услуг IMPU; и
модуль приема, сконфигурированный для приема пользовательских данных резервного копирования зарегистрированного IMPI, непосредственно связанного с IMPU, и данных конфигурации пользовательских услуг IMPU, переносимых в ответе, возвращаемом сетевым объектом хранения пользователя.

19. Сетевой объект хранения, содержащий:
модуль хранения пользовательских данных, сконфигурированный для хранения данных конфигурации пользовательских услуг, пользовательских данных резервного копирования для восстановления пользовательских услуг и информации функции управления сеансом вызова (CSCF), где зарегистрирован пользователь;
модуль передачи данных аварийного восстановления, сконфигурированный для передачи пользовательских данных резервного копирования в CSCF;
модуль инкапсуляции сообщения, сконфигурированный для инкапсуляции ответа, который несет информацию одного из зарегистрированных Приватных идентификаторов пользователя (IMPI) Подсистемы IP-мультимедиа (IMS) и публичных идентификаторов пользователя (IMPU) IMS, и
модуль отправки сообщения, сконфигурированный для отправки ответа, который несет информацию одного из зарегистрированных IMPI или IMPU, в CSCF.

20. Сетевой объект хранения по п.19, причем ответ содержит одно из сообщения Ответа назначения сервера (SAA) и сообщения Ответа восстановления услуги (SRA).

21. Сетевой объект хранения, содержащий:
модуль хранения пользовательских данных, сконфигурированный для хранения данных конфигурации пользовательских услуг, пользовательских данных резервного копирования для восстановления пользовательских услуг и информации функции управления сеансом вызова (CSCF), где зарегистрирован пользователь; и
модуль обработки аварийного восстановления, который содержит: модуль принятия решения, сконфигурированный для принятия решения, осуществлять ли аварийное восстановление для CSCF; и модуль передачи данных, сконфигурированный для передачи пользовательских данных резервного копирования зарегистрированных приватных идентификаторов пользователя (IMPI) Подсистемы IP-мультимедиа (IMS), которые связаны с пользователем, и данных конфигурации пользовательских услуг публичных идентификаторов пользователя (IMPU) IMS в подписке IMS в резервную CSCF путем взаимодействия с резервной CSCF, по меньшей мере, один раз, если в модуле принятия решения принято решение осуществлять аварийное восстановление для CSCF.

22. Сетевой объект хранения по п.21, в котором модуль принятия решения содержит:
модуль анализа, сконфигурированный для анализа одного из сообщения Запроса назначения сервера (SAR) и сообщения Запроса восстановления услуги (SRR), несущего индикацию восстановления, которое отправлено CSCF так, чтобы определять, несет ли одно из сообщения SAR и сообщения SRR информацию индикации восстановления; и
модуль определения согласно результату анализа в модуле анализа, сконфигурированный для определения, что аварийное восстановление необходимо осуществлять для CSCF, если сообщение SAR несет информацию индикации восстановления;
или модуль принятия решения содержит:
модуль обнаружения, сконфигурированный для обнаружения, изменилась ли CSCF, где зарегистрирован пользователь, и принял ли сетевой объект хранения пользователя сообщение Ответа завершения регистрации (RTA), возвращенное CSCF после отправки сообщения Запроса завершения регистрации (RTR) в начальную CSCF, где зарегистрирован пользователь; и модуль определения, сконфигурированный для определения, что аварийное восстановление необходимо осуществлять для CSCF, если результат обнаружения в модуле обнаружения показывает, что CSCF, где зарегистрирован пользователь, изменилась, и сетевой объект хранения пользователя не принимает сообщение RTA, возвращенное CSCF;
или модуль принятия решения содержит:
модуль обнаружения, сконфигурированный для обнаружения, изменилась ли CSCF, где зарегистрирован пользователь, и дала ли сбой начальная CSCF, где зарегистрирован пользователь; и
модуль определения, сконфигурированный для определения, что аварийное восстановление необходимо осуществлять для CSCF, если результат обнаружения в модуле обнаружения показывает, что CSCF, где зарегистрирован пользователь, изменилась, и начальная CSCF, где зарегистрирован пользователь, дала сбой.

23. Подсистема IP-мультимедиа (IMS), содержащая сетевой объект по любому из пп.15-18 и сетевой объект хранения по любому из пп.19-20.