ПРЕДОСТАВЛЕНИЕ УСЛУГ В СИСТЕМЕ СВЯЗИ Российский патент 2009 года по МПК H04W4/02 

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

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

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

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

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

Примером услуг, предоставляемых системами связи абонентам, являются так называемые мультимедийные услуги. Системы связи, способные предоставлять мультимедийные услуги, иногда называют мультимедийными IP-сетями. Функциональные возможности IP-мультимедиа (IM) могут обеспечиваться посредством подсистемы базовой сети (CN) IP-мультимедиа или, кратко, подсистемы IP-мультимедиа (IMS). IMS содержит различные сущности для предоставления мультимедийных услуг.

Системы связи развивались в направлении, в котором различные сетевые функции предоставления услуг находятся под управлением сетевых сущностей, именуемых серверами. Например, в современных архитектурах беспроводной мультимедийной сети третьего поколения (3G) предполагается, что несколько разных серверов используются для управления разными функциями. Эти функции включают в себя функции управления сеансом вызова (CSCF). Функции управления сеансом вызова можно разделить на несколько категорий, например посредническую функцию управления сеансом вызова (P-CSCF), опрашивающую функцию управления сеансом вызова (I-CSCF) и обслуживающую функцию управления сеансом вызова (S-CSCF). Очевидно, что иногда CSCF можно относить к функциям управления состоянием вызова или функциям управления сервером вызова.

Обслуживающая функция управления сеансом вызова образует сущность, на которой абоненту необходимо зарегистрироваться, чтобы иметь возможность запрашивать услугу у системы связи. Обслуживающую функцию управления сеансом вызова можно дополнительно подразделить на начинающую функцию управления сеансом вызова (O-CSCF) и оканчивающую функцию управления сеансом вызова (T-CSCF) на начинающем и оканчивающем концах сеанса. Помимо обслуживающей сущности управления, пользователю может потребоваться быть связанным с посреднической сущностью управления, например, P-CSCF. Посредническая сущность может быть назначена области, где обслуживается пользователь.

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

Сервер приложений (СП) - это сущность, предназначенная для предоставления пользователям дополнительных услуг IM. Сервер приложений может размещаться в собственной сети пользователя. Сервер приложений, альтернативно, может быть внешним по отношению к собственной сети пользователя и обеспечиваться услугой третьей стороны. Третья сторона может представлять собой другую сеть или просто автономный сервер приложений. Сервер приложений может оказывать влияние на сеанс передачи данных со стороны услуг, поддерживаемых сетью оператора. Сервер приложений может вмещать в себя и выполнять услуги. Примеры серверов приложений включают в себя серверы приложений протокола инициирования сеанса (SIP), серверы приложений открытого доступа к услуге (OSA) и специализированные приложения для функций коммутации услуг IP-мультимедиа с усовершенствованной логикой (CAMEL IM-SSF).

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

Таким образом, начинающие сеансы/транзакции следует рассматривать как сеансы/транзакции, которые нормально начинаются пользовательским оборудованием пользователя или сетевой сущностью со стороны пользователя. Оканчивающие сеансы/транзакции - это сеансы/транзакции, которые нормально оканчиваются пользовательским оборудованием пользователя или сетевой сущностью со стороны пользователя.

Например, стандарты для сетей IMS 3GPP (проект сотрудничества по третьему поколению) выпуск 5 (Rel-5) задают правила, как пользовательское оборудование (ПО) может начинать сеансы и единичные транзакции. Однако правила, приведенные в Rel-5, сосредоточены только на том, как применять так называемые критерии начинающей фильтрации. Выпуск 5 не позволяет третьей стороне начинать сеанс или транзакцию со стороны пользователя. Выпуск 6 стандартов 3GPP требует, чтобы сервер приложений (СП) имел возможность посылать запросы протокола инициирования сеанса (SIP) со стороны пользовательского оборудования через интерфейс ISC (Управление мультимедийными IP-услугами) на S-CSCF. Однако даже современный выпуск 6 стандартов 3GPP не обеспечивает никакого механизма для сервера приложений (СП), позволяющего серверу приложений это делать, иначе чем в исключительных случаях, когда запросы, исходящие от сервера приложений, непосредственно возбуждаются запросами, исходящими от пользовательского оборудования. Поэтому сервер приложений по-прежнему не способен выполнять услуги, которые генерируют запросы SIP или другой запрос со стороны пользователя.

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

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

Например, когда S-CSCF принимает сообщение, она должна иметь возможность принимать решение, как обрабатывать сообщение. В современных системах S-CSCF может применять к сообщению критерии фильтрации, именуемые «начинающая фильтрация» и «оканчивающая фильтрация». Термин «критерии фильтрации» (КФ) означает информацию, которая задает соответствующие триггеры точки обслуживания (SPT) для конкретного приложения услуги. В среде связи SIP критерии фильтрации задают подмножество запросов SIP, принимаемых S-CSCF, которые следует посылать или передавать через посредника на конкретное приложение услуги. S-CSCF может принимать критерии фильтрации от собственного сервера абонента (ССА) или сервера приложений (СП).

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

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

Раскрытие изобретения

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

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

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

сущность управления связью, способная обслуживать пользователя системы связи,

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

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

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

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

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

Первая сущность может генерировать начинающий запрос со стороны пользователя.

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

Первая сущность может выбрать порт, куда должен быть отправлен запрос.

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

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

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

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

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

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

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

фиг. 1 - система связи, в которой может быть реализовано изобретение;

фиг. 2 - вариант осуществления настоящего изобретения;

фиг. 3 и 4 - другие варианты осуществления;

фиг. 5 - логическая блок-схема предоставления услуги посредством вариантов осуществления.

Осуществление изобретения

Рассмотрим фиг. 1, где показана мультимедийная IP-сеть, в которой можно реализовать настоящее изобретение. IP-мультимедийные услуги могут предоставляться абонентам мультимедийной IP-сети. Функциональные возможности IP-мультимедиа (IM) могут обеспечиваться посредством подсистемы базовой сети (CN), содержащей различные сущности для предоставления услуги.

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

В показанной компоновке базовая станция 11 обеспечивает сущность доступа сети сотовой связи. Сетью 11 радиодоступа управляет соответствующий контроллер (для ясности не показан). Контроллер может быть обеспечен для каждой базовой станции, или контроллер может управлять совокупностью базовых станций. Известны также решения, в которых контроллеры обеспечены как на отдельных базовых станциях, так и на уровне сети радиодоступа для управления совокупностью базовых станций. Таким образом, очевидно, что название, местоположение и количество контроллеров сети доступа зависит от системы. Например, в наземной сети радиодоступа UMTS (UTRAN) может использоваться узел контроллера, именуемый контроллером радиосети (КРС). В GSM и CDMA2000 сущность, соответствующая контроллеру радиосети, называется контроллером базовой станции (КБС).

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

Базовая станция 11 предназначена для передачи сигналов на мобильное пользовательское оборудование 10 мобильного пользователя, т.е. абонента, и приема сигналов от него через беспроводной интерфейс. Соответственно, мобильное пользовательское оборудование 10 способно передавать сигналы на базовую станцию и принимать сигналы от нее через беспроводной интерфейс. Мобильный пользователь может использовать любое подходящее мобильное устройство, приспособленное для связи по интернет-протоколу (IP) для подключения к сети. Например, мобильный пользователь может осуществлять доступ к сотовой сети посредством персонального компьютера (ПК), карманного персонального компьютера (КПК), мобильной станции (МС) и т.д. Следующие примеры описаны применительно к мобильным станциям.

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

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

В современных архитектурах беспроводной мультимедийной IP-сети третьего поколения (3G) предполагается, что несколько разных серверов используются для управления разными функциями. Эти функции включают в себя функции управления сеансом вызова (CSCF). Функции управления сеансом вызова можно разделить на несколько категорий, например посредническую функцию 12 управления сеансом вызова (P-CSCF), опрашивающую функцию 24 управления сеансом вызова (I-CSCF) и обслуживающую функцию 14 управления сеансом вызова (S-CSCF).

Обслуживающая функция 14 управления сеансом вызова образует сущность, на которой регистрируется абонент 10. Регистрация необходима, чтобы иметь возможность запрашивать услугу у системы связи. Пользователь может регистрироваться через сущность доступа системы связи, например базовую станцию 11. Обслуживающую функцию 14 управления сеансом вызова можно рассматривать как обеспечивающую начинающие функции управления сеансом вызова (O-CSCF) и оканчивающие функции управления сеансом вызова (T-CSCF) на начинающем и оканчивающем концах сеанса или транзакции.

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

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

Сервер 22 приложений, взаимодействующий с собственным сервером 20 абонента (ССА) и обслуживающей функцией 14 управления сеансом вызова (S-CSCF), также известен. В общем случае, сервер приложений можно рассматривать как сущность, которая вмещает в себя услугу(и), доступную(ые) в сеансах/транзакциях в соответствии с подпиской пользователя. Маршрутизация на сервер приложений может осуществляться в результате оценивания критерия фильтрации, который связан с подпиской пользователя.

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

Когда сервер 22 приложений начинает сеанс или транзакцию, посылая сообщение на S-CSCF 14, S-CSCF 14 должна принять решение, в какой роли действовать. Если S-CSCF 14 выбирает действовать в начинающей роли, то S-CSCF применяет критерии начинающей фильтрации ко входящему сообщению. В оканчивающей роли S-CSCF оценивает критерии оканчивающей фильтрации. Ниже будут рассмотрены различные способы реализации выбора. В зависимости от роли S-CSCF может затем построить адрес услуги, который она возвращает на P-CSCF в ответ на сообщение регистрации. Затем P-CSCF должна использовать этот адрес при пересылке сообщений на S-CSCF.

Предпочтительно, чтобы S-CSCF 14 передавала в ходе регистрации на ССА 20 адрес, который должен использоваться при окончании сеансов или транзакций. Согласно предпочтительному варианту осуществления, показанному на фиг.2, сервер 14 приложений принимает от ССА 20 информацию адреса, относящуюся к S-CSCF 14, на которой регистрируется пользовательское оборудование 10. Информация адреса может предоставляться по запросу, например по интерфейсу Sh между сущностями, см. этап 1 фиг.2. Информация адреса может иметь вид любой подходящей информации, например имени S-CSCF или URI (универсального идентификатора ресурсов) S-CSCF.

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

На фиг.2 сервер 20 приложений обозначен номером этапа 2 как ответственный за конфигурацию информации адреса. В частности, сервер 22 приложений может изменять информацию адреса, чтобы абоненту предоставлялся соответствующий тип услуги. Например, сервер 20 приложений может изменить имя услуги, чтобы построить правильный адрес для нужной услуги. Имя S-CSCF можно изменить, например, добавив параметры указателя "term" или "orig" в качестве префикса к имени, принятого от ССА. Например, адрес

scscf12.operator.net имя

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

orig.scscf12.operator.net или

term.scscf12.operator.net

На этапе 3 происходит разрешение адреса с помощью DNS (системы доменных имен) 26 для получения IP-адреса соответствующей услуги.

В зависимости от изменения адрес направляет сообщения на начинающую или оканчивающую услугу. Таким образом, сервер 22 приложений снабжается средством, посредством которого он может маршрутизировать сообщение запроса услуги либо на начинающую услугу, либо на оканчивающую услугу на этапе 4. Как показано на фиг.1, это может происходить на интерфейсе ISC (управления мультимедийными IP-услугами).

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

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

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

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

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

xx44@scscf7.operator.net

Если сервер 22 приложений собирается начать оканчивающий/ую сеанс/транзакцию, то он использует вышеупомянутый адрес как он есть, чтобы сигнализировать целевой S-CSCF 14, что S-CSCF должна действовать в роли оканчивающего/ей сеанса/транзакции. В обычном режиме работы это означает, что S-CSCF 14 должна применять критерии оканчивающей фильтрации при оценивании входящих сообщений.

Если сервер 22 приложений намеревается начать начинающий/ую сеанс/транзакцию, то он изменяет адрес. Для этого можно добавить в адрес новый параметр «роль». Таким образом, измененный адрес, включающий в себя параметр роли role=orig, может, например, иметь вид

xx44@scscf7.operator.net;role=orig

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

Адрес S-CSCF можно конфигурировать на сервере 22 приложений, где требуется адрес. Альтернативно, адрес можно конфигурировать на всех серверах приложений. Последняя альтернатива может иметь преимущество, например, в случаях, когда не существует интерфейса Sh от сервера приложений 22 к собственному серверу абонента 20 или когда интерфейс временно недоступен.

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

Возможность для построения адреса состоит в том, что параметр хранится на ССА 20 совместно с адресом S-CSCF 14. Затем сервер 22 приложений может построить правильный адрес, используя информацию адреса и параметра из ССА в качестве входных данных процесса изменения.

Согласно возможности, показанной на фиг.3, сервер 22 приложений делает запрос DNS (системе доменных имен) на основании информации адреса, возвращенной от САА на этапе 1. Возвращенное имя S-CSCF можно использовать для запрашивания, например, записей ресурсов SRV для отыскания адреса и порта, где доступна нужная услуга (начинающая или оканчивающая). SRV - это записи ресурсов (RR) DNS для указания местонахождения услуг (DNS SRV). Использование записей ресурсов SRV позволяет запрашивать конкретную услугу и/или протокол для конкретного домена. Тогда ответ будет включать в себя имя любого доступного сервера, отвечающего критериям.

Например, можно сделать следующий запрос DNS из записей ресурсов SRV, когда следует оценивать критерии начинающей фильтрации. В записи ресурсов SRV обычно указаны протокол и услуга. Записи SRV можно запрашивать на этапе 2, например, используя в качестве аргумента следующий адрес:

_orig._sip.scscf12.operator.net

Ответом на этапе 2 может быть советом маршрутизировать по указанному адресу "orig.scscf12.operator.net" с использованием порта 5060:

_orig._sip.scscf12.operator.net SRV 0 0 5060 orig.scscf12.operator.net.

Альтернативно, ответом может быть маршрутизация на указанный порт 55334 с исходным адресом "scscf12.operator.net":

_orig._sip.scscf12.operator.net SRV 0 0 55334 scscf12.operator.net.

Следующий аргумент можно использовать в запросе DNS (SRV), когда следует оценивать критерии оканчивающей фильтрации:

_term._sip.scscf12.operator.net.

Ответом может быть совет маршрутизировать по указанному адресу "term.scscf12.operator.net" с использованием порта 5060:

_term._sip.scscf12.operator.net SRV 0 0 5060 term.scscf12.operator.net.

Или, как выше, ответом может быть, например, маршрутизация на указанный порт 55335 с исходным адресом "scscf12.operator.net":

_term._sip.scscf12.operator.net SRV 0 0 55335 scscf12.operator.net.

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

Затем сервер приложений может разрешить адрес с помощью DNS на этапе 3 и маршрутизировать на этапе 4 сообщения по указанному адресу и/или на указанный порт.

Согласно другой возможности база данных абонентов (например, ССА 20) возвращает на этапе 1 имя S-CSCF. Затем сервер приложений делает запрос DNS с помощью возвращенного имени S-CSCF на предмет записей ресурсов NAPTR (указателя службы присвоения имен) для отыскания доступных услуг (начинающих и/или оканчивающих). На основании ответа сервер приложений может маршрутизировать сообщение запроса по нужному адресу. Этот вариант осуществления позволяет использовать DNS для поиска услуг для широкого диапазона имен ресурсов, которые не соответствуют синтаксису имен домена. Возможные имена ресурсов включают в себя URI услуг.

Ниже приведен пример запроса NAPTR с помощью SRV. Запрос DNS можно делать, спрашивая записи ресурсов (RR) NAPTR с использованием доменной части адреса S-CSCF, например

scscf12.operator.net

В результате может получиться:

IN NAPTR 100 10 "S" "sip+orig" ""_orig._sip.scscf12.operator.net.

IN NAPTR 100 10 "S" "sip+term" "" _term._sip.scscf12.operator.net.

Поскольку поля порядка и предпочтения равны, можно выбрать любую из RR. Если необходим адрес для S-CSCF для начинающих сеансов/транзакций, можно выбрать первый адрес. Флаг "S" указывает, что следующий запрос DNS будет сделан на предмет RR SRV. Затем можно сделать запрос DNS на предмет RR SRV с помощью доменного имени, т.е. вышеупомянутого адреса

_orig._sip.scscf12.operator.net.

Результатом запроса DNS может быть IP-адрес или любая другая подходящая информация маршрутизации.

Возможно также реализовать NAPTR без запроса SRV. Как и выше, запрос DNS можно сделать на предмет RR NAPTR с использованием доменной части адреса S-CSCF, например

scscf12.operator.net

В результате может получиться

IN NAPTR 100 10 "A" "sip+orig" "" orig.scscf12.operator.net.

IN NAPTR 100 10 "A" "sip+term" "" term.scscf12.operator.net.

Поскольку поля порядка и предпочтения равны, можно выбрать любую из RR. Если необходим адрес для S-CSCF для начинающих сеансов/транзакций, можно выбрать первую. Флаг "A" указывает, что следующий запрос DNS делается на предмет записей ресурсов A, AAAA или A6 SRV. Затем можно сделать запрос DNS на предмет RR A, AAAA или A6 с доменным именем orig.scscf12.operator.net. В результате запроса будет получен IP-адрес.

Согласно первой альтернативе запрос DNS, сделанный на предмет RR NAPTR с использованием доменной части адреса S-CSCF (например, scscf12.operator.net), может дать следующий результат:

IN NAPTR 100 10 "U" "sip+orig" "!(^.$)!sip:orig.\1!".

IN NAPTR 100 10 "U" "sip+term" "!(^.$)!sip:term.\1!".

Преимущество этой альтернативы в том, что все S-CSCF обычно имеют общие записи ресурсов NAPTR. Поскольку поля порядка и предпочтения равны, можно выбрать любую из RR и таким образом можно выбрать первую для начинающего/ей сеанса/транзакции. Флаг "U" указывает, что результатом будет URI. Тогда результат может иметь вид

sip:orig.scscf 12.operator.net.

Доменная часть URI разрешается до IP-адреса посредством запроса DNS. Запрос DNS можно делать на предмет RR A, AAAA или A6 с помощью доменного имени, и результатом будет IP-адрес.

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

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

scscf12.operator.net,

добавив тег, символ, строку символов или строку битов в качестве пользовательской части, строя таким образом адрес для начинающей услуги (или наоборот):

orig@scscf12.operator.net

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

Однако в ССА возможно хранить два адреса (т.е. адрес для начинающей и адрес для оканчивающей роли) S-CSCF. Таким образом, согласно другому варианту осуществления, показанному на фиг.4, в собственном сервере 20 абонента (ССА) хранятся более одного адреса для S-CSCF.

В частности, ССА 20 может хранить один адрес S-CSCF для запуска критериев начинающей фильтрации и другой для запуска критериев оканчивающей фильтрации. Затем сервер 22 приложений может извлекать нужный адрес через интерфейс Sh, когда ему нужно действовать со стороны пользовательского оборудования 10. Альтернативно, сервер 22 приложений может извлекать оба адреса и выбирать тот, который ему нужен. Это является вопросом реализации.

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

На фиг.5 показана возможность предоставления услуг посредством вышеописанных вариантов осуществления. Для этапов 1, 2 и 4, см. вышеописанные варианты осуществления на фиг. 2 и 3. На этапе 5 услуга предоставляется по запросу на услугу, поступающему от пользователя.

В вышеописанной иллюстративной среде связи расширение до существующих интерфейсов Sh может потребоваться для вытягивания адреса начинающей S-CSCF из ССА на сервер приложений. Это можно обеспечить посредством расширения до запроса Sh-pull для включения информационного элемента «имя S-CSCF». Аналогично, расширение до интерфейса Cx между ССА 20 и S-CSCF 14 может потребоваться для проталкивания информации адреса начинающей S-CSCF из S-CSCF 14 на ССА 20.

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

Конфигурация может быть такова, что в ходе регистрации пользовательского оборудования для IP-мультимедийных услуг S-CSCF может проталкивать их адрес для начинающих запросов на ССА через интерфейс Cx. Запросы извещения регистрации и/или отмены регистрации Cx:S-CSCF можно расширить так, чтобы они содержали адреса начинающей S-CSCF и оканчивающей S-CSCF.

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

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

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

Очевидно, что, хотя пользователь может косвенно обуславливать предоставление начинающей или оканчивающей услуги, ответственность за манипулированием адресом или именем обслуживающей сущности управления связью (например, S-CSCF) лежит на сервере приложений. Таким образом, пользователь не обращается напрямую к обслуживающей сущности управления связью. Таким образом, сервер приложений может принимать информацию, относящуюся к сущности управления связью, способной обслуживать пользовательское оборудование, из различных источников. Помимо сущностей хранения, например базы данных абонентов (например, ССА) или внутренней базы данных сервера приложений, сервер приложений может также получать имя или адрес обслуживающей сущности управления связью из сообщения, принятого от обслуживающей сущности управления связью или любой другой сетевой сущности. Такое сообщение может представлять собой, например, предыдущий запрос, оканчивающийся сервером приложений.

Возможно также, что сервер приложений получает список адресов обслуживающих сущностей управления связью от ССА или из другой базы данных. Тогда СП может выбрать из списка правильный. Это может быть полезной возможностью, например, когда пользователь вовсе не зарегистрирован, и на ССА не существует доступных адресов S-CSCF. Тогда СП может извлечь адрес из списка S-CSCF, принятых по умолчанию. В этом случае ССА может затем возвращать только возможности. На основании этой информации СП может выбрать правильную S-CSCF.

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

Вариант осуществления настоящего изобретения был описан применительно к системе мобильной связи третьего поколения, например универсальной системе мобильной связи (UMTS), i-phone или CDMA2000 и общеевропейской системе транковой связи (TETRA). Кроме того, данные примеры описаны применительно к так называемым полностью SIP-овым сетям с полностью SIP-овыми сущностями. Это изобретение также применимо к любым другим подходящим системам связи, беспроводным либо стационарным системам и стандартам и протоколам. Примеры других возможных систем связи, обеспечивающих услуги беспроводной передачи данных, помимо вышеупомянутых, включают в себя общую услугу пакетной радиосвязи (GPRS), мобильную сеть передачи данных с увеличенной скоростью передачи данных для развития GSM (EDGE) и различные приложения беспроводных локальных сетей (W-LAN). Примеры стационарных систем включают в себя различные широкополосные технологии, обеспечивающие доступ к Интернету для пользователей в разных местах, например дома и в учреждениях. Независимо от стандартов и протоколов, используемых для сети связи, изобретение можно применять во всех сетях связи, где сетевые сущности можно сделать способными начинать сеансы или транзакции.

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

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

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

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

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

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

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

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

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

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

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

6. Способ по п.1, в котором сетевой объект добавляет указатель типа услуги в первоначальный запрос.

7. Способ по п.6, в котором указатель типа услуги включают в адрес объекта управления связью.

8. Способ по п.7, в котором указатель типа услуги включают в пользовательскую часть адреса.

9. Способ по п.7, в котором указатель типа услуги включают в доменную часть адреса.

10. Способ по п.1, в котором сетевой объект выбирает порт, куда должен быть отправлен запрос.

11. Способ по п.1, в котором информация, принятая от объекта хранения, содержит универсальный идентификатор ресурса (URI) объекта управления связью.

12. Способ по п.1, в котором информация, принятая от объекта хранения, содержит параметр указателя типа услуги.

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

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

15. Способ по п.13, в котором сетевой объект запрашивает записи ресурсов указателя службы присвоения имен (NAPTR) для отыскания доступных услуг.

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

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

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

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

20. Способ по п.1, в котором в первоначальном запросе указаны критерии фильтрации, подлежащие применению к запросу.

21. Способ по п.1, в котором сетевой объект является сервером приложений.

22. Способ по п.1, в котором объект управления связью содержит обслуживающую функцию управления сеансом вызова.

23. Способ по п.1, в котором объект хранения содержит объект хранения пользовательской информации.

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

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

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

27. Система связи по п.26, в которой указатель типа услуги включен в адрес объекта управления связью.

28. Система связи по любому из пп.25-27, которая содержит базу данных для хранения информации, относящейся к услуге.

29. Система связи по п.28, в которой база данных содержит систему доменных имен.

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

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

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

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

34. Сетевой объект по п.33, который является одним из шлюза, сервера, прокси-сервера, клиента или пользовательского агента.

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

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

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

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

39. Способ по п.37 или 38, в котором первоначальный запрос содержит указатель типа услуги.

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

41. Способ по любому из пп.37-40, в котором в первоначальном запросе указаны критерии фильтрации, подлежащие применению к запросу.

42. Способ по любому из пп.37-40, в котором сетевой объект содержит сервер приложений и объект управления связью содержит обслуживающую функцию управления сеансом вызова.

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

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

45. Устройство по любому из пп.43 или 44, в котором процессор приспособлен применять критерии фильтрации, основываясь на указателе в первоначальном запросе.

46. Устройство по любому из пп.43-45, в котором объект управления связью содержит обслуживающую функцию управления сеансом вызова.