СПОСОБ, УСТРОЙСТВО И СИСТЕМА ДЛЯ РЕАЛИЗАЦИИ СЕРВИСА ОВЕРРАЙДА ПРИ ЭКСТРЕННОМ ВЫЗОВЕ Российский патент 2014 года по МПК H04L29/00 

Область применения

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

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

Употребляемые в настоящем описании сокращения означают:

HSS (Home Subscriber Server) - главный сервер абонентов;

OSA (Open Service Architecture) - открытая архитектура сервисной среды;

IMS (IP Multimedia Subsystem) - мультимедийная подсистема, использующая Интернет-протокол;

SIP (Session Initiation Protocol) - протокол инициации сеанса связи;

AS (Application Server) - сервер приложений;

ISC (IP multimedia Service Control) - управление мультимедийными сервисами по Интернет-протоколу;

SCS (Server Capability Server) - сервер с возможностью оказания сервисов;

SCIM (Service Capability Interaction Manager) - устройство управления взаимодействиями при оказании сервисов;

CAMEL (Customized Applications for Mobile Network Enhanced Logic) -специализированные приложения для расширенной логики сетей мобильной связи;

CAP (CAMEL Application Part) - часть приложений, относящаяся к CAMEL;

MAP (Mobile Application Part) - мобильная часть приложений;

IM-SSF (IP Multimedia Service Switching Function) - функция коммутации мультимедийных сервисов по Интернет-протоколу;

P-CSCF (Proxy Call Session Control Function) - прокси-функция управления сенсами связи;

S-CSCF (Serving Call Session Control Function) - функция управления сеансами связи, связанными с оказанием сервисов;

Sh - базовая точка связи между HSS и AS;

Si - базовая точка связи между HSS и IM-SSF;

Сх - базовая точка связи между HSS и S-CSCF.

IMS (IP Multimedia Subsystem) - мультимедийная подсистема, использующая Интернет-протокол, которая является ключевой технологией сети следующего поколения, обеспечивает универсальную платформу для обслуживания абонентов, поддерживающую различную мультимедийные приложения. Подсистема IMS содержит различные функции, такие как управление сервисными функциями (связанными с оказанием сервисов пользователям), функции безопасности, такие как аутентификация и авторизация, выставление счетов, маршрутизация, регистрация, сжатие SIP-сообщений, поддержка Qos и прочие. IMS независима от сети доступа, и IMS-терминалы поддерживают SIP-протокол. IMS-терминалы являются «высокоинтеллектуальными» и позволяют быстро развивать оказываемые через них различные сервисы. Более того, подсистема IMS при поддержке пакетно-коммутируемой сети имеет такое важное преимущество, как поддержка сервисов, связанных с передачей данных.

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

1) сервер приложений, работающий по SIP-протоколу (SIP-AS);

2) сервер с возможностью оказания сервисов, имеющий открытую архитектуру (OSA-SCS);

3) сервер приложений CAMEL (сервер IM-SSF), обеспечивающий функцию коммутации мультимедийных сервисов по Интернет-протоколу.

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

Обычно сервис оверрайда при экстренном вызове реализуется в CS-домене (домене канальной коммутации). В этом смысле сервис оверрайда при экстренном вызове является сервисом центрального обменного устройства (IP Centrex) в сети с программной коммутацией.

Как показано на фиг.2, в соответствии существующими типами архитектуры программной коммутации процесс реализации сервиса оверрайда при экстренном вызове содержит следующие основные этапы:

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

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

S203: после выполнения последовательности операций, связанных с оказанием данного сервиса, программный коммутатор посылает первичный запрос-приглашение на терминал В.

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

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

А именно в сетевой архитектуре IMS управление сеансами связи, связанными с предоставлением сервисов, осуществляет функция управления S-CSCF; а заключительную обработку логических операций, связанных с установлением мультимедийной голосовой связи и предоставлением пользователю дополнительных сервисов, осуществляет сервер приложений, работающий по SIP-протоколу. Что касается мультимедийной голосовой связи, S-CSCF включает соответствующий сервер приложений с помощью механизма запуска iFc, чтобы при этом реализовать тот или иной сервис. Чтобы полностью обработать вызов, то есть установить сеанс связи между двумя сторонами, S-CSCF необходимо запустить серверы приложений дважды: в первый раз - сервер приложения на вызывающей стороне, чтобы сервер приложения на вызывающей стороне завершил последовательность логических операций, связанных с обслуживанием вызывающей стороны; и второй раз - сервер приложения на вызываемой стороне, чтобы сервер приложения на вызываемой стороне завершил последовательность логических операций, связанных с обслуживанием вызываемой стороны. Как показано на фиг.3, на этапе 303, когда сервер приложения на вызывающей стороне завершает последовательность логических операций обслуживания вызывающей стороны, сервер приложения на вызывающей стороне посылает первичный запрос-приглашение к установлению вызова на S-CSCF. При этом информация о коде доступа к сервису удалена, потому что сервер приложения на вызывающей стороне должен преобразовать номер вызываемого абонента в специальный формат для глобальной маршрутизации вызова (SIP URI или TEL URI) и глобального определения S-CSCF, обслуживающей вызываемого абонента, в соответствии с номером вызываемого абонента; и по этой причине сервер приложений на вызывающей стороне не может сообщить серверу приложения на вызываемой стороне о наличии у вызывающего абонента права на сервис оверрайда. Как показано на фиг.3, на этапе 305, когда сервер приложения на вызываемой стороне получил сигнал запуска от S-CSCF, он не может определить, имеет ли вызывающая сторона право на оверрайд, и является ли вызов, совершаемый вызывающей стороной, экстренным вызовом, требующим оверрайда. Может быть, например, исполнена последовательность логических операций «не беспокоить» или сделана переадресация вызова, то есть право вызывающей стороны на оверрайд не будет реализовано.

Как показано на фиг.3, последовательность операций по обработке простого вызова в сетевой архитектуре IMS содержит следующие основные этапы:

S301: пользователь А посылает на свою S-CSCF первичный запрос-приглашение «INVITE» в виде SIP-сообщения.

S302: после получения запроса S-CSCF вызывающей стороны вычисляет из данного запроса код запуска сервиса (SPT) и проверяет, удовлетворяет ли вычисленный код SPT критерию фильтрации X; если он удовлетворяет, то S-CSCF пересылает запрос на сервер приложений AS-A вызывающей стороны.

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

S304: после получения SIP-сообщения с запросом от AS-A, S-CSCF вызывающей стороны проводит поиск S-CSCF вызываемой стороны и пересылает данный запрос на S-CSCF вызываемой стороны.

S305: после получения запроса S-CSCF вызываемой стороны вычисляет из данного запроса код SPT и проверяет, удовлетворяет ли данный код SPT критерию фильтрации Y; если он удовлетворяет, то S-CSCF пересылает запрос на сервер приложений AS-B вызываемой стороны.

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

S307: S-CSCF на вызываемой стороне проверяет SIP-сообщение с запросом, полученное от AS-B, и определяет, что данный запрос не удовлетворяет ни одному из критериев фильтрации; после этого S-CSCF вызываемой стороны проводит поиск следующего перегона в соответствии со стандартным механизмом маршрутизации SIP-сообщений и и посылает по нему данное SIP-сообщение с запросом.

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

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

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

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

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

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

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

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

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

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

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

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

Фиг.1. Схема структуры сервисной среды в сети IMS в соответствии с существующим уровнем техники.

Фиг.2. Схема последовательности операций при оказании сервиса оверрайда при экстренном вызове в системе с программным коммутатором в соответствии с существующим уровнем техники.

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

Фиг.4. Общая схема способа реализации сервиса оверрайда при экстренном вызове в соответствии с воплощением настоящего изобретения.

Фиг.5. Подробная схема способа реализации сервиса оверрайда при экстренном вызове в соответствии с воплощением настоящего изобретения.

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

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

Фиг.8. Система для реализации сервиса оверрайда в соответствии с одним из воплощений настоящего изобретения.

Подробное описание изобретения

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

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

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

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

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

S404: первый сервер приложений реализует сервис оверрайда в соответствии с идентификатором сервиса.

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

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

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

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

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

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

Этап А: после получения первичного сообщения-запроса сервер приложений вызывающей стороны удаляет код доступа к сервису оверрайда при экстренном вызове в строке "Requestline" сообщения и посылает данное сообщение, с удаленным кодом доступа к сервису на S-CSCF. Сообщение, посланное на S-CSCF, имеет заголовок "Р-Asserted-Service" и идентификатор сервиса задан как "urn: 3gpp:mmtel.eco.version1", что означает, что требуется сервис оверрайда при экстренном вызове. После этого на сервер приложений вызываемой стороны высылается первичное сообщение-запрос.

Этап В: сервер приложений, к которому подключена вызываемая сторона, получает первичное сообщение-запрос с заголовком "P-Asserted-Service" и идентификатором сервиса "urn: 3gpp:mmtel.eco.version1", удаляет заголовок и посылает вызов на S-CSCF, и не выполняет последовательности логических операций передачи вызова, переадресации вызова, «не беспокоить» и прочих.

Кроме того, до этапа А вызывающий терминал инициирует первичное сообщение-запрос для построения вызова. Строка "Requestline" в SIP-сообщении несет код сервиса оверрайда при экстренном вызове и информацию о номере вызываемого абонента.

При получении вызова от вызывающей стороны S-CSCF на вызывающей стороне прозрачным образом передает код сервиса и информацию о вызываемой стороне в строке "Requestline" сообщения в процессе запуска сервера приложений на вызывающей стороне.

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

Кроме того, на этапе А серверу приложений вызывающей стороны необходимо проанализировать содержимое заглавной строки "Requestline" в последовательности SIP-сигналов и определить, является ли текущий вызов, инициированный вызывающей стороной, экстренным вызовом, требующим сервиса оверрайда.

Более того, до выполнения этапа В, S-CSCF на вызываемой стороне добавляет заголовок "P-Asserted-Service" и информацию о том, что идентификатором сервиса является "urn: 3gpp:mmtel.eco.version1" в информацию о сервисах, на которые имеется подписка у вызываемой стороны.

В соответствии с настоящим изобретением используется заголовок "P-Asserted-Service" и устанавливается идентификатор сервиса "urn: 3gpp:mmtel.eco.version1" для обозначения того, что пользователю открыт сервис оверрайда при экстренном вызове.

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

Ниже на ряде примеров подробно описана последовательность операций для реализации способа в соответствии с настоящим изобретением.

БНФ заголовка «P-Asserted-Service» имеет вид и рассчитывается следующим образом:

PAssertedService="P-Asserted-Service" HCOLON PAssertedService-value

PAssertedService-value=Service-ID *(COMMA Service-ID)

Service-ID="urn:xxx:" urn-service-id

urn-service-id=top-level *("." sub-service-id) *("-"application-id)

top-level=let-dig [*26 let-dig]

sub-service-id=let-dig [*let-dig]

let-dig=ALPHA/DIGIT

Параметр «Service-ID» (идентификатор сервиса) в соответствии с настоящим изобретением имеет расширение "ххх", при этом "ххх" задается как "3gpp"; "urn-service-id" задается как "mmtei.eco.version1", что обозначает сервис оверрайда при экстренном вызове.

Так, например, содержимое заголовка «P-Asserted-Service» задается следующим образом:

P-Asserted-Service: urn: 3gpp:mmtel.eco.version1

Способ в соответствии с настоящим изобретением реализуется следующим образом. Допустим, что терминал А (вызывающая сторона) имеет подписку на сервис оверрайда при экстренном вызове, терминал В (вызываемая сторона) имеет подписку на сервисы передачи вызова, «не беспокоить», переадресация вызова и прочие.

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

S501: терминал А вызывающей стороны вызывает вызываемую сторону путем набора кода сервиса оверрайда при экстренном вызове перед набором номера вызываемой стороны. Другими словами, в строке "Requestline" первичного сообщения-запроса приглашения содержится код сервиса оверрайда при экстренном вызове и информация о номере вызываемой стороны.

S502: S-CSCF стороны А получает первичное сообщение-запрос приглашения (далее именуется также первичным сообщением-запросом) и запускает сервер приложений вызывающей стороны А в соответствии с правилом запуска iFc; это означает, что на сервер приложений вызывающей стороны А высылается первичное сообщение-запрос приглашения.

S503: Сервер приложений стороны А получает первичное сообщение-запрос приглашения, и если он определяет, что код сервиса, указанный в строке "Requestline", соответствует коду доступа, выделенному для сервиса оверрайда при экстренном вызове (такой код выделяется данному сервису заранее и сообщается пользователю, подписывающемуся на данный сервис), то есть что пользователь хочет воспользоваться сервисом оверрайда при экстренном вызове, сервер приложений стороны А удаляет код доступа к сервису оверрайда при экстренном вызове из строки "Requestline" сообщения и посылает такое же сообщение, но с удаленным кодом доступа к сервису оверрайда при экстренном вызове, на S-CSCF стороны А. При этом отправленное сервером на S-CSCF стороны А сообщение несет идентификатор сервиса оверрайда при экстренном вызове, например P-Asserted-Service: urn:3gpp:mmtel.eco.version1, что означает, что вызывающая сторона А запрашивает выполнение функции оверрайд при экстренном вызове. Предпочтительно, чтобы идентификатор сервиса оверрайда был вставлен в заголовок сообщения-запроса.

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

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

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

S507: после получения первичного сообщения-запроса приглашения, сервер приложения на стороне В проверяет, несет ли сообщение идентификатор сервиса оверрайда при экстренном вызове, например, P-Asserted-Service: urn:3gpp:mmtel.eco.version1, чтобы определить, инициирует ли терминал А вызывающей стороны сервис оверрайда при экстренном вызове. При этом, если идентификатор сервиса вставлен в заголовок сообщения-запроса, то проверяется заголовок сообщения-запроса; если будет определено, что запрашивается оверрайд при экстренном вызове, то сервер приложений на стороне В удаляет идентификатор сервиса, и не выполняет логическую последовательность операций по функциям передачи вызова или «не беспокоить», на которые имеется подписка у вызываемой стороны; после этого сервер приложений на стороне В посылает первичное сообщение-запрос, с удаленным из него идентификатором сервиса, функции S-CSCF на стороне В, чтобы закончить выполнение функции оверрайда. При этом, если будет определено, что запрашивается сервис оверрайд при экстренном вызове, первичное сообщение-запрос приглашения может быть непосредственно послано на S-CSCF на стороне В или непосредственно на терминал В принимающей стороны; если будет определено, что сервис оверрайд при экстренном вызове не запрашивается, то сервер приложений на стороне В выполняет логическую последовательность операций по функциям передачи вызова или «не беспокоить», на которые имеется подписка у вызываемой стороны в соответствии с исходным процессом и определяет, требуется ли отправка полученного первичного сообщения-запроса приглашения обратно на S-CSCF на стороне В.

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

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

S510-S517: терминал В вызываемой стороны получает первичное сообщение-запрос приглашения, напоминает вызываемой стороне о том, что имеется вызов, путем подачи звонка и посылает временное сообщение о звонке вызывающей стороне А.

S518-S525: принимающая сторона поднимает трубку телефона, тем самым принимая вызов, и терминал вызываемой стороны посылает вызывающей стороне ответное сообщение о приеме приглашения.

S526-S532: после получения сообщения о приеме приглашения терминал вызывающей стороны троекратно посылает повторное сообщение-запрос вызываемой стороне до успешного завершения процедуры установления связи.

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

В соответствии с еще одним воплощением настоящего изобретения прилагается также сервер приложений.

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

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

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

Структурная схема такого сервера приложений показана на фиг.7. Такой сервер приложений расположен на вызывающей стороне и, как показано на фиг.7, включает задающий модуль 702, сконфигурированный для задания идентификатора сервиса, индицирующего сервис оверрайда при экстренном вызове, в первичном сообщении-запросе; и отправляющий модуль 704, сконфигурированный для отправки первичного сообщения-запроса на сервер приложений, находящийся на вызываемой стороне (сервер приложений, изображенный на фиг.6).

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

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

На фиг.8 приведена схема системы для реализации сервиса оверрайда при экстренном вызове в соответствии с одним из воплощений настоящего изобретения. Как показано на фиг.8, система содержит первый сервер приложений 802 на вызывающей стороне и второй сервер приложений 804 на вызываемой стороне.

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

Второй сервер приложений 804 содержит принимающий модуль 602, сконфигурированный для приема первичного сообщения-запроса от первого сервера приложений 802; и исполнительный модуль 604, сконфигурированный для исполнения сервиса оверрайда при экстренном вызове в соответствии с идентификатором сервиса.

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

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

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

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

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

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

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

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

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

3. Способ по п.1 или 2, при котором идентификатор сервиса содержится в заголовке первичного сообщения-запроса.

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

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

6. Способ по п.4, при котором операция отправки первым сервером приложений первичного сообщения-запроса вызываемой стороне содержит:
отправку первым сервером приложений первичного сообщения-запроса вызываемой стороне через сетевой элемент S-CSCF.

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

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

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

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

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