СЖАТИЕ ПОЛЕЗНОЙ НАГРУЗКИ СООБЩЕНИЯ ПРОТОКОЛА ИНИЦИИРОВАНИЯ СЕАНСА Российский патент 2012 года по МПК H04L29/06 H04W80/10 

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

Изобретение относится к сжатию полезных нагрузок сообщений протокола инициирования сеанса

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

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

Подсистема мультимедиа IP (IMS) является технологией, определенной Проектом партнерства третьего поколения (3GPP) и группой TISPAN ETSI, чтобы предоставлять услуги мультимедиа IP через мобильные сети связи (версии 5-7 TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29. 328 и TS 29.329, и версия 7 TS 24.173 3GPP). 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), ролью которой является идентифицировать правильную CSCF и передать в эту CSCF запрос, принятый из терминала SIP через P-CSCF.

В сети службы IMS серверы приложений (AS) обеспечены для осуществления функциональных возможностей службы IMS. Серверы приложений предоставляют услуги конечным пользователям в системе IMS и могут быть соединены либо как конечные пункты через определенный 3GPP интерфейс Mr, либо “связаны” с помощью S-CSCF через определенный 3GPP интерфейс ISC. В последнем случае первоначальные критерии фильтра (IFC) используют с помощью S-CSCF, чтобы определить, какие серверы приложений должны быть “связаны” во время установления сеанса SIP (или, фактически, с целью любого относящегося способа, сеанса и не сеанса SIP). IFC принимают с помощью S-CSCF из HSS во время процедуры регистрации IMS как часть профиля абонента абонента.

Иллюстративная служба IMS, которую облегчают с помощью использования AS, является службой “присутствия”. Служба присутствия позволяет пользователям распространять свою текущую доступность и местоположение другим пользователям и включает в себя использование AS присутствия в IMS. Пользователь обновляет его/ее статус присутствия с помощью AS присутствия с использованием способа ОПУБЛИКОВАТЬ SIP, а затем AS присутствия выдает сообщения УВЕДОМИТЬ SIP одноранговым пользователям, которые подписаны на это присутствие пользователя. Подписка включает в себя посылку пользователем сообщения ПОДПИСАТЬСЯ SIP в AS присутствия, идентифицирующего пользователя, на присутствие которого подписаны. Для того чтобы уменьшить объем трафика, относящегося к присутствию, проходящего в сети IMS, может быть введен так называемый AS сервера списка ресурсов (RLS). RLS действует как “концентратор” для сообщений УВЕДОМИТЬ, направленных данному пользователю, буферизирующий сообщения УВЕДОМИТЬ, принятые в течение некоторого предварительно определенного периода времени, и посылающий только одно объединенное сообщение УВЕДОМИТЬ подписывающемуся пользователю в конце этого периода. AS RLS также действует как “посредник” для сообщений ПОДПИСАТЬСЯ, принятых от пользователя.

Понятно, что сообщение УВЕДОМИТЬ может быть очень большим, причем полезные нагрузки превышают 64 кбайт. Другие сообщения SIP также могут быть большими. По существу, желательно быть в состоянии сжимать сообщения, чтобы уменьшить нагрузку сети. Кроме того, сжатие сообщений может уменьшить общее время ожидания, поскольку большие сообщения, посланные через эфирный интерфейс (и в сети), обязательно могут быть разделены на несколько меньших сообщений.

WO2006/030277 описывает способ и устройство, предназначенные для сжатия сообщений протокола SIP на основании способа, известного как SIGCOMP (RFC 3320 и 3321 IEEE). Описанный подход включает в себя проверку типа сообщения и содержания и выборочного сжатия всего заголовка и полезной нагрузки или их частей, для того чтобы оставить те компоненты сообщения, которые должны быть читаемыми с помощью промежуточных узлов сети, в открытом тексте.

Сам SIGCOMP включает в себя как статическую, так и динамическую библиотеки, в IMS, и осуществлен в терминале IMS и в P-CSCF. Статическая библиотека содержит предварительно определенные элементы для сжатия и распаковки конкретных сообщений и частей сообщений. Она имеет два ограничения. Во-первых, количество информации сжатия/преобразования, которое может содержать статическая библиотека, может быть ограничено в терминале конечного пользователя вследствие имеющейся памяти. Во-вторых, добавление новых элементов сжатия в статическую библиотеку требует изменений, как стороны сервера, так и клиента. Динамическая библиотека использует предыдущие сообщения, чтобы сжимать и распаковывать сообщения. Несмотря на то, что использование динамической библиотеки будет достигать достаточно высокого коэффициента сжатия, когда сообщения включают в себя подобные данные, если данные сильно изменяются от сообщения к сообщению, что будет в среде с множеством служб, коэффициент сжатия будет низким.

Несмотря на коэффициенты сжатия, достигнутые с помощью подходов, основанных на SIGCOMP, SIGCOMP пока широко не используют (и статические библиотеки будут требовать постоянную стандартизацию) и, по существу, в течение некоторого времени будет существовать выпуск большого числа терминалов, которые не имеют самую последнюю поддержку SIGCOMP или совсем без поддержки SIGCOMP. Если, например, приложение присутствия SIP разработано для такого традиционного оборудования, связанное сообщение SIP должно быть передано распакованным. Эта проблема также является применимой для других типов уведомлений SIP, например, уведомлений, выполняемых с использованием пакета события изменения XCAP.

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

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

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

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

Желательно использовать широко известный и легкодоступный алгоритм для сжатия и распаковки полезных нагрузок. Например, может быть использован алгоритм gzip (сокращение от zip GNU).

Например, в случае службы присутствия, осуществленной через IMS, предпочтительным является включить в сообщение ПОДПИСАТЬСЯ SIP, посланное из пользовательского терминала в сервер приложения протокола инициирования сеанса, указание, что сжатие полезной нагрузки должно быть выполнено в сервере приложения. Полезные нагрузки сообщений УВЕДОМИТЬ SIP, посланные затем из сервера приложения в пользовательский терминал, и относящиеся с событием абонента, сжимают. Предпочтительно упомянутое указание включают в поле заголовка принятия или принятия-кодирования сообщения ПОДПИСАТЬСЯ. Еще более предпочтительно способ содержит запись поля заголовка принятия или принятия-кодирования в пользовательского агента протокола инициирования сеанса из упомянутого прикладного уровня через упомянутый интерфейс прикладного программирования. В случае службы присутствия способ может содержать включение в сообщение ОПУБЛИКОВАТЬ SIP, посланное из пользовательского терминала в сервер приложения протокола инициирования сеанса, указание, что полезная нагрузка сообщения является сжатой, например, в поле заголовка содержание-тип. Конечно, эти процедуры могут быть использованы в службах IMS, отличных от присутствия.

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

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

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

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

Фиг.1 схематически иллюстрирует интегрирование подсистемы мультимедиа IP в систему мобильной связи 3G;

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

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

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

Как уже обсуждено, некоторое число разных сообщений SIP, использованных в подсистеме мультимедиа IP (IMS), может включать в себя очень большое количество данных полезной нагрузки. Такие сообщения включают в себя, например, уведомления SIP (например, для изменений присутствия, RLS и XCAP), и публикации SIP (например, для присутствия). Было бы выгодным использовать механизм сжатия, чтобы уменьшить размер сообщения, в частности, чтобы оптимизировать использование полосы частот эфирного интерфейса.

Кроме того, для того чтобы позволить сжатие, используемое с традиционными терминалами, которые не используют SIGCOMP (или, по меньшей мере, SIGCOMP с самыми последними статическими библиотеками сжатия), желательно облегчить сжатие на прикладном уровне, выше уровня SIP.

В настоящей заявке предложено ввести процедуру сжатия/распаковки на прикладном уровне для сжатия/распаковки только полезных нагрузок сообщений, и которая использует обычно используемый алгоритм сжатия, такой как “gzip”. Gzip основан на алгоритме ПОНИЗИТЬ ПОРЯДОК, который является комбинацией кодирования LZ77 и Хаффмана. В качестве альтернативы gzip может быть использован широко известный формат сжатия zip.

Сжатие не выполняют в заголовках сообщений SIP и, по существу, любой модуль-посредник SIP, через который проходит сообщение, не будет затронут, поскольку фактическая информация SIP не является сжатой. Это проиллюстрировано на фиг.2, где пользовательский терминал указан с помощью ссылочного номера 1, AS (наличия) или RLS, с помощью ссылочного номера 2, соответственные UA SIP с помощью 3а, 3b, а соответственные прикладные уровни с помощью 4а, 4b. Функции gzip указаны с помощью ссылочных номеров 5а, 5b. Иллюстративная CSCF указана с помощью ссылочного номера 6.

По меньшей мере, в некоторых вариантах осуществления процессы сжатия/распаковки являются полностью прозрачными для пользовательских агентов SIP (либо в пользовательском терминале, либо в сервере приложения SIP). Соответственное приложение просто обменивается данными полезной нагрузки с UA SIP через соответственный интерфейс прикладного программирования (API) UA SIP, и UA SIP не заботится о том, что сжаты ли данные или нет. [Соответственные API указаны на фиг.2 с помощью ссылочных номеров 7а, 7b]. Эта процедура проиллюстрирована на блок-схеме последовательности этапов фиг.3. Однако в других вариантах осуществления может быть желательным позволить пользовательскому терминалу указывать, например, в первоначальном сообщении ПОДПИСАТЬСЯ SIP, что он поддерживает сжатую полезную нагрузку в сообщениях УВЕДОМИТЬ SIP. Это может быть выполнено, например, с помощью разрешения приложению записывать соответствующий оператор в заголовок сообщения SIP. Например, существующие поля заголовка “принять” или ”принять-кодирование” могли бы быть использованы для этой цели, или может быть задано новое поле заголовка SIP. При допущении, что уведомитель (например, AS присутствия) также поддерживает сжатие, он будет сжимать полезные нагрузки всех сообщений УВЕДОМЛЕНИЕ SIP, посланные абоненту и относящиеся к событию, на который подписан. Указание, что полезная нагрузка является сжатой, может содержаться в заголовке сообщения, например, с использованием поля заголовка “содержание-тип”, сообщений ОПУБЛИКОВАТЬ и УВЕДОМИТЬ.

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

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

Изобретение относится к сжатию полезных нагрузок сообщений протокола инициирования сеанса (SIP). Техническим результатом является обеспечение сжатия сообщений, чтобы уменьшить нагрузку сети. Указанный технический результат достигается тем, что предложен способ транспортировки сообщений протокола инициирования сеанса через сеть мультимедиа IP между пользовательским терминалом (1) и сервером (2) приложения протокола инициирования сеанса. Способ содержит сжатие полезных нагрузок сообщений в прикладном уровне (4а, 5а) на посылающей стороне и распаковку их на прикладном уровне (4b, 5b) на принимающей стороне, причем сжатые полезные нагрузки сообщений передают между прикладным уровнем и пользовательским агентом (3а) протокола инициирования сеанса через соответствующий интерфейс (7а) прикладного программирования. 4 н. и 9 з.п. ф-лы, 3 ил.

1. Способ транспортировки сообщений УВЕДОМИТЬ протокола инициирования сеанса через сеть мультимедиа IP между пользовательским терминалом и сервером приложения протокола инициирования сеанса, содержащий этапы, на которых сжимают полезные нагрузки сообщений УВЕДОМИТЬ в прикладном уровне на посылающей стороне и распаковывают их на прикладном уровне на принимающей стороне, причем сжатые полезные нагрузки сообщений УВЕДОМИТЬ передают между прикладным уровнем и пользовательским агентом протокола инициирования сеанса через соответствующий интерфейс прикладного программирования, отличающийся тем, что в пользовательском терминале прикладной уровень записывает в заголовок сообщения ПОДПИСАТЬСЯ SIP, который следует послать в сервер приложения протокола инициирования сеанса, указание, что сжатие полезной нагрузки поддерживают с помощью пользовательского терминала.

2. Способ по п.1, в котором заголовки сообщений посылают распакованными таким образом, что сообщения могут быть маршрутизированы через любые промежуточные функции управления вызовом/сеансом (CSCF) и серверы приложений.

3. Способ по п.1 или 2, в котором упомянутые сжатие и распаковку полезных нагрузок сообщений выполняют с использованием алгоритма gzip.

4. Способ по п.1 или 2, содержащий этап, на котором включают упомянутое указание в поле заголовка принятия или принятия-кодирования сообщения ПОДПИСАТЬСЯ.

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

6. Способ по п.1, 2 или 5, в котором упомянутые сообщения ПОДПИСАТЬСЯ и УВЕДОМИТЬ относятся к службе присутствия.

7. Способ транспортировки сообщений ОПУБЛИКОВАТЬ протокола инициирования сеанса через сеть мультимедиа IP между пользовательским терминалом и сервером приложения протокола инициирования сеанса, содержащий этапы, на которых сжимают полезные нагрузки сообщений ОПУБЛИКОВАТЬ в прикладном уровне на посылающей стороне и распаковывают их на прикладном уровне на принимающей стороне, причем сжатые полезные нагрузки сообщений ОПУБЛИКОВАТЬ передают между прикладным уровнем и пользовательским агентом протокола инициирования сеанса через соответствующий интерфейс прикладного программирования, отличающийся тем, что в пользовательском терминале прикладной уровень записывает в заголовок сообщения ОПУБЛИКОВАТЬ SIP, который следует послать в сервер приложения протокола инициирования сеанса, указание, что полезная нагрузка сообщения является сжатой.

8. Способ по п.7, содержащий этап, на котором включают упомянутое указание в поле заголовка "содержание-тип" сообщения ОПУБЛИКОВАТЬ.

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

10. Способ по любому из пп.7-9, в котором упомянутое сообщение ОПУБЛИКОВАТЬ относится к службе присутствия.

11. Способ по любому из пп.7-9, в котором упомянутый сервер приложения протокола инициирования сеанса является сервером списка ресурсов.

12. Пользовательский терминал, сконфигурированный с возможностью работы в сети службы подсистемы мультимедиа IP, причем пользовательский терминал осуществляет один или более прикладных уровней, связывающихся с пользовательским агентом протокола инициирования сеанса, причем прикладной уровень или уровни связываются с пользовательским агентом протокола инициирования сеанса через интерфейс прикладного программирования, при этом пользовательский терминал дополнительно сконфигурирован с возможностью приема сообщений УВЕДОМИТЬ SIP в пользовательском агенте протокола инициирования сеанса, передачи их в прикладной уровень или уровни через упомянутый интерфейс прикладного программирования и распаковки полезных нагрузок входящих сообщений УВЕДОМИТЬ SIP на прикладном уровне или уровнях, причем прикладной уровень или уровни сконфигурированы с возможностью записи в заголовок сообщения ПОДПИСАТЬСЯ SIP, которое следует послать в сервер приложения протокола инициирования сеанса, указания, что сжатие полезной нагрузки поддерживают с помощью пользовательского терминала.

13. Сервер приложения протокола инициирования сеанса, сконфигурированный с возможностью работы в сети службы подсистемы мультимедиа IP, причем сервер приложения осуществляет один или более прикладных уровней, связывающихся с пользовательским агентом протокола инициирования сеанса, при этом прикладной уровень или уровни связываются с протоколом инициирования сеанса через интерфейс прикладного программирования, причем сервер приложения дополнительно сконфигурирован с возможностью сжатия полезных нагрузок исходящих сообщений УВЕДОМИТЬ SIP на прикладном уровне или уровнях и обмена сжатыми полезными нагрузками с пользовательским агентом протокола инициирования сеанса через упомянутый интерфейс прикладного программирования, причем сервер дополнительно сконфигурирован с возможностью приема из пользовательского терминала сообщение ПОДПИСАТЬСЯ SIP, идентификации в заголовке этого сообщения указания, что сжатие полезной нагрузки поддерживают с помощью пользовательского терминала, и инициирования сжатия полезной нагрузки сообщений УВЕДОМИТЬ, посланных в этот пользовательский терминал.