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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

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

Для обеспечения более единообразного взаимодействия с пользователем, а также для сокращения рабочей нагрузки, связанной с методиками переключения служебных доменов, желательно обеспечить унифицированный служебный домен вместо множества различных служебных доменов. В настоящее время посредством проекта 3GPP исследуется соответствующее решение для последовательно маршрутизируемых вызовов из сети доступа с коммутацией каналов (CS), через сеть подсистемы IMS, в служебный домен подсистемы IMS. Рабочий элемент называется централизованными службами подсистемы IMS (ICS) и нацелен на перемещение всех абонентов в подсистему IMS для гармонизации служебной среды (см. 3GPP TSG SA WG2 Архитектура - SA2#5, София Антиполис, Франция, 28 августа - 1 сентября 2006, Tdoc S2-063335).

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

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

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

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

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

Унифицированный служебный домен может являться служебным доменом, выбираемым из двух и более потенциально доступных служебных доменов в качестве конкретного служебного домена для гармонизации служебного домена. Выбор может быть выполнен посредством оператора сети. В одном варианте унифицированный служебный домен является служебным доменом подсистемы IMS под парадигмой служб ICS, как описано в документе 3GPP TSG SA WG2 Архитектура - SA2#5, София Антиполис, Франция, 28 августа - 1 сентября 2006, Tdoc S2-063335, при этом включенном посредством ссылки, в частности, касательно функциональных возможностей клиентских приложений и аспектов унифицированного служебного домена.

Несмотря на то что домен доступа является предпочтительным доменом доступа с коммутацией каналов (CS), не исключаются любые передачи вызова с домена доступа с коммутацией каналов (CS) на другой домен доступа (например, на домен с коммутацией пакетов (PS), такой как IP-CAN), или c другого подобного домена доступа на домен доступа с коммутацией каналов (CS), или же между двумя различными доменами доступа с коммутацией каналов (CS). Такие передачи вызова могут возникнуть, например, в сценариях непрерывности обслуживания (обеспечения служб), таких как сценарий непрерывности голосового вызова (VCC).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В следующем описании для обеспечения полного понимания настоящего изобретения в целях объяснения, а не ограничения описаны определенные детали, такие как конкретные последовательности этапов, интерфейсы и конфигурации. Специалистам в данной области техники будет понятно, что настоящее изобретение может быть осуществлено на практике в других вариантах осуществления, которые отступают от этих определенных деталей. Например, несмотря на то что варианты осуществления будут иллюстративно описываться в контексте унифицированного служебного домена подсистемы IMS, очевидно, что изобретение также может быть осуществлено на практике в других унифицированных служебных доменах, отличных от охватываемых посредством подсистемы IMS. Кроме того, несмотря на то что в следующих вариантах осуществления будут описываться отдельные протоколы, такие как протокол передачи неструктурированных данных для дополнительных услуг (USSD), протокол подсистемы пользователя сети ISDN (ISUP) и протокол управления вызовом, независимый от среды переноса (BICC), должно быть понятно, что другие подходящие протоколы также могут быть использованы вместо или в дополнение к одному или нескольким таким протоколам.

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

Фиг.1 иллюстрирует сеть 100 связи, включающую в себя два варианта осуществления аппаратных средств в виде терминала 110 с одной стороны и узла 112 сети с другой стороны. Сеть 100 связи дополнительно включает в себя унифицированный служебный домен 114. Терминал 110 может являться стационарным или мобильным терминалом, таким как персональный компьютер, мобильный телефон или персональный цифровой помощник (PDA). Узел 112 сети может являться коммутационным компонентом сети, таким как центр MSC или сервер MSC-S. Предпочтительно, узел 102 сети привязан или является частью домена доступа с коммутацией каналов (CS), с помощью которого терминал 110 может быть привязан к унифицированному служебному домену 114, как иллюстрировано посредством стрелки 116 на Фиг.1.

Терминал 110 включает в себя дополнительное клиентское приложение 120, предоставляющее функциональные возможности, которые поддерживают маршрутизацию вызова из домена доступа с коммутацией каналов (CS) с узлом 112 сети в унифицированный служебный домен 114. Клиентское приложение 120 является дополнительным в том отношении, что оно может быть потенциально опущено (например, если клиентское приложение, предоставляющее, по существу, аналогичные функциональные возможности, находится на узле 112 сети). Терминал 110 дополнительно включает в себя сетевой интерфейс 122, приспособленный к передаче на узел 112 сети индикатора конкретного клиентского приложения для предоставления функциональных возможностей для маршрутизации вызова в унифицированный служебный домен 114. Индикатор, предназначенный для передачи через сетевой интерфейс 122, генерируется посредством процессора 124 терминала 110. Как показано на Фиг.1, процессор 124 приспособлен к взаимодействию как с дополнительным клиентским приложением 120, так и с сетевым интерфейсом 122.

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

Как показано на Фиг.1, узел 112 сети дополнительно включает в себя собственное клиентское приложение 132 для выборочного обеспечения поддержки унифицированного служебного домена. Подобно дополнительному клиентскому приложению 120 терминала 110, сетевое клиентское приложение 132 приспособлено к предоставлению функциональных возможностей, которые поддерживают маршрутизацию вызова с терминала 110 через узел 112 сети в унифицированный служебный домен 114 (см. стрелку 116). Узел 112 сети дополнительно включает в себя датчик 134, соединенный с сетевым интерфейсом 130. Датчик 134 приспособлен к обнаружению в ответ на прием сообщения через сетевой интерфейс 130 клиентского приложения для предоставления функциональных возможностей маршрутизации.

Датчик 134 взаимодействует с контроллером 136, приспособленным к управлению состоянием активации, по меньшей мере, либо сетевого клиентского приложения 132, либо дополнительного оконечного клиентского приложения 120 в зависимости от результата обнаружения, выполненного посредством датчика 134. В зависимости от результата обнаружения контроллер 136 может, например, активировать или дезактивировать сетевое клиентское приложение 132. Однако контроллер 136 также может дистанционно управлять состоянием активации оконечного клиентского приложения 120. Для этой цели контроллер 136 может передать команды управления через сетевой интерфейс 130 на терминал 110.

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

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

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

Фиг.3 изображает схему 300 последовательности операций другого варианта осуществления для управления состоянием активации одного или нескольких клиентских приложений, предоставляющих функциональные возможности, которые поддерживают маршрутизацию вызова из домена доступа с коммутацией каналов (CS) в унифицированный служебный домен. Этот вариант осуществления способа может быть осуществлен на практике посредством узла 112 сети, изображенного на Фиг.1, или посредством любого другого узла сети.

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

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

На следующем этапе 306 состоянием активации, по меньшей мере, либо сетевого клиентского приложения, либо оконечного клиентского приложения управляют в зависимости от результата этапа обнаружения 304. Управление (этап управления) может включать в себя активацию (этап активации) одного из клиентских приложений и одновременную дезактивацию (этап одновременной дезактивации) другого клиентского приложения. В случае когда клиентское приложение не обеспечено на стороне терминала, этап 306 может включать в себя только активацию (этап активации) сетевого клиентского приложения. Если сетевое клиентское приложение по умолчанию находится в активированном состоянии, то этап 306 приведет к поддержке активированного состояния сетевого клиентского приложения.

Иллюстративная реализация служб ICS

Далее, со ссылкой на структурные блок-схемы сети и структурные схемы передачи сигналов, изображенные на Фиг.4-19, будут обсуждаться различные дополнительные варианты осуществления. Одинаковые ссылочные номера, используемые на Фиг.1, будут использоваться для обозначения идентичных или подобных компонентов.

Дополнительные варианты осуществления, изображенные на Фиг.4-19, относятся к динамическому выбору сетевого или оконечного клиентского приложения в иллюстративном контексте служб ICS. Изначально будут разъясняться более подробные решения для установки клиентского приложения на терминал (Фиг.4) и в сеть (Фиг.5).

Оконечные и сетевые клиентские приложения служб ICS

Изображенная на Фиг.4 сетевая система 400 включает в себя терминал 110 (также называемый абонентским оборудованием (UE)), имеющий доступ к сети с коммутацией каналов (CS). Терминал 110 включает в себя клиентское приложение 156 подсистемы IMS, а также дополнительно клиентское приложение 120 служб ICS. Сервер 112 MSC-S, медиа-шлюз 154 (MGW), адаптер 150 интерфейса (IA), функционирующий в качестве интерфейса для подсистемы 114 IMS, и медиа-прокси 152 (MP) включаются в сетевую систему 400 дополнительно.

Клиентское приложение 120 служб ICS на терминале 110 обеспечивает специальные задачи в контексте служб ICS, а также включает в себя два функциональных компонента, отражающих многоуровневую архитектуру сетевой системы 400. На уровне управления (или плоскости управления) клиентское приложение 120 служб ICS включает в себя функциональный блок «С» для управления сеансом. На пользовательском уровне (или пользовательской плоскости) клиентское приложение 120 служб ICS включает в себя функциональный блок «М» для управления мультимедийным соединением. Отдельные функциональные блоки клиентского приложения 120 служб ICS взаимодействуют с соответствующими функциональными блоками адаптера 150 интерфейса (IA). Взаимодействие на уровне управления вовлекает протокол служб ICS по USSD, между тем как взаимодействие на пользовательском уровне вовлекает протоколы согласно технической спецификации стандарта 24.008 проекта 3GPP, с одной стороны (между клиентским приложением 120 служб ICS и сервером 112 MSC-S), и ISUP/BICC, с другой стороны (между сервером 112 MSC-S и медиа-прокси 152 MP).

Уровень управления и пользовательский уровень привязаны к подсистеме 114 IMS через адаптер 150 интерфейса (IA) и медиа-прокси 152 (MP). Как показано на Фиг.4, подсистема 114 IMS включает в себя ядро IMS, а также прикладные службы IMS (такие, как службы мультимедийной телефонной связи (MMTel)). Ядро IMS и прикладные службы IMS взаимодействуют через протокол служб ICS.

Подразумевая существование клиентского приложения служб ICS где-то на сетевой стороне (см., например, Фиг.1 выше или Фиг.5 ниже), изображенный на Фиг.4 терминал 110 может быть сконфигурирован с возможностью выполнения варианта осуществления способа, обсужденного выше со ссылкой на Фиг.2. В одном варианте реализации терминал 110 посылает сетевой стороне индикатор, который информирует сетевую сторону о доступности клиентского приложения 120 служб ICS в терминале 110.

Между тем, как Фиг.4 иллюстрирует сетевую систему 400 с оконечным клиентским приложением 120 служб ICS, Фиг.5 изображает сетевую систему 500 с сетевым клиентским приложением 132 служб ICS. Как будет понятно после просмотра Фиг.5, клиентское приложение 132 служб ICS установлено на сервере 112 MSC-S. Другое клиентское приложение служб ICS может быть установлено на терминале 110 (как показано на Фиг.4). Изображенный на Фиг.5 сервер MSC-S может быть сконфигурирован с возможностью выполнения варианта осуществления способа, разъясненного выше со ссылкой на Фиг.3. Остальные компоненты сетевой системы 500 подобны компонентам вышеупомянутой сетевой системы 400, в связи с чем подробное описание будет опущено.

На основании Фиг.4 и 5 далее подразумевается, что клиентское приложение 132 служб ICS (также называемое «клиентом «uICS») будет всегда устанавливаться на сетевой стороне, а также что клиентское приложение 120 служб ICS (также называемое «клиентом nnICS») может быть установлено на стороне терминала.

Как уже разъяснялось выше, клиентское приложение служб ICS (сетевое или оконечное) будет соединено с адаптером 150 интерфейса (IA) подсистемы IMS, который служит в качестве интерфейсного узла для подсистемы 114 IMS. Реализация адаптера 150 интерфейса (IA) не должна зависеть от местоположения клиентского приложения служб ICS, то есть размещение клиентского приложения служб ICS (на стороне терминала или на сетевой стороне) предпочтительно является скрытым от адаптера 150 интерфейса (IA).

Клиентское приложение 132 служб ICS на сервере 112 MSC-S использует протокол служб ICS по USSD таким же образом, как и терминал 110 в решении, ориентированном на терминал. При процедурах обновления местоположения/привязки IMSI, инициированных терминалом 110 посредством соответствующих сообщений, сервер 112 MSC-S пытается обнаружить клиентское приложение служб ICS в терминале 110. Если терминал 110 имеет функциональные возможности клиента служб ICS (как показано, например, на Фиг.4), то клиентское приложение 132 служб ICS на сервере MSC-S дезактивируется. В противном случае, если клиентское приложение служб ICS не может быть обнаружено на терминале 110, то клиентское приложение 132 служб ICS на сервере 112 MSC-S активируется (или поддерживается в активированном состоянии, которое должно являться состоянием по умолчанию). Абонент, работающий с терминалом 110, может выбрать конкретное клиентское приложение служб ICS в качестве приложения по умолчанию (например, через веб-портал) и, следовательно, отвергнуть любой сетевой выбор.

Связанная со службами ICS информация, по меньшей мере, о состоянии активации клиентского приложения 132 служб ICS, а также о состоянии доступности/активации клиентского приложения 120 служб ICS, потенциально обеспечиваемого терминалу 110, локально сохраняется в базе VLR (не показана на Фиг.4 и 5) сервера 112 MSC-S. Такая информация также может быть загружена в базу HLR (не показана на Фиг.4 и 5).

Следовательно, статус клиента служб ICS (сохраненный на сервере 112 MSC-S и в базе HLR) может принимать следующие состояния:

- Введен сетью, дезактивирован = Предполагается оконечный клиент служб ICS.

- Введен сетью, активирован (IA ID) = Предполагается сетевой клиент служб ICS.

- Абонент активирован = принужденно на базе сети

о Пр