Результат интеллектуальной деятельности: СПОСОБ И СИСТЕМА ДЛЯ ХРАНЕНИЯ ДАННЫХ В МУЛЬТИМЕДИЙНОЙ ПОДСИСТЕМЕ

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

IMS - оверлейная архитектура услуг, способная обеспечивать услуги в сети 3G на основе Интернет-протокола (IP), позволяя, таким образом, мобильным пользователям получать доступ к самым разнообразным услугам, доступным в сети IP. IMS также может предоставлять услуги, обычно связанные с коммутируемыми сетями, например переадресацию вызовов.

Архитектура IMS и функциональность определяются рядом стандартов, обеспеченных Проектом партнерства третьего поколения (3GPP).

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

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

Данные, хранящиеся в HSS, могут быть «прозрачными» данными, означая, что HSS понимает синтаксис, но не семантику данных, или непрозрачными данными, означая, что HSS понимает и синтаксис, и семантику данных.

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

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

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

(1) они должны быть частью одного и того же профиля услуг (то есть все пользователи подписываются на одни и те же услуги);

(2) они должны быть частью одного и того же набора неявной регистрации; и

(3) они должны иметь одну и ту же конфигурацию услуги для каждой услуги.

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

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

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

В соответствии с первым аспектом настоящего изобретения предложен способ хранения данных в мультимедийной подсистеме IP (IMS), при этом способ содержит этапы:

(i) выбора первого пользователя и второго пользователя, которые не являются алиасами;

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

(iii) создания структуры данных, содержащей единственный экземпляр идентифицированных общих элементов данных; и

(iv) сохранение структуры данных в домашнем абонентском сервере (HSS) в IMS.

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

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

(ii) анализируют первый и второй наборы данных, связанные с первым и вторым пользовательскими идентификаторами, соответственно, для выявления общих элементов конфигурации для каждой абонируемой услуги, общей для первого и второго пользовательских идентификаторов, при этом первый и второй наборы данных используются первым сервером приложений в составе IMS для удовлетворения запросов на услугу от имени первого и второго пользовательских идентификаторов;

(iii) создают структуру данных, содержащую единственный экземпляр выявленных общих элементов конфигурации; и

(iv) сохраняют эту структуру данных в HSS в составе IMS

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

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

Общие элементы данных обычно сохраняются в контейнере в базе данных, поддерживаемой HSS. Подходящим контейнером является BLOB (большой двоичный объект).

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

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

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

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

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

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

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

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

Ниже описывается пример воплощения изобретения со ссылками на сопровождающие чертежи, на которых:

Фигура 1 - часть мультимедийной подсистемы IP (IMS), на которой может быть выполнено изобретение;

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

Фигура 3 - этапы, выполняемые в сервере приложений и HSS при осуществлении изобретения.

На фигуре 1 показан сервер 1 приложений, связанный с HSS 2 и S-CSCF 3. Сервер 1 приложений соединяется с HSS 2, используя интерфейс Sh, и с S-CSCF 3 через интерфейс ISC. HSS 2 и S-CSCF 3 соединяются, используя интерфейс Cx. Интерфейсы Sh и Cx определяются как часть протокола DIAMETER, который является сетевым протоколом для использования при аутентификации, авторизации и учете. Интерфейс ISC определяется как часть протокола инициирования сеансов (SIP).

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

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

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

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

Интерфейс Sh в сервере 1 приложений может работать в двух режимах: обработка данных и подписок/уведомлений.

В режиме обработки данных используется Sh Pull для извлечения данных из HSS 2 и обновления Sh для хранения данных в HSS 2. Данные извлекаются из HSS 2, создавая запрос Sh Pull, и данные хранятся в HSS 2, посылая запрос на обновление Sh.

Режим подписок/уведомлений позволяет серверу 1 приложений получать уведомление, когда определенные данные для конкретного пользователя обновляются в HSS 2 другими сетевыми объектами.

Приведенный ниже список суммирует типы данных, которые могут быть запрошены, используя приложение Sh:

- архивные данные: содержат прозрачные данные, относящиеся к услугам.

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

- Состояние подсистемы IMS пользователя: содержит информацию о состоянии IMS пользователя и общедоступных идентификаторов; возможные значения: РЕГИСТРИРУЕТСЯ, НЕ РЕГИСТРИРУЕТСЯ, АУТЕНТИФИКАЦИЯ_ОТЛОЖЕНО, ЗАРЕГИСТРИРОВАНО_УСЛУГИ.

- Имя S-CSCF: содержит адрес S-CSCF, выделенный пользователю.

- Начальные критерии Фильтра: содержит информацию об инициировании услуги; AS может только получить начальные критерии фильтра, относящиеся к предоставленной услуге.

- Информация о расположении: содержит информацию о расположении, относящуюся к пользователю, который может быть расположен в домене коммутацией каналов (CS) или к коммутации пакетов (PS).

- Состояние пользователя: содержит данные о состоянии пользователя в домене CS/PS.

- Загрузка информации: содержит адрес функции загрузки.

- MSISDN: содержит MSISDN (которое является числом, однозначно определяющим подписку в GSM или мобильной сети UMTS), связанное с общедоступным идентификатором пользователя.

На фигуре 2 представлен ряд общедоступных идентификаторов IMS (IMPU) с IMPU 1 по IMPU 4, каждый из которых может пожелать осуществить доступ к HSS 2, чтобы получить архивные данные, относящиеся к ним. В ситуации, показанной на фигуре 2, IMPU 1, IMPU 2 и IMPU 3 являются алиасами. IMPU 1 и IMPU 2 могут получить доступ к сгруппированным архивным данным S2 на HSS2, и IMPU 2 и IMPU 3 могут получить доступ к сгруппированным архивным данным S3 на HSS 2. Как упомянуто выше, IMPU 1-4 используют индикацию услуги в качестве ключа для доступа к группе архивных данных BLOB (большого двоичного объекта).

IMPU 3 и IMPU 4 не являются алиасами. Однако сервер 1 приложений может создать групповые архивные данные для этих двух объектов, используя операцию обновления профиля, которая затем будет совместно использована IMPU 3 и IMPU 4.

Способ, которым это делается, будет теперь описан со ссылкой на фигуру 3, которая иллюстрирует взаимодействие между сервером 1 приложений и HSS 2 при создании и хранении сгруппированных архивных данных для двух неалиасных идентификаторов: IMPU 3 (называемый пользователем А на фигуре 4) и IMPU 4 (называемый пользователем В на фигуре 4).

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

Например, пользователь A может подписаться на услуги фильтрации и переадресации входящих вызовов, и пользователь В может подписаться на услуги фильтрации вызовов, переадресации вызовов и запрета связи.

Из-за различия в абонируемых (подписанных) услугах (т.е. различные профили услуг пользователей A и B) пользователь A и пользователь В не являются алиасными. Однако архивные данные, относящиеся к услуге переадресации для пользователей A и B, могут, тем не менее, группироваться и храниться как единственный экземпляр данных.

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

Таким образом, сервер 1 приложений может анализировать архивные данные для каждого из пользователей A и B для выявления общих элементов данных, т.е. указания того, что пользователь авторизован использовать услугу, что услуга активируется для этого пользователя, и другие опций подписки как для пользователя A, так и для пользователя B, и для сохранения данных в HSS 2 создается контейнер (такой как BLOB).

Затем сервер 1 приложений отправляет контейнер с группами архивных данных для пользователей A и B в HSS 2 и выдает команду PUR для предписания HSS 2 сохранить сгруппированные архивные данных в своей базе данных. Таким образом, сгруппированные архивные данные, сохраненные в HSS 2, являются прозрачными данными, сгруппированными по двум неалиасным пользователям A и B. На фигуре 3 эти действия показаны как этапы 1 и 2.

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

На этапе 3 сервер 1 приложений выдает команду UDR для HSS 2 на извлечение сгруппированных архивных данных для пользователей A и B, причем HSS 2, возможно, должен будет ответить на запросы на услугу от любого пользователя. Команда UDR будет сопровождаться индикацией услуги (т.е. переадресация вызова) и идентификацией пользователя (т.е. IMPU 3 или 4), которые HSS 2 будет использовать в качестве ключа, чтобы получить сгруппированные архивные данные, которые затем могут быть возвращены серверу 1 приложений.

На этапе 4 сервер 1 приложений подписывается на уведомления относительно изменений в сгруппированных архивных данных для пользователей A и B. Сервер делает это, выдавая команду SNR в HSS 2. Команда SNR будет сопровождаться индикацией услуги (т.е. переадресация вызова) и идентификацией пользователя (т.е. IMPU 3 или 4), которые HSS 2 будет использовать для уведомления сервера 1 приложений (который также будет уведомлен в случае изменения этих данных).

На этапе 5 HSS 2 обнаруживает изменение в данных (которое может быть сделано, например, другим сетевым объектом, который обрабатывает услугу переадресации вызова). HSS 2 реагирует на это, выдавая уведомление (известное как уведомление PNR) серверу 1 приложений. Сервер 1 приложений затем может использовать команду UDR, как описано выше, чтобы в случае необходимости извлечь и просмотреть измененные данные или выполнить любую необходимую обработку в ответ на указанное изменение.

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