Способ и элемент для управления службой

Способ и элемент для управления службой

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

Во время разработки мобильных систем второго поколения (2G) организациями стандартизации были полностью определены полные наборы сетей, телесервисов, применений и дополнительных служб. Однако для промышленности общим интересом является сокращение времени на разработку спецификаций предоставителей служб, ускорение введения новых служб и возможность плавного масштабирования служб. При разработке мобильных сетей третьего поколения (3G) был применен подход, нацеленный на стандартизацию возможностей служб вместо стандартизации служб как таковых.

Европейский Институт Телекоммуникационных Стандартов (ETSI) определяет управление службой как возможность пользователя, домашнего окружения или обслуживающего окружения определять, что выполняет определенная служба, для специфического вызова этой службы, в пределах этой службы. В основном, это означает, что архитектура любой системы должна обеспечивать структуру службы, которая способствует соответствующей надежности, качеству обслуживания, тарификации и управлению сессией для поддержки различных служб в такой системе. Сначала некоторое число поставщиков служб, например, службы управления цифровыми правами и службы РоС (push to talk over cellular - "нажми кнопку и говори по сотовой") генерировали модели управления службой более или менее независимо, просто в ответ на то, что именно нужно потребителю. Позже различные поставщики служб кооперировались в рамках глобальной организации, называемой Open Mobile Alliance (ОМА), для использования инфраструктуры, предоставляющей требуемые основные возможности.

В настоящее время эта инфраструктура называется Internet Protocol Multimedia Subsystem (IMS, подсистема IP-мультимедиа). Она имеет отношение к архитектуре независимого доступа, базирующейся на IP и взаимодействующей с существующими голосовыми сетями и сетями данных, доступными как для пользователей фиксированной, так и мобильной связи. Архитектура IMS облегчает пиринговую IP-связь с разными типами клиентов с требуемым качеством служб. IMS основана на спецификации Session Initiation Protocol (SIP, протокол инициирования сессии), стандартизованной организацией Engineering Task Force (IETF). Так называемый 5-й релиз представляет IMS как часть стандарта 3GPP. 3GPP и ОМА сделали выпуски спецификаций IMS публично доступными.

Сессия связана с интервалом, во время которого существует логическое соответствие между двумя объектами для передачи соответствующей информации. Сессия может включать, например, передачу голосовой или видеоинформации. В IMS выбранный управляющий протокол прикладного уровня для создания, изменения и прекращения сессий с одним или больше участниками представляет собой SIP. Во время сессии пользователи могут иметь несколько соединений с приложениями служб. Для каждой IMS-сессии управление службой для IMS поддерживает состояние сессии, взаимодействует с платформами служб и функциями тарификации в соответствии с требованиями службы. Логический элемент сети, ответственный за эти функции, называется обслуживающей функцией управления сессией вызова (Serving Call Session Control Function, S-CSCF).

В архитектуре IMS службы расположены и исполняются в платформах служб, серверах приложений (Application Servers, AS). Для отправки и приема SIP-сообщений между S-CSCF и AS определяется контрольная точка Управления Службой IMS (ISC). При приеме SIP-запроса S-CSCF будет анализировать его и принимать решение о маршрутизации этого запроса к AS для дальнейшей обработки. Анализ базируется на профиле службы, ассоциированном с указанным в запросе идентификатором открытого пользователя. Профиль службы связан с набором информации, специфичной для пользователя (например, критерии фильтра), доступным для S-CSCF как минимум во время выполнения S-CSCF операций по обработке данных этого конкретного пользователя. Обычно профиль службы или по меньшей мере критерии фильтра загружаются в S-CSCF при регистрации пользователя или при приеме завершения начального запроса для незарегистрированного пользователя.

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

Возможность агента пользователя (UA) для использования подготовленного приложения могут, однако, изменяться динамически. В соответствии с RFC 3840 возможность определена как атрибут отправителя или получателя, который указывает способность генерировать или обрабатывать определенный тип контента сообщений. Возможность отличается от характеристики в том, что возможность может быть использована/не использована в любой конкретный период, например, во время одиночного вызова, в то время как характеристика - это неизменяемое свойство UA. Например, агенты пользователя могут широко изменяться в своих возможностях и в типах устройств, которые эти агенты представляют. Критерии фильтра, однако, являются по существу статическими определениями, которые не способствуют динамическим вариациям, вызванным, например, возможностями текущего используемого терминального оборудования.

Например, пользователь IMS может быть подписан на использование службы РоС, но не быть зарегистрированным пользователем РоС в текущий момент, потому что он использует в этот момент терминал без возможностей РоС. Когда входящий запрос, адресованный такому пользователю IMS, принимается S-CSCF, S-CSCF анализирует этот запрос и сравнивает его с критериями фильтра. Критерии фильтра указывают, что если запрос содержит индикацию возможности службы РоС, то сообщение должно быть перенаправлено на заданный РоС AS. Служба IMS в действительности содержит механизм, по которому AS может определить несоответствие и соответствующим образом прервать инициацию сессии. Однако к этому времени маршрутирование к AS уже выполнено. Это добавляет ненужную нагрузку на сервер РоС и, в зависимости от установленного типа ответа на сервере РоС, может генерировать тарификационные действия, которые должны быть согласованы и организованы отдельно; например, тарификационные записи должны будут стерты/отменены. Более того, это является ощутимым техническим недостатком, который ухудшает условия принятия и реализации службы в системе IMS.

КРАТКОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг.1 - блок-схема сигнализации, которая иллюстрирует поток информации между элементами IMS при установлении IMS-сессии высокого уровня;

Фиг.2 - блок-схема сигнализации, когда конечное оборудование пользователя перерегистрировано в IMS без возможностей РоС.;

Фиг.3 - ситуация, иллюстрированная на фиг.2, но улучшенная с помощью предложенного решения;

Фиг.4 - профиль пользователя, ассоциированный с абонентом IMS;

Фиг.5 - более детальная структура критериев фильтра;

Фиг.6 - более детальная структура триггерных точек фиг.5;

Фиг.7 - блок-схема, иллюстрирующая работу элемента управления службой для конечного оборудования пользователя;

Фиг.8 - функциональная архитектура элемента управления службой;

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

Фиг.10 - процедура, иллюстрированная на фиг.9, но улучшенная с помощью предложенного решения.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Настоящее изобретение применимо к различным пакетным архитектурам мультимедиа с независимым доступом, взаимодействующим, например, с голосовыми сетями и сетями данных для фиксированных (PSTN, ISDN, Интернет) и мобильных пользователей (GSM; CDMA; WCDMA) и содержащим управление службой, которое содействует установлению пиринговых коммуникаций с различными типами клиентов. Примеры таких систем включают 3GPP IMS, 3GPP MMD (Multi-Media Domain), сети IETF SIP, сети SIP как таковые, а также сети ETSI TISPAN NGN, которые могут иметь различные типы сетей доступа, например, GERAN, UTRAN, WLAN, фиксированный широкополосный доступ, в случае фиксированной/мобильной связи - также сети доступа PSTN/ISDN. В дальнейшем данное изобретение иллюстрировано посредством служб IMS и РоС, однако без ограничения данного изобретения терминами, протоколами и логическими элементами, использованными здесь.

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

Оборудование пользователя (UE) может быть упрощенным терминалом только для передачи речи, либо оно может быть терминалом для иных служб, действующим как платформа служб с поддержкой загрузки и выполнения различных функций, относящихся к этим сервисам. В этом контексте термин «оборудование пользователя» в основном относится к объекту, включающему идентификатор абонента и реальное мобильное оборудование. Мобильное оборудование пользователя в следующих реализациях включает действительное мобильное оборудование и отделяемый модуль идентификации абонента, без ограничения рассмотрения рамками только такой конфигурации. Ясно, что некоторое оборудование пользователя, например, фиксированные терминалы для широкополосного доступа не содержат отдельный модуль идентификации. Модуль идентификации абонента обычно является смарткартой, которая по существу содержит идентификатор абонента, выполняет алгоритм аутентификации и сохраняет ключи аутентификации и шифрования, а также другую абонентскую информацию, которая нужна оборудованию пользователя. Мобильное оборудование обычно является радиотерминалом, используемым для радиосвязи между оборудованием пользователя и сетью. Мобильное оборудование может быть любым оборудованием, способным к коммуникациям в мобильной системе связи, или комбинацией нескольких единиц оборудования, например, компьютером для мультимедиа с подсоединенным телефоном для обеспечения мобильного соединения.

Пользователь IMS имеет один или более публичных идентификаторов пользователя, которые используются любым пользователем для запроса соединения с другими пользователями. Публичный идентификатор/идентификаторы пользователя обычно имеет формат SIP-URI или TEL-URI (tel URL). Публичный идентификатор пользователя (Public User Identity) обычно должен быть зарегистрирован явно или неявно, перед тем как идентификатор может быть использован для участия в сессиях IMS и в процедурах, не связанных с сессией IMS. В некоторых случаях такая регистрация, однако, сделана другими средствами, например со статической (постоянной, полупостоянной) регистрацией, при подсоединении оборудования пользователя к фиксированной линии.

Когда вызывающий пользователь А желает выполнить РоС-вызов к вызываемому пользователю В, оборудование пользователя A (UEa) генерирует запрос SIP INVITE (шаг 1.1), помещает в Accept-Contact Header запроса тег функции РоС "+g.poc.talkburst" и отсылает запрос к прокси-функции управления сессией вызова (Proxy-Call Session Control Function, P-CSCF_A). P-CSCF_A представляет первую контактную точку UE_A в IMS. Если запрос сжатый, P-CSCF_A распаковывает запрос, верифицирует идентификатор вызывающего пользователя А и перенаправляет этот запрос (шаг 1.2) к обслуживающей функции управления сессией вызова (S-CSCF_A) внутренней сети пользователя А. S-CSCF_A отвечает за управление сессией и службы регистрации для оборудования пользователя. Когда бы ни было оборудование пользователя вовлечено в сессию, S-CSCF_A поддерживает состояние сессии и взаимодействует с платформами служб для обеспечения работы службы.

S-CSCF_A обрабатывает запрос, выполняет управление службой и, базируясь на идентификаторе вызываемого пользователя в запросе SIP INVITE, определяет входную точку местной сети пользователя В. Опрашивающая функция управления сессией вызова (Interrogating Call Session Control Function, I-CSCF_B) - это контактная точка в пределах одной сети для соединений, адресованных абоненту оператора этой сети. S-CSCF посылает (шаг 1.3) запрос SIP INVITE к I-CSCF_B, взаимодействующей (шаги 1.4 и 1.5.) с домашним сервером абонента (Home Subscriber Server, HSS_B) домашнего оператора пользователя В для определения S-CSCF_B, которая обслуживает оборудование пользователя (UЕ_B). Приняв запрос (шаг.1.6), S-CSCF_B берет на себя обработку сессии вызываемого абонента.

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

Если метод = "INVITE" и заголовок = "Accept-Contact" = "+g.poc.talkburst", тогда: НАПРАВИТЬ запрос к определенному вызываемому порту сервера РоС.

Поскольку критерий фильтра совпадает с запросом, S-CSCF_B перенаправляет запрос (шаг 1.7.) к РоС AS. Следует отметить, что представленные критерии фильтра относятся к примерам и включают только элементы, необходимые для иллюстрации настоящей реализации данного изобретения. Специалисту ясно, например, что критерий фильтра может быть в другом формате и может включать другие элементы, не показанные в проиллюстрированном примере. РоС AS осуществляет логику службы в соответствии со службой РоС и маршрутирует запрос INVITE назад (шаг 1.8) к S-CSCF_B. S-CSCF_B передает запрос (шаг 1.9) к P-CSCF_B, который в итоге передает запрос в UЕ_B. Оборудование пользователя UЕ_A и UE_B будет обмениваться между собой некоторыми дополнительными данными для завершения установления сессии, а затем может начаться вызов РоС.

Фиг.1 относится к нормальному случаю, когда между подготовленным приложением и возможностями оборудования пользователя не обнаружено несоответствия. Фиг.2 иллюстрирует ситуацию, когда UE_B перерегистрировано в IMS, однако (например, для указания того, что пользователь не желает принимать любые сессии РоС) не включает в регистрацию индикацию возможностей РоС. Входящий запрос перенаправляется к РоС AS таким же способом, как и в шагах 1.1…1.7 на фиг.1.

Затем РоС AS может обнаружить несоответствие в силу наличия тега функции РоС "+g.poc.talkburst" в запросе и указанных возможностей оборудования UE_B вызываемого пользователя при условии, что указанные возможности оборудования UЕ_B вызываемого пользователя доступны в РоС AS. Если РоС AS обнаруживает несоответствие, то, согласно его логике службы, он прекращает инициацию сессии и посылает (шаги 2.8…2.12) соответствующее сообщение ошибки к вызывающему оборудованию UЕ_A пользователя. Если РоС AS не обнаруживает несоответствия, он обрабатывает запрос и перенаправляет его к S-CSCF для дальнейшей отправки к UЕ_B. Перед отправкой к UЕ_B S-CSCF проверяет указанные возможности UЕ_B и проверяет несоответствие. Если S-CSCF обнаруживает несоответствие, она прекращает инициацию сессии и посылает соответствующее сообщение ошибки к вызывающему оборудованию UЕ_B пользователя.

Операции по отношению к РоС AS и в нем самом вызывают дополнительную сигнализационную нагрузку на сервер РоС и/или S-CSCF, которая в перегруженной системе должна быть устранена. Эти операции также генерируют одну или несколько детальных записей вызовов, которые в нормальной сессии могут быть использованы как основа для начисления оплаты абоненту. Подобная излишняя тарификационная информация создает совокупный объем работы, который должен быть устранен.

Фиг.3 иллюстрирует ситуацию, подобную фиг.3, но уже улучшенную с помощью реализации изобретенного решения. Запрос перенаправлен к S-CSCF таким же образом, как и в шагах 1.1…1.6 на фиг.1. Затем S-CSCF обнаруживает критерий управления службой, что показано посредством критерия фильтра:

Если метод = "INVIТЕ" и заголовок = "Accept-Contact" = "+g.poc.talkburst" и заголовок контакта запроса ЗАРЕГИСТРИРОВАТЬ включает '+g.poc.talkburst', тогда: НАПРАВИТЬ запрос к определенному Вызываемому Порту Сервера РоС.

Поскольку не все условия по логическому «И» вышеуказанного критерия фильтра выполнены (т.е. зарегистрированный заголовок контакта UЕ_B не включает тег функции РоС '+g.poc.talkburst'), то запрос не перенаправлен к РоС AS, а вместо этого возвращен (шаги 3.7…3.10) к вызывающему оборудованию UE_A пользователя с соответствующим кодом ошибки. Таким образом, несоответствие обнаружено перед достижением РоС AS, и неуместная операция устранена.

Следует отметить, что критерий фильтра, используемый в данном описании текущей реализации, служит просто примером критерия управления службой и использован для передачи основного логического содержимого, необходимого для иллюстрации данного изобретения. Для специалиста ясно, что для управления доступом к службе, предоставленной платформой службы, применим любой тип набора связей, относительно которого могут быть выражены иные связи. Кроме того, запрос REGISTER сам по себе, необходимая часть или информация из этого запроса может быть сохранена в любой момент регистрации, например, при регистрации, перерегистрации или дерегистрации. Более того, данное изобретение пригодно как для запросов (например, SIP INVITE), так и для отдельных транзакций (например, SIP MESSAGE).

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

Фиг.4 иллюстрирует профиль пользователя, ассоциированный с абонентом IMS, в соответствии с реализацией настоящего изобретения. Когда пользователь получает подписку IMS, ему присвоен профиль пользователя. Профиль пользователя включает по меньшей мере один персональный идентификатор 40 пользователя и единственный профиль службы 41. Профиль пользователя может иметь более одного персонального идентификатора пользователя (что позволяет иметь множество зарегистрированных адресов контакта), и одна подписка IMS может содержать множество профилей служб. Профиль служб включает открытый идентификатор 42, авторизацию 43 службы базовой сети и блок 44 критериев фильтра. Открытый идентификатор 42 включает открытые идентификаторы пользователя (SIP uniform resource identifiers (URI) или tel URI), которые ассоциированы с профилем службы. Авторизация 43 службы базовой сети может нести информацию о медиаполитике, что позволяет операторам предоставлять различные абонентские профили в их сетях IMS.

Критерии 44 фильтра представляют информацию для запуска служб, которая описывает, когда входящее SIP-сообщение далее маршрутируется к серверу конкретного приложения. В соответствии с данным изобретением информация фильтра организована так, чтобы позволить выполнить проверку динамических возможностей ассоциированного оборудования пользователя по использованию службы, предоставляемой сервером приложений. В настоящей реализации пользователь во время регистрации в IMS указывает возможность РоС включением в запрос тега функции носителя "+g.poc.talkburst".

Фиг.5 иллюстрирует более детально структуру критерия фильтра. Критерий фильтра включает один или ни одного экземпляра триггерных точек 50 и один экземпляр сервера 51 приложений. Критерии фильтра могут быть снабжены взаимными приоритетами посредством приоритетных номеров и затем оцениваться в порядке приоритета. Сервер 51 приложений определяет AS, с которым устанавливается связь всякий раз, когда есть соответствие критерию фильтра. Сервер 51 приложений может также включать служебную информацию, которая передается прямо через S-CSCF к AS, когда есть соответствие условиям критериев фильтра во время регистрации.

Триггерная точка 50 определяет условия, которые проверяются для выяснения, нужно ли в IMS контактировать с AS, указанным сервером 51 приложений. В соответствии с данным изобретением триггерная точка организована так, что включает информацию о динамических возможностях ассоциированного оборудования пользователя по использованию службы, предоставленной сервером 51 приложений. В настоящей реализации триггерная точка побуждает S-CSCF проверить, указало ли оборудование вызываемого пользователя во время регистрации в IMS возможность РоС включением в запрос тега функции носителя "+g.poc.talkburst".

Фиг.6 иллюстрирует более детально структуру триггерной точки 50. Триггерная точка включает один или более экземпляр триггера 60 точки службы (SPT). Экземпляр SPT 60, в соответствии с настоящим изобретением, включает:

- Запрос-URI для идентификации ресурса, к которому направлен запрос.

- S/P метод для указания типа запроса.

- S/P заголовок для обеспечения данных, относящихся к запросу, например, для запуска на присутствие или отсутствие любого заголовка SIP или для запуска содержимого заголовка/заголовков SIP.

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

- Описание сессии для определения SPT для содержимого любого поля SDP в теле SIP метода.

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

В другой реализации данного изобретения элемент информации о возможностях, который проверяет динамические возможности оборудования пользователя по использованию конкретной службы, не сделан частью критериев фильтра пользователя, а вместо этого сохранен во время регистрации или перед ней либо в S-CSCF, либо в базе данных, файле, списке, таблице и т.п., либо на уровне системных критериев фильтра, общем для одного или более пользователей, и применен перед маршрутированием к AS, например, совместно с определением критериев фильтра. Это проиллюстрировано посредством фиг.7, относящейся к типу соединения и элементам, показанным на фиг.1. На шаге 710 S-CSCF принимает запрос и берет на себя обработку сессии, которая выходит на пользователя UЕ_B. В шаге 715 S-CSCF проверяет, зарегистрирован ли UE_B. В случае, когда UE_B не зарегистрирован, S-CSCF_B загружает (шаг 720) из HSS_B местного оператора пользователя В критерии фильтра, ассоциированные с идентификатором, принятым в запросе. В случае, когда UE_B зарегистрирован, чтение критериев фильтра доступно для S-CSCF_B. S-CSCF_B начинает проходить эти критерии фильтра один за другим, проверяя, совпадает ли любой из этих критериев с параметрами принятого запроса (шаг 725). При любом совпадении S-CSCF выполняет (шаг 730) соответствующую логику службы в соответствии с заранее заданным приоритетом между службами.

В соответствии с реализацией S-CSCF также проверяет (шаг 735) по меньшей мере для одной службы S(q) (но предпочтительно для всех подходящих служб), доступна ли какая-либо информация Контакт/возможности терминала, относящаяся к определенной службе S(q). Например, в случае службы РоС S-CSCF организована для проверки, зарегистрировано ли оборудование UE_B пользователя, и если да, был ли принят тег функции РоС при регистрации. В случае совпадения (шаг 740) между службой S(q) и информацией о возможностях терминала, записанной в S-CSCF, S-CSCF продолжает логику службы S(q), как предписано. Например, в реализации, показанной на фиг.1, в случае, если информация о возможности РоС, принятая во время регистрации UЕ_B, совпадает с тегом функции РоС в запросе, запрос INVITE перенаправляют к РоС AS. Иначе S-CSCF выполняет альтернативную функцию F(q). В последнем случае S-CSCF прекращает сессию и направляет соответствующее сообщение ошибки к оборудованию UЕ_B вызывающего пользователя. Для специалиста ясно, что реализация функции F(q), вызываемой при несоответствии возможностей терминала и входного запроса, может быть определена в соответствии с приложением. Например, может быть определено, что в случае несоответствия S-CSCF будет запрашивать из UЕ_B возможность/возможности терминала перед отправкой запроса к AS службы S(q).

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

Если метод = "INVIТЕ" и заголовок = "Accept-Contact"="+g.poc.talkburst", тогда: НАПРАВИТЬ запрос к определенному вызываемому порту сервера РоС.

1. При регистрации оборудования пользователя критерии фильтра редактируют для включения возможностей терминала. Например, содержимое заголовка контакта запроса РЕГИСТРИРОВАТЬ может быть скопировано в критерии фильтра. Критерии фильтра тогда включают:

Если метод = "INVIТЕ" и заголовок = "Accept-Contact" = "+g.poc.talkburst" и "+g.poc.talkburst" включен в "aaa:bbb:ccc::333:444:555;+g.poc.talkburst", тогда: НАПРАВИТЬ запрос к определенному вызываемому порту сервера РоС.

2. При регистрации оборудования пользователя критерии фильтра редактируют для включения возможностей терминала. Например, содержимое заголовка контакта запроса РЕГИСТРИРОВАТЬ сохраняют как регистрационные данные в S-CSCF и указатель на структуру данных, содержащую сохраненный заголовок Контакт, добавляют к критериям фильтра. Тогда критерии фильтра включают:

Если метод = "INVIТЕ" и заголовок ="Accept-Contact" = "+g.poc.talkburst" и "+g.poc.talkburst" включен в &УКАЗАТЕЛЬ (структура данных, содержащая сохраненное содержимое заголовка контакта запроса ЗАРЕГИСТРИРОВАТЬ), тогда: НАПРАВИТЬ запрос к определенному вызываемому порту сервера РоС.

3. При регистрации оборудования пользователя критерии фильтра редактируют для включения возможностей терминала. Например, содержимое заголовка контакта запроса РЕГИСТРИРОВАТЬ сохраняют как регистрационные данные в S-CSCF, и ссылка на адрес, где сохранен заголовок Контакта, добавляется к критериям фильтра. Тогда критерии фильтра включают:

Если метод = "INVIТЕ" и заголовок = "Accept-Contact" = "+g.poc.talkburst" и "+g.poc.talkburst" включен в &ССЫЛКУ (сохраненное содержимое заголовка Контакта запроса ЗАРЕГИСТРИРОВАТЬ), тогда: НАПРАВИТЬ запрос к определенному вызываемому порту сервера РоС.

4. При регистрации оборудования пользователя критерии фильтра не редактируют, но они содержат статическую ссылку на сохраненные возможности терминала. Например, содержимое заголовка Контакта запроса ЗАРЕГИСТРИРОВАТЬ может быть сохранено в критериях фильтра вместе или по адресу со ссылкой &ССЫЛКА456. Тогда критерии фильтра включают:

Если метод = "INVIТЕ" и заголовок ="Accept-Contact" = "+g.poc.talkburst" и "+g.poc.talkburst" включен в &ССЫЛКУ, тогда: НАПРАВИТЬ запрос к определенному вызываемому порту сервера РоС.

5. При регистрации оборудования пользователя критерии фильтра не редактируют, а возможности терминала сохраняют при регистрации. Например, запрос ЗАРЕГИСТРИРОВАТЬ или только содержимое заголовка Контакта запроса ЗАРЕГИСТРИРОВАТЬ могут быть сохранены в S-CSCF. Таблица условий для маршрутизации к AS будет изменена, включая:

AS-poc; "требуемые возможности терминала" = '+g.poc.talkburst'.

Таблица условий для маршрутизации к AS может быть загружена как данные конфигурации, например, во время запуска S-CSCF или когда это необходимо, из локальной или общей базы данных, сервера, файла, таблицы и т.п.

Альтернативный пример организации этой таблицы:

"возможности терминала" = '+g.рос.talkburst'; позволить маршрутизацию к AS-рос.

6. При регистрации оборудования пользователя критерии фильтра не редактируют, а возможности терминала сохраняют при регистрации. Например, запрос ЗАРЕГИСТРИРОВАТЬ или только содержимое заголовка Контакта запроса ЗАРЕГИСТРИРОВАТЬ сохраняют в S-CSCF. Системные критерии фильтра, использованные для проверки маршрутизации к AS, организованы так:

Если метод = "INVIТЕ" и заголовок ="Accept-Contact" = "+g.poc.talkburst" и "возможности терминала" = '+g.poc.talkburst', тогда: НАПРАВИТЬ запрос к определенному вызываемому порту сервера РоС.

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

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

Фиг.8 иллюстрирует функциональную архитектуру элемента управления службой в соответствии с данным изобретением. Элемент управления службой является элементом сети, который содержит средства обработки 81 (элемент, который содержит арифметико-логическое устройство, определенное число специальных регистров и управляющих схем). К средству обработки подключено средство памяти 82 (носитель данных, где могут быть сохранены данные, читаемые компьютером, или программы, или данные пользователя). Средство памяти обычно включает устройство памяти, которое допускает как чтение, так и запись (RAM), и память, содержимое которой может быть только прочитано (ROM). Устройство также включает блок интерфейса 83 со средствами ввода 84, для ввода данных для внутренней обработки в устройстве, и средства вывода 85, для вывода данных после внутренней обработки в устройстве. Примеры указанных средств ввода включают подключаемое устройство, действующее как шлюз для информации, доставляемой к его внешним точкам подключения. Для приема информации от оператора элемента управления службой этот элемент может также содержать клавиатурную панель, сенсорный экран, микрофон и т.п. Примеры указанных средств вывода включают подключаемое устройство, подающее информацию на линии, подключенные к его внешним точкам подключения. Для вывода информации оператору элемента управления службой этот элемент может также содержать экран, сенсорный экран, громкоговоритель и т.п. Средства обработки 81, средства памяти 82 и блок интерфейса 83 электрически соединены вместе для обеспечения систематического выполнения операций над принятыми и/или сохраненными данными в соответствии с заранее заданными, в точности запрограммированными обработками устройства.

В описанной ранее реализации операции включают выполняемые функции для осуществления этапов управления службой, как описано выше. Средства памяти 82 выполнены с возможностью хранения пользовательских критериев фильтра в элементе, как минимум во время обработки запроса, ассоциированного с пользователем, элементом управления службой. Когда подобный запрос принят элементом управления службой через средства ввода 84, пользовательские критерии фильтра извлекаются из средства памяти 82 и сравниваются с данными, содержащимися в запросе. Если условия критериев фильтра совпадают, запрос перенаправляется к заданному AS через средства вывода 85. В соответствии с данным изобретением пользовательские критерии фильтра организованы так, чтобы была возможность проверки информации о динамических возможностях ассоциированного пользователя по использованию службы, предоставленной сервером приложений.

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

Передача информации о возможностях может быть организована несколькими путями, известными специалистам. Например, возможности оборудования пользователя могут быть указаны и с механизмом, описанным в IETF RFC3840, и/или через веб-страницу, и/или через Ut интерфейс между оборудованием пользователя и SIP-сервером приложений, и/или посредством конфигурирования подписки пользователя и/или профиля службы, и/или посредством соглашения, и/или посредством связи между оборудованием пользователя и элементом сети, и/или с помощью любого механизма и/или процедуры, включающей любое из следующего: пользователь, оператор и/или автоматическая (например, запрограммированная) процедура. При рассмотрении информации о возможностях некоторые явления могут отражаться на параметрах, относящихся к информации о возможностях, а также на том, как эти параметры могут быть переданы, например, тип носителя (например, речь, аудио, видео, текст), тип транспорта (например, в реальном времени, оффлайн, CS-транспорт, PS-транспорт), тип доступа (например, сотовый, WLAN, фиксированная широкополосная xDSL) и любые другие параметры (например, обмен сообщениями мультимедиа), и/или условия, и/или процедуры, и/или т.п.

Как дальнейший пример указанных выше механизмов далее приводится более конкретный пример таблицы условий для элемента управления службой, определяющей принципы управления маршрутизацией к AS. Этот пример представлен для описанной реализации, относящейся к службе РоС.

AS	Требуемые возможности