Способ, устройство и система аварийного восстановления ims

Способ, устройство и система аварийного восстановления ims

Иллюстрации

Показать все

Реферат

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

Настоящее изобретение относится к сетевым технологиям, связанным с Подсистемой 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 определяет, чт