RU2385546C2 - Способ и устройство поддержания информации на клиенте ims - Google Patents

Abstract

Изобретение относится к способу и устройству поддержания информации на клиенте подсистемы IP-Мультимедиа и, в частности, для поддержания соответствующей последнему обновлению информации на клиенте IMS. Техническим результатом является обеспечение надежной синхронизации данных, хранящихся на клиенте мультимедийной системы на базе межсетевого протокола (IP), с данными, хранящимися на сервере приложений протокола инициирования сеансов (SIP) этой мультимедийной подсистемы на базе IP. Указанный технический результат достигается тем, что принимают запрос на данные, переданный с клиента, на сервере приложений; определяют, содержит ли этот запрос условие, идентифицирующее текущее состояние данных, хранящихся на клиенте; на основании любого идентифицированного условия определяют на сервере приложений, передавать ли дополнительные данные на клиента, и передают данные в зависимости от результата определения. 3 н. и 3 з.п. ф-лы, 2 ил.

Description

Область техники, к которой относится изобретение

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

Предшествующий уровень техники

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

Мультимедийная подсистема на базе IP (IMS) - это технология, отвечающая стандарту Third Generation Partnership Project (3GPP) (Проект Партнерства в области связи третьего поколения) для обеспечения мультимедийных услуг на базе IP в сетях мобильной связи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329, выпуски 5-7). IMS обеспечивает ключевые функциональные возможности для обогащения опыта межличностного общения конечного пользователя с использованием стандартных средств, позволяющих обеспечивать предоставление услуг IMS, которые обеспечивают новые богатые услуги связи между двумя людьми (между двумя клиентами), а также услуги связи человека с контентом (клиента с сервером) в сетях на базе IP. IMS использует протокол инициирования сеансов (SIP) для установления и контроля вызовов или сеансов между пользовательскими терминалами (или между пользовательскими терминалами и серверами приложений). Протокол описания сеансов (SDP), переносимый сигнализацией SIP, используется для описания и согласования медиа-компонентов сеанса. Хотя SIP был создан как протокол межпользовательской связи, IMS позволяет операторам и поставщикам услуг управлять пользовательским доступом к услугам и выставлять пользователям соответствующие счета.

В порядке примера, на фиг.1 схематически показано, как IMS встроена в архитектуру сети мобильной связи в случае сети доступа GPRS/PS (IMS, конечно, может работать в других сетях доступа). Функциональные модули управления вызовами/сеансами (CSCF) выступают в качестве посредников SIP в IMS. Архитектура 3GPP задает три типа CSCF: посреднический CSCF (P-CSCF), который является первой точкой контакта в IMS для терминала SIP; обслуживающий CSCF (S-CSCF), который предоставляет пользователю услуги, на которые пользователь подписан; и опрашивающий CSCF (I-CSCF), предназначенный для идентификации правильного S-CSCF и для пересылки на этот S-CSCF запроса, полученного от терминала SIP через P-CSCF.

Пользователь регистрируется в IMS с использованием заданного метода REGISTER («РЕГИСТРАЦИЯ»), соответствующего SIP. Это механизм для подключения к IMS и объявления для IMS адреса, по которому можно найти идентификационные данные пользователя SIP. В 3GPP, когда терминал SIP осуществляет регистрацию, IMS аутентифицирует пользователя и выделяет S-CSCF этому пользователю из набора имеющихся S-CSCF. Хотя критерии выделения S-CSCF не заданы в 3GPP, они могут включать в себя требования к разделению нагрузки и к услугам. Заметим, что выделение S-CSCF играет важную роль для контроля (и тарификации) пользовательского доступа к услугам на базе IMS. Операторы могут обеспечивать механизм, предотвращающий прямые сеансы связи между пользователями SIP, которые, в противном случае, могли бы обходить S-CSCF.

В процессе регистрации I-CSCF отвечает за выбор S-CSCF, если S-CSCF еще не выбран. I-CSCF принимает запрашиваемые возможности S-CSCF от сервера собственных абонентов (HSS) домашней сети и выбирает соответствующий S-CSCF на основании принятых возможностей [заметим, что I-CSCF также осуществляет выделение S-CSCF для пользователя в случае, когда пользователя вызывает третья сторона, и в данный момент пользователю не выделена S-CSCF]. Затем, когда зарегистрированный пользователь направляет запрос сеанса на IMS, P-CSCF способен переслать запрос на выбранный S-CSCF на основании информации, принятой от S-CSCF в процессе регистрации.

В ряде случаев терминал-клиент IMS может пожелать поддерживать данные, которые, по существу, синхронизированы с данными, поддерживаемыми на сервере приложений SIP. Рассмотрим для примера услугу присутствия, где абоненты IMS публикуют свою информацию присутствия, например, текущий контактный адрес, местожительство и т.д., в базе данных, поддерживаемой на сервере приложений SIP. Эта информация доступна другим пользователям, имеющим соответствующие права доступа. Обмен информацией между пользователями и сервером приложений SIP можно обеспечивать с использованием соответствующих SIP методов PUBLISH («ПУБЛИКАЦИЯ») и SUBSCRIBE/NOTIFY («ПОДПИСКА/ИЗВЕЩЕНИЕ»).

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

Как указано в данном описании изобретения, относящийся к SIP метод SUBSCRIBE/NOTIFY позволяет клиенту IMS только запрашивать, чтобы он получал извещения об определенной информации, идентифицированной в методе SUBSCRIBE. Таким образом, идентифицированная информация поступает на клиент в сообщении NOTIFY независимо от того, изменилась ли информация после того, как клиент в последний раз запрашивал эту информацию. Уровень техники не предусматривает никакого механизма, позволяющего направлять на клиент только измененную или новую информацию.

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

принимают запрос на данные, переданный с клиента, на сервере приложений;

определяют, содержит ли запрос условие, идентифицирующее текущее состояние данных, хранящихся на клиенте;

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

передают данные в зависимости от результата определения.

Согласно варианту осуществления изобретения запрос представляет собой относящееся к SIP сообщение SUBSCRIBE. Упомянутое условие может содержаться в заголовке сообщения SIP или в полезной нагрузке сообщения.

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

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

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

Согласно второму аспекту настоящего изобретения предусмотрен терминал-клиент мультимедийной системы на базе IP, содержащий:

память для хранения данных совместно с условием, идентифицирующим текущее состояние этих данных; и

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

Согласно третьему аспекту настоящего изобретения предусмотрен сервер приложений SIP, содержащий:

память для хранения данных совместно с условием, идентифицирующим текущее состояние этих данных;

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

средство для сравнения принятого условия с условием, сохраненным для данных в памяти; и

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

Перечень чертежей

Фиг.1 - схема архитектуры IMS в 3G-сети.

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

Подробное описание некоторых вариантов осуществления

Общая архитектура мультимедийной подсистемы на базе IP (IMS) уже была описана (фиг.1) применительно к 3G-сети. В сети на базе IMS клиент может запрашивать данные о ресурсе в этой сети, которым оперируют разные серверы приложений. Клиент может либо извлекать данные на нерегулярной основе, либо может опрашивать сеть на регулярной основе, либо может подписаться на изменения, которые должны присылаться на клиент более или менее в реальном времени. Для некоторых клиентов предпочтительно использовать более старое решение «проталкивания», согласно которому сеть извещает клиент, когда происходит изменение в запрашиваемых данных. Другие клиенты предпочитают производить извлечение или опрос в отношении данных только тогда, когда это необходимо. Сеть IMS поддерживает эти функциональные возможности с помощью предусмотренной инфраструктуры подписки/извещения (RFC 3265).

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

Это поведение также возможно для обновления сообщений подписки (современные стандарты дают право серверу приложений всегда направлять полное извещение на клиент, даже если данные клиента соответствуют последнему обновлению). Клиенту, использующему метод «проталкивания», т.е. клиенту, который создает долговременную подписку с сервером приложений, требуется периодически обновлять свою подписку, чтобы поддерживать подписку активной на сервере приложений. В настоящее время, когда клиент обновляет свою подписку (посылая сообщение SUBSCRIBE с Expires (истекает через)>0), сервер приложений возвращает сохраненные данные в сообщении NOTIFY. Применение описанного здесь условного механизма позволяет производить такое обновление без необходимости загружать данные, которые соответствуют последнему обновлению. Решение пригодно для любой подписки на базе SIP.

На фиг.2 показана относящаяся к IMS сигнализация SIP, связанная с обменом информацией между двумя клиентами IMS, пользователем A и пользователем B, где данные, предоставленные пользователем A, поддерживаются на сервере приложений SIP для загрузки пользователем B. Пользователь A использует относящийся к SIP метод PUBLISH для отправки своих данных на сервер приложений SIP (через P-CSCF и S-CSCF) на этапах 1-3. В этом примере предполагается, что на этом этапе пользователь B не получил никакой версии данных пользователя А. На этапе 4 пользователь B запрашивает данные пользователя А, отправляя сообщение SUBSCRIBE на сервер приложений SIP [значение «Expires» заголовка SIP определяет метод, используемый клиентом IMS для получения данных. «Expires=0» используется для извлечения (вытягивания) данных, а «Expires>0» используется для установления подписки, которая используется для получения изменений в данных, проталкиваемых на клиент]. Пользователь B не включает в сообщение SUBSCRIBE никакое условие, относящееся к данным пользователя А. По приему сообщения SUBSCRIBE сервер приложений определяет из отсутствия условия, что он должен передать все данные пользователя А пользователю B. Для этого он включает данные в качестве полезной нагрузки, относящиеся к SIP, в сообщение NOTIFY, этап 5.

На этапе 6 пользователь B определяет по какой-либо причине, что ему нужно связаться с сервером приложений, чтобы определить, изменились ли данные пользователя А. Для этого он направляет дополнительное сообщение SUBSCRIBE. Однако на этот раз он включает в это сообщение условие, идентифицирующее текущее состояние данных пользователя А, которыми располагает пользователь B. Это условие задается таким образом, что его могут распознать все стороны, но может быть включено, например, в заголовок сообщения SIP или в полезную нагрузку. На основании этого условия сервер приложений может определить, следует ли передавать пользователю B данные, поддерживаемые на сервере. В этом примере, если данные не изменились, сервер приложений возвращает пользователю B сообщение «4xx» (т.е. 400-й серии) или пустое сообщение NOTIFY.

Затем пользователь A передает на сервер приложений дополнительное сообщение PUBLISH, содержащее обновленные данные, этапы 8-10. Когда пользователь B передает дополнительное сообщение SUBSCRIBE на сервер приложений на этапе 11, оно содержит условие («x»), идентифицирующее текущую версию данных, поддерживаемых для пользователя A. По приему сообщения SUBSCRIBE на сервере приложений SIP, сервер определяет из условия x, что данные, которые есть у пользователя B, устарели. Сервер возвращает пользователю B, в относящемся к SIP сообщении NOTIFY, новые данные для пользователя A.

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

Claims (6)

1. Способ синхронизации данных, хранящихся на клиенте мультимедийной системы на базе IP (межсетевого протокола), с данными, хранящимися на сервере приложений SIP (протокола инициирования сеансов) этой мультимедийной подсистемы на базе IP, при этом способ содержит этапы, на которых
принимают на сервере приложений относящийся к SIP запрос SUBSCRIBE («ПОДПИСКА») в отношении данных, хранящихся на сервере приложений, отправленный с клиента,
определяют, содержит ли этот запрос в своем заголовке условие, идентифицирующее текущее состояние данных, хранящихся на клиенте,
если запрос не содержит условие, отправляют все данные с сервера приложений SIP на клиент в относящемся к SIP сообщении NOTIFY («ИЗВЕЩЕНИЕ»), и
если запрос содержит условие, определяют на сервере приложений из этого условия, отличаются ли данные, хранящиеся на клиенте, от данных, хранящихся на сервере приложений SIP, и, если это так, направляют запрашиваемые данные на клиент в относящемся к SIP сообщении NOTIFY.

2. Способ по п.1, в котором, если определено, что данные, хранящиеся в данный момент на клиенте, соответствуют последнему обновлению, сервер приложений SIP информирует клиент об этом, направляя на клиент пустое относящееся к SIP сообщение NOTIFY или сообщение 400-й серии.

3. Способ по п.1 или 2, в котором условие, идентифицирующее текущее состояние данных, хранящихся на клиенте, представляет собой метку времени или номер версии.

4. Способ по п.1 или 2, в котором упомянутое условие генерируется сервером приложений SIP до того или одновременно с тем, как сервер приложений SIP направляет на клиент данные, сохраненные в данный момент, либо генерируется каким-либо другим источником данных.

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

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

Images