Результат интеллектуальной деятельности: СПОСОБЫ, УСТРОЙСТВА И КОМПЬЮТЕРНЫЕ ПРОГРАММНЫЕ ПРОДУКТЫ ДЛЯ МАРШРУТИЗАЦИИ ВЫЗОВА ИЗ ДОМЕНА С КОММУТАЦИЕЙ КАНАЛОВ В УНИФИЦИРОВАННЫЙ СЛУЖЕБНЫЙ ДОМЕН

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

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

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

В системах мобильной связи второго (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.

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

о Приложение USSD на сервере 112 MSC-S заблокировано

о Клиент служб ICS на базе сервера MSC-S постоянно используется

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

о Клиент служб ICS на сервере 112 MSC-S никогда не активируется

о Приложение USSD на сервере 112 MSC-S не активировано

Если при обновлении местоположения/привязки IMSI сервер 112 MSC-S не может обнаружить оконечное клиентское приложение служб ICS, то сетевое клиентское приложение 132 служб ICS выберет узел 150 IA для использования для взаимодействия с подсистемой 114 IMS. После выбора узла 150 IA клиентское приложение 132 служб ICS инициирует регистрационную процедуру подсистемы IMS. Идентификатор IA возвращается клиентскому приложению 132 служб ICS, и в случае с сетевым клиентом служб ICS идентификатор IA и связанное состояние служб ICS сохраняются в базе VLR, а также загружаются в базу HLR.

Когда терминал 110 перемещается из зоны, обслуживаемой посредством сервера 112 MSC-S (и посредством клиентского приложения 132 служб ICS сервера 112 MSC-S), в зону нового сервера MSC-S, идентификатор IA и состояние служб ICS принимаются новым сервером MSC-S из базы HLR совместно с абонентскими данными. Затем адаптер 150 интерфейса (IA), идентифицированный посредством принятого идентификатора IA, используется посредством нового сервера MSC-S для возобновления регистрации подсистемы IMS для перемещаемого терминала 110. Это означает, что идентификационная информация соединения адаптера 150 интерфейса (IA) не меняется при перемещении терминала 110.

Клиентское приложение 132 служб ICS на предыдущем сервере 112 MSC-S сбрасывается после приема индикатора отмены местоположения из базы HLR. В случае когда терминал 110 освобождается от обслуживания сервера 112 MSC-S, адаптер 150 интерфейса (IA) также должен быть сброшен.

В сценарии сетевого клиента служб ICS клиентское приложение 132 служб ICS на сервере 112 MSC-S снимает с регистрации терминал 110 и сбрасывает устройство IA. В оконечном клиентском приложении 120 служб ICS таймер IA контролирует регистрацию подсистемы IMS посредством терминала 110. Если таймер истекает, то устройство IA сбрасывается.

В изображенных на Фиг.4-19 вариантах осуществления функциональные возможности служб ICS в подсистеме 114 IMS предоставляются на основе подписки. Подписка на службы ICS предоставляется каждому абоненту посредством оператора в базе HLR и загружается на сервер 112 MSC-S с обычным сообщением ввода абонентских данных МАР. Если для терминала 110, обслуживаемого посредством сервера 112 MSC-S, подписка на службу ICS не может быть определена, то терминал 110 обслуживается в соответствии с обычной подпиской на службы ICS, а также будет обычно обслуживаться в служебном домене ICS. Однако если подписка на службы ICS может быть определена для терминала 110, то активируется сетевое или оконечное клиентское приложение служб ICS в зависимости от состояния клиента служб ICS (возможные состояния клиента служб ICS уже были описаны выше). В абонентских данных может присутствовать дополнительный индикатор запрета uICS. Посредством установления индикатора запрета uICS оператор может запретить использование любого оконечного клиентского приложения служб ICS.

Вышеупомянутые основные механизмы, вовлекающие динамический выбор либо оконечного приложения 120 служб ICS (см. Фиг.4), либо сетевого клиентского приложения 132 служб ICS (см. Фиг.5), будут описаны далее более подробно со ссылкой на сценарии передачи сигналов, изображенные на Фиг.6-19. Сначала будут рассмотрены основные процедуры привязки IMSI, которые инициируют динамический выбор клиентского приложения служб ICS.

Процедуры привязки IMSI

Фиг.6 и 7 изображают процедуру привязки IMSI для терминала 110, перемещаемого в домашней сети с поддержкой служб ICS. Процедура привязки IMSI вовлекает оконечное клиентское приложение 120 служб ICS.

При перемещении в домашней сети (или в любой другой сети с поддержкой служб ICS) процедура выбора, как показано на Фиг.6, запускается на основе сообщения привязки IMSI, которое послано посредством терминала на сервер 112 MSC-S (этап 1). Затем сервер 112 MSC-S должен решить, применять ли сетевое клиентское приложение служб ICS или использовать любое оконечное клиентское приложение 120 служб ICS (этап 2). Это решение на сервере 112 MSC-S может быть основано на различных элементах информации, как определено посредством, например, оператора 170 сети. Сервер 112 MSC-S может обнаружить присутствие клиентского приложения 120 служб ICS в терминале 110 на основе следующих критериев:

- Абонентские данные в базе VLR (не показана) содержат подписку на службы ICS,

- а запрос на модификацию принят в привязке IMSI, причем эта модификация является регистрацией подсистемы IMS через USSD на не зависящей от вызова транзакции (для того, чтобы приложение USSD на сервере 112 MSC-S проверило строки USSD, принятые от терминала 110, для определения того, была ли инициирована регистрация подсистемы IMS посредством терминала 110),

или

- абонентские данные в базе VLR содержат подписку на службы ICS,

- а недавно определенный элемент информации (IE) индикатора служб ICS обнаружен в сообщении привязки IMSI 24.008,

или

- абонентские данные в базе VLR содержат подписку на службы ICS,

- а недавно определенный элемент информации (IE) классификационного индикатора 24.008 добавлен посредством терминала 110 для указания поддержки служб ICS в терминале 110.

Затем сервер 112 MSC-S выполняет выбор адаптера интерфейса (IA) (этап 3) на основе анализа распределения нагрузки. На следующем этапе проверка подписки на службы ICS выполняется посредством выбранного адаптера 150 интерфейса (IA) для реестра 160 домашних абонентов (HSR) (этап 4). Если подписка на службы ICS существует, то терминал 120 регистрируется в подсистеме 114 IMS (этап 5). Более того, выбранный адаптер 150 интерфейса (IA) возвращает свой уникальный идентификатор серверу 112 MSC-S, а также клиентскому приложению 120 служб ICS, постоянно находящемуся на терминале 110 (этап 6), для дальнейшего использования.

Сигнальный поток в случае, когда оконечное клиентское приложение 120 служб ICS обнаружено посредством сервера 112 MSC-S, схематически изображен на Фиг.7, а также кратко описан ниже:

Этапы 1) - 5): Обновление местоположения типа привязки IMSI обновляется для базы 180 HLR (не показана на Фиг.6), а также вводит абонентские данные в базу VLR (не показана на Фиг.6). Абонентские данные содержат индикатор подписки на службы ICS.

Этапы 6) - 7): Уровень управления мобильностью на сервере 112 MSC-S проверяет подписку на службы ICS в базе VLR. В этой последовательности предполагается, что клиентское приложение 120 служб ICS в терминале 110 обнаружено посредством последующего запроса на привязке IMSI.

Этапы 8) - 9): Терминал 110 открывает независящую от вызова транзакцию.

Этапы 10) - 12): Оконечное клиентское приложение 120 служб ICS использует установленную, не зависящую от вызова транзакцию для посылки строки USSD на адаптер 150 интерфейса (IA).

Этапы 13) - 16): Адаптер 150 интерфейса (IA) санкционирует службу ICS в базе 160 HSR и выполняет регистрацию подсистемы IMS.

Этапы 17) - 20): Адаптер 150 интерфейса (IA) возвращает строку USSD клиентскому приложению 120 служб ICS в терминале 110 для указания успеха регистрации подсистемы IMS. Клиентское приложение 120 служб ICS запускает таймер наблюдения за регистрацией.

Этапы 21) - 22): Приложение USSD на сервере 112 MSC-S обновляет статус служб ICS в базе VLR, а также в базе 180 HLR, указывая то, что сетевое клиентское приложение служб ICS дезактивировано. После чего процедура выбора завершается.

В случае когда сервер 112 MSC-S не может обнаружить оконечную поддержку служб ICS, активируется сетевая поддержка служб ICS. В связи с этим Фиг.8 и 9 изображают процедуру привязки IMSI для терминала 110, перемещаемого в домашней сети. Процедура привязки IMSI вовлекает сетевое клиентское приложение 132 служб ICS и выполняет схематически изображенные на Фиг.8 посредством этапов 1-7 действия. Более подробное описание связанного сигнального потока изображено на Фиг.9.

Этапы 1) - 5): Обновление местоположения типа привязки IMSI обновляется для базы 180 HLR, а также вводит абонентские данные в базу VLR. Абонентские данные содержат подписку на службы ICS.

Этапы 6) - 7): Уровень управления мобильностью на сервере 112 MSC-S проверяет подписку на службы ICS в базе VLR. В этой последовательности предполагается, что клиентское приложение служб ICS в терминале 110 не может быть обнаружено.

Этап 8): Уровень управления мобильностью на сервере 112 MSC-S активирует для абонента сетевую поддержку служб ICS

Этапы 9) - 10): Сетевое клиентское приложение служб ICS использует установленную, не зависящую от вызова транзакцию для посылки строки USSD на адаптер 150 интерфейса (IA).

Этапы 11) - 14): Адаптер 150 интерфейса (IA) санкционирует службу ICS в базе 160 HSR и выполняет регистрацию подсистемы IMS.

Этапы 15) - 17): Адаптер 150 интерфейса (IA) возвращает строку USSD сетевому клиентскому приложению служб ICS для указания успеха регистрации подсистемы IMS. Клиентское приложение служб ICS запускает таймер наблюдения за регистрацией.

Этапы 21) - 22): Приложение USSD на сервере 112 MSC-S обновляет статус служб ICS в базе VLR, а также в базе 180 HLR, указывая то, что сетевое клиентское приложение служб ICS активировано, а также идентификатор IA, который был принят в ответ. После чего процедура выбора завершается.

Фиг.10 изображает процедуру привязки IMSI для терминала 110, перемещаемого в гостевой сети без сетевой поддержки служб ICS. В этом случае должно использоваться оконечное клиентское приложение 120 служб ICS, в противном случае абонент не сможет использовать централизованные службы подсистемы IMS вообще.

Как иллюстрировано на Фиг.10, передача сигналов начинается с сообщения привязки IMSI, которое посылается с терминала 110 на сервер 112 MSC-S в гостевой сети (этап 1). Сервер 112 MSC-S в гостевой сети не обеспечивает поддержку служб ICS и, следовательно, напрямую отправляет любые операции USSD приложению USSD, постоянно находящемуся в базе 180 HLR в домашней сети (этап 2). База 180 HLR выполняет выбор адаптера интерфейса (IA) (этап 3) на основе анализа распределения нагрузки. Затем посредством выбранного адаптера 150 интерфейса (IA) для базы 160 HSR проверяется подписка на службы ICS (этап 4). Если подписка на службы ICS существует, то терминал 120 регистрируется в подсистеме 114 IMS (этап 5). Кроме того, выбранный адаптер 150 интерфейса (IA) возвращает свой уникальный идентификатор базе 180 HLR, а также клиентскому приложению 120 служб ICS, постоянно находящемуся на терминале 110 (этап 6), для дальнейшего использования.

В изображенных на Фиг.6-10 сценариях сервер 112 MSC-S также может реализовать дополнительные механизмы для предоставления оператору 170 или абоненту контроля над принятием решения относительно того, использовать ли сетевое клиентское приложение служб ICS или же использовать оконечное клиентское приложение служб ICS. Дополнительные функциональные возможности на сервере 112 MSC-S могут активировать сетевую поддержку служб ICS несмотря на то, что оконечное клиентское приложение служб ICS доступно и было обнаружено посредством сервера 112 MSC-S. Это замена может быть основана на установках оператора, например, выраженных посредством индикатора запрета для оконечной поддержки служб ICS в абонентских данных, или посредством установки такого запрета для всех перемещающихся абонентов из конкретной сети. Замена может быть реализована в приложении USSD сервера 112 MSC-S (например, посредством отклонения любых строк USSD регистрации подсистемы IMS на сервере 112 MSC-S).

Сценарии перемещения в сети с коммутацией каналов (CS)

Фиг.11 и 12 иллюстрируют действия в отношении активированного оконечного клиентского приложения служб ICS, которые выполняются для перемещаемого терминала 110. При перемещении в зону обслуживания подобного сервера 112 MSC-S, который выполнил основную процедуру выбора клиента служб ICS, изображенную на Фиг.6 и 7, никакие новые действия не выполняются, как иллюстрировано на Фиг.11 посредством этапов 1) - 6). При выходе из зоны обслуживания старого сервера 112 MSC-S и входе в зону обслуживания нового сервера 112 MSC-S' идентификатор IA и статус служб ICS загружаются из базы 180 HLR, и в случаях, когда оконечное клиентское приложение служб ICS использовалось прежде, это состояние будет неизменным, а тот же самый адаптер 150 интерфейса IA будет использоваться дальше (этапы 7) - 12) на Фиг.11).

Более подробное описание связанного сигнального потока изображено на Фиг.12:

Этапы 1) - 5): Обновление местоположения типа изменения LA обновляется для базы 180 HLR, а также вводит абонентские данные в базу VLR. Абонентские данные содержат подписку на службы ICS. Состояние указывает на то, что сетевая поддержка служб ICS (то есть сетевое клиентское приложение служб ICS) дезактивирована.

Этапы 6) - 7): Уровень управления мобильностью на сервере 112 MSC-S проверяет подписку на службы ICS в базе VLR. Поскольку состояние указывает, что сетевая поддержка служб ICS дезактивирована, никакие дальнейшие действия на сервере 112 MSC-S не выполняются.

Фиг.13 и 14 иллюстрируют действия в отношении активированного сетевого клиентского приложения служб ICS, которые выполняются для перемещаемого терминала 110. При перемещении в зону обслуживания подобного сервера 112 MSC-S, который выполнил основную процедуру выбора клиента служб ICS, как иллюстрировано на Фиг.8 и 9, никакие новые действия не выполняются, как иллюстрировано на Фиг.13 посредством этапов 1) - 5). При выходе из зоны обслуживания старого сервера 112 MSC-S и входе в зону обслуживания нового сервера 112 MSC-S' идентификатор IA и статус служб ICS загружаются в базу 180 HLR, и в случаях, когда сетевое клиентское приложение служб ICS использовалось прежде, это состояние будет неизменным, а тот же самый адаптер 150 интерфейса IA будет использоваться дальше (этапы 6) - 12) на Фиг.13).

Более подробное описание связанного сигнального потока изображено на Фиг.14:

Этапы 1) - 5): Обновление местоположения типа изменения LA обновляется для базы 180 HLR и вводит абонентские данные в базу VLR. Абонентские данные вновь содержат подписку на службы ICS. Состояние указывает, что сетевая поддержка служб ICS активирована, а также распределенный идентификатор IA.

Этапы 6) - 7): Уровень управления мобильностью на сервере 112 MSC-S' проверяет подписку на службы ICS в базе VLR. Поскольку состояние указывает, что сетевая поддержка служб ICS активирована, новое локальное сетевое клиентское приложение служб ICS должно быть использовано посредством сервера 112` MSC-S.

Этапы 8) - 9): Используется новое клиентское приложение служб ICS. Поскольку новое клиентское приложение служб ICS не имеет данных об активной регистрации подсистемы IMS, а также статуса таймера, должна быть вызвана повторная регистрация подсистемы IMS.

Этапы 10) - 16): Повторная регистрация подсистемы IMS выполняется с помощью того же самого адаптера 150 интерфейса (IA), как и прежде. Проверка подписки HSR не требуется.

Процедуры аннулирования местоположения, вовлекающие базу HLR

Когда терминал 110 входит в зону обслуживания нового сервера 112` MSC-S, старый сервер 112 MSC-S аннулируется из базы 180 HLR. В случае активированного оконечного клиентского приложения служб ICS не требуются никакие дополнительные действия. Этот случай идентифицируется новым сервером 112` MSC-S посредством проверки статуса подписки на службы ICS в базе VLR. Если использовалась сетевая поддержка служб ICS, то клиентское приложение служб ICS на старом сервере 112 MSC-S должно быть сброшено, как показано в сигнальном потоке на Фиг.15. Поскольку адаптер 150 интерфейса (IA) снова используется новым сервером 112` MSC-S, никакие дополнительные действия для адаптера 150 интерфейса (IA) или подсистемы 114 IMS не требуются.

Выполнение аннулирования привязки CS

Когда терминал 110 выключается, индикатор аннулирования привязки принимается на сервере 112 MSC-S, как схематично изображено в сигнальных потоках на Фиг.16 и 17.

В отношении оконечного клиентского приложения служб ICS (Фиг.16) никакие дополнительные действия не могут быть выполнены, поскольку терминал 110 не может посылать строку USSD.

Этап 1): Индикатор аннулирования привязки от терминала 110 принимается сервером 112 MSC-S.

Этапы 2) - 3): Уровень управления мобильностью на сервере 112 MSC-S проверяет подписку на службы ICS. Поскольку сетевая поддержка служб ICS дезактивирована, никакие дополнительные действия не выполняются.

Этапы 4) - 5): Таймер наблюдения за регистрацией в адаптере 150 интерфейса (IA) истекает, и адаптер 150 интерфейса (IA) сбрасывается. Регистрация подсистемы IMS истекает и удаляется автоматически посредством подсистемы 114 IMS.

Следует отметить, что в иллюстрированном на Фиг.16 сценарии сервер 112 MSC-S не может связаться с адаптером 150 интерфейса (IA) в связи с тем, что он не информирован об идентификаторе IA (оконечная поддержка служб ICS).

В отношении сетевой поддержки клиента служб ICS сетевое клиентское приложение служб ICS по-прежнему может отменить регистрацию подсистемы IMS, как схематически изображено на Фиг.17:

Этап 1): Индикатор аннулирования привязки от терминала 110 принимается сервером 112 MSC-S.

Этапы 2) - 3): Уровень управления мобильностью на сервере 112 MSC-S проверяет подписку на службы ICS, эта проверка указывает, что сетевое клиентское приложение служб ICS находится в активированном состоянии.

Этап 4): Уровень управления мобильностью информирует клиентское приложение служб ICS в сети об аннулировании привязки.

Этапы 5) - 11): Выполняется отмена регистрации подсистемы IMS с помощью адаптера 150 интерфейса (IA), и устройство IA сбрасывается.

Этапы 12) - 13): Приложение USSD на сервере 112 MSC-S обновляет базу 180 HLR, а также базу VLR и удаляет идентификатор IA.

Процедура повторной регистрации

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

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

В отношении сетевого клиентского приложения служб ICS таймер запускается на сервере 112 MSC-S, как иллюстрировано в сигнальном потоке на Фиг.19. После истечения таймера сетевое клиентское приложение служб ICS связывается с адаптером 150 интерфейса (IA) для повторной регистрации.

Самостоятельное управление

Сетевая поддержка служб ICS и управление ее статусом может быть обеспечено посредством оператора в базе 180 HLR. Статус может быть изменен посредством абонента при использовании:

- существующих процедур дополнительного обслуживания (SS), расширенных на базе служб nICS, или

- Процедур ut, или

- веб-портала и доступа с коммутацией пакетов (PS) к этому веб-порталу.

Как будет понятно из вариантов осуществления, преимущества оконечных служб ICS (uICS) и сетевых служб ICS (nICS) могут быть объединены в одно динамическое решение, где оконечные и сетевые клиентские приложения присутствуют в одной сети для одного абонента (или одного терминала). Если абонент использует более современный (усовершенствованный) терминал, который включает в себя клиентское приложение служб ICS, то абонент может использовать подход, основанный на терминале, и получить полный объем возможностей подсистемы IMS. Если абонент использует устаревший терминал без клиентского приложения служб ICS, то может быть обеспечена сетевая поддержка для извлечения выгоды из одного, нескольких или всех возможностей подсистемы IMS.

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

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