СПОСОБЫ И УСТРОЙСТВА ДЛЯ ПЕРЕДАЧИ ИНФОРМАЦИИ О СОСТОЯНИИ СИГНАЛЬНОГО СОЕДИНЕНИЯ, ОТНОСЯЩЕЙСЯ К СИГНАЛЬНОМУ СОЕДИНЕНИЮ МЕЖДУ ТЕРМИНАЛОМ И МОДУЛЕМ ПОСРЕДНИЧЕСКОЙ ФУНКЦИИ УПРАВЛЕНИЯ СЕАНСОМ/ВЫЗОВОМ (P-CSCF) В МУЛЬТИМЕДИЙНОЙ ПОДСИСТЕМЕ ИНТЕРНЕТ-ПРОТОКОЛА (IMS)

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

Изобретение относится к состоянию сигнальной линии связи для пользователей IP Мультимедийной Подсистемы (IMS). В частности, но не обязательно, оно относится к P-CSCF, обеспечивающей указание того, что линия связи, предварительно используемая для передачи SIP сигналов между пользователем и P-CSCF, была потеряна.

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

IP Мультимедиа (IPMM) представляет собой пример услуги, которая обеспечивает динамическое объединение голоса, изображения, сообщения, данных и т.д. в одном и том же сеансе. Путем увеличения числа базовых приложений и среды, которые можно объединить, число услуг, предлагаемых пользователю, возрастет, и опыт межперсональной связи станет богаче. Это приведет к новому поколению персонализированных услуг связи с широкими мультимедийными возможностями, например мультимедийная одноранговая связь, IPTV и т.д.

Эти услуги могут быть основаны на архитектуре IP Мультимедийной Подсистемы (IMS), которая является технологией, определенной с помощью Проекта Сотрудничества Третьего Поколения (3GPP), чтобы обеспечить IP Мультимедийные услуги по сетям мобильной связи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329 версии 5-7).

IMS применяет Протокол Инициализации Сеанса (SIP), чтобы установить и управлять звонками или сеансами между пользовательскими терминалами (или пользовательскими терминалами и серверами приложений). Протокол Описания Сеанса (SDP), переносимый сигналами SIP, использован, чтобы описывать и согласовывать компоненты среды сеанса. Другие мультимедийные приложения, которые могут быть использованы для передачи среды и управления, включают в себя Транспортный Протокол Реального Времени и Транспортный Управляющий Протокол Реального Времени (RTP/RTCP), Протокол ретрансляции сообщений сеанса (MSRP) и Протокол Преобразования Гипертекста (HTTP).

Фиг. 1 иллюстрирует схематически, как IMS встраивается в архитектуру мобильной сети в случае 3GPP PS доступа сети.

Функции Управления Сеансом/Вызовом (CSCF_s) работают как SIP посредники c IMS. Архитектура 3GPP определяет три типа CSCF: Посредническая CSCF (Р-CSCF), которая является первой точкой контакта внутри IMS для SIP терминала; Сервисная CSCF (S-CSCF), которая обеспечивает услуги пользователю, на которые пользователь подписан; и Запрашивающая CSCF (I-CSCF), чья роль заключается в указании правильной S-CSCF и в передаче ей S-CSCF запроса, принятого от SIP терминала через Р-CSCF.

Если пользователь хочет получить доступ к услугам, обеспечиваемым сетью IP Мультимедийной Подсистемы (IMS), то пользователь должен обычно зарегистрировать свою собственную домашнюю сеть (это может происходить при включении пользовательского устройства). IMS/SIP клиент в оборудовании пользователя инициализирует процесс регистрации путем отправки SIP REGISTER сообщения Сервисной Функции Управления Сеансом/Вызовом (S-CSCF), присвоенного пользователю в домашней сети. При приеме REGISTER сообщения пользователь домашней сети может разрешить или отказать в доступе к IMS сети. Устройство пользователя или Оборудование Пользователя (UE) соединяется через сеть доступа, и первая точка контакта для пользователя в IMS представляет собой Р-CSCF. Как часть процесса регистрации S-CSCF сохраняет адрес контакта Р-CSCF вместе с адресом UE.

Передача сигналов между терминалом и Р-CSCF выполняется с использованием сети доступа. Возможно, что линия связи для передачи сигналов информации в сети доступа потеряна. Это может случиться, например, когда сигнал «прямо через воздух» потерян (например, когда пользователь проезжает через туннель) или когда пользователь движется в зоне перегруженной соты. Происходит непрерывная работа в 3GPP R7, чтобы гарантировать, что Р-CSCF примет указание, что линия передачи сигналов была потеряна, например, через R_x интерфейс. Однако нет предложений, которые были бы сделаны относительно того, что Р-CSCF сделает с этим указанием, кроме простого формирования команды Р-CSCF отмены регистрации. Другими словами, Р-CSCF послала бы SIP REGISTER запрос S-CSCF для отмены регистрации терминала. Это не является достаточно характерным или универсальным, чтобы указать состояние сигнального соединения терминала. IMS в настоящий момент не содержит механизма для передачи указания потери сигнальной линии.

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

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

определение на узле-посреднике того, что состояние сигнального соединения изменилось на новое состояние; и

отправку SIP запроса от узла-посредника IMS узлу IP Мультимедийной Подсистемы, при этом SIP запрос указывает новое состояние.

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

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

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

Узел-посредник представляет собой предпочтительно Посредническую Функцию Управления Вызовом/Сеансом. IMS узел может быть Сервисной Функцией Управления Вызовом/Сеансом.

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

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

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

В соответствии с еще одним следующим аспектом настоящего изобретения, предусмотрен способ регистрации терминала на IMS узле IP Мультимедийной Подсистемы, содержащий отправку SIP REGISTER запроса IMS узлу, причем SIP REGISTER запрос включает в себя параметр состояния соединения, указывающий состояние сигнального соединения между терминалом и узлом-посредником.

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

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

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

В соответствии с другим аспектом настоящего изобретения предусмотрена Посредническая Функция Управления Сеансом/Вызовом для использования в IP Мультимедийной Подсистеме, содержащая:

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

средство вывода для обеспечения текущего состояния сигнального соединения к узлу IP Мультимедийной Подсистемы.

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

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

средство ввода на узле-посреднике для определения того, что состояние сигнального соединения изменилось на новое состояние;

выходное средство на узле-посреднике для отправки SIP запроса, указывающего новое состояние; и

IMS узел IP Мультимедийной Подсистемы, предназначенный, чтобы принимать SIP запрос и предпринимать соответствующее действие.

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

Фиг. 1 иллюстрирует схематично архитектуру IP Мультимедийной Подсистемы в системе мобильной связи третьего поколения;

фиг. 2 представляет собой схематичный вид сигнального пути между SIP UE и S-CSCF;

фиг. 3 иллюстрирует последовательность сигналов для гарантирования того, что S-CSCF информирована о потере сигнального однонаправленного канала;

фиг. 4 иллюстрирует альтернативную последовательность сигналов для гарантирования того, что S-CSCF информирована о потере сигнального однонаправленного канала;

фиг. 5 иллюстрирует последовательность сигналов для доставки информации о соединении S-CSCF; и

фиг. 6 иллюстрирует последовательность сигналов для уведомления S-CSCF о потере сигнального однонаправленного канала.

Подробное описание предпочтительного осуществления

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

Фиг. 2 представляет собой схематическое представление сигнального пути 1 между UE 2 и S-CSCF 3 через Р-CSCF 4. Линия 5 связи обеспечивается сетью доступа (не показана) UE. Р-CSCF включает в себя механизм 6 мониторинга, который определяет, потерян ли сигнальный путь 1 от UE.

Фиг. 3 иллюстрирует последовательность сигналов между Р-CSCF и S-CSCF, которая позволяет данным о соединении UE быть записанными S-CSCF-ей. В данном примере это достигается введением нового параметра заголовка контакта, указывающего состояние соединения UE. Подходящие значения для информации о состоянии могут включать в себя: «соединенное», «разъединенное», «неясное» и «неизвестное». «Неясное» состояние может быть использовано, когда есть подозрение, что произошел отказ при соединении.

Последовательность сигналов указана далее:

Этап 1: UE регистрирует свой контакт с S-CSCF известным образом. UE и P-CSCF подписывают пакет события регистрации, чтобы получить уведомления об информации регистрации, поддерживаемой S-CSCF.

Этап 2: P-CSCF определяет потерю сигнальной линии связи между ней и UE. Этого можно достигнуть, например, с помощью P-CSCF, принимающей такое указание по R_x интерфейсу. P-CSCF посылает REGISTER запрос S-CSCF. REGISTER запрос включает в себя адрес контакта UE, совместно с новым параметром заголовка контакта. Новый параметр содержит детали состояния контакта соединения. В этом примере состояние имеет вид «разъеденное». P-CSCF вставляет свой SIP URI адрес в заголовок «От».

Этап 3: когда S-CSCF принимает REGISTER запрос, она устанавливает, что запрос был создан объектом, заслуживающим доверия. Один путь достижения этого заключается в сравнении адреса P-CSCF, принятого в запросе, с P-CSCF адресом, ранее сохраненным при процедуре регистрации на Этапе 1. Как только S-CSCF подтвердила, что P-CSCF авторизован, то тогда S-CSCF возвращает 200 OK ответ. Это подтверждает, что состояние «контакт разъединен», содержащееся в REGISTER запросе, было записано.

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

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

Альтернативная последовательность сигналов для получения информации о соединении для S-CSCF показана на фиг.4. Эта альтернатива расширяет определение Пакета События Регистрации (RFC 3680) путем добавления необязательной информации о состоянии сигнального контакта к элементу информации о контакте документа с информацией о регистрации. Состояние соединения UE включается в начальную регистрацию в S-CSCF, в дополнение к местоположению и идентификации. Этого можно достигнуть с помощью S-CSCF, допуская, что начальное состояние сигнального соединения все еще имеет вид «соединено» (и если известно, что) начальная регистрация имеет место во всем сигнальном канале. Альтернативно P-CSCF может обеспечивать начальное сигнальное соединение с S-CSCF, используя SIP PUBLISH запрос. Если P-CSCF определяет, что состояние соединения изменилось, то эта информация поступает к S-CSCF, используя PUBLISH запрос. S-CSCF обновляет свою информацию о регистрации в ответ на информацию, включенную в PUBLISH запрос. Как и прежде, подходящие значения для информации о состоянии могут включать в себя: «соединенное», «разъединенное», «неясное» и «неизвестное». «Неясное» состояние может быть использовано, когда есть подозрение, что произошел отказ при соединении.

Последовательность сигналов указана далее:

Этап 1: UE регистрирует свой контакт с S-CSCF известным образом. S-CSCF изучает состояние сигнального соединения в процессе этой начальной регистрации.

Этап 2: P-CSCF определяет потерю сигнальной линии связи между ней и UE. Как и прежде, этого можно достигнуть, например, с помощью P-CSCF, принимающей такое указание по R_x интерфейсу.

P-CSCF посылает PUBLISH запрос S-CSCF. PUBLISH запрос включает в себя документ, содержащий информацию о новом состоянии соединения контакта. В этом примере состояние имеет вид «разъединено». P-CSCF вставляет свой SIP URI адрес в заголовок «От».

Этап 3: когда S-CSCF принимает PUBLISH запрос, то она устанавливает, что запрос был создан объектом, заслуживающим доверия. Один путь достижения этого заключается в сравнении адреса P-CSCF, принятого в запросе, с P-CSCF адресом, ранее сохраненным при процедуре регистрации на Этапе 1. Как только S-CSCF подтвердила, что P-CSCF авторизован, то тогда S-CSCF возвращает 200 OK ответ. Это подтверждает, что состояние «контакт разъединен», содержащееся в REGISTER запросе, было записано.

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

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

В дальнейшем альтернативном варианте, определен новый пакет SIP события, который позволяет P-CSCF доставлять информацию о контакте соединения. Используется структура уведомления о SIP событии (PFC 3265). В этом альтернативном варианте P-CSCF поддерживает информацию о состоянии соединения контакта в Пакете SIP События с новым Документом с Информацией о Состоянии. Это позволяет другим объектам, таким как S-CSCF, подписывать эту информацию и получать уведомления об изменениях состояния.

Последовательность начальной установки показана на фиг.5 и представлена далее:

Этап 1: UE регистрирует свой контакт с S-CSCF. В процессе регистрации P-CSCF и S-CSCF сохраняют адрес друг друга. Они также сохраняют информацию, касающуюся начального контакта, и состояние начального контакта между UE и P-CSCF. UE и P-CSCF подписывают пакет события регистрации, чтобы получить уведомления об информации о регистрации, поддерживаемые S-CSCF. Они являются процедурами текущего стандарта 3GPP. Дополнительно P-CSCF создает Документ с Информацией о Контакте с информацией о состоянии соединения контакта и может предоставить S-CSCF SIP URI адрес созданного документа как часть процедуры регистрации. P-CSCF поддерживает этот документ так долго, как она поддерживает состояние регистрации контакта.

Этап 2: если контакт был зарегистрирован, S-CSCF подписывает состояние соединения контакта. Это достигается отправкой SIP SUBSCRIBE запроса P-CSCF, запрашивающего Документ с Информацией о Контакте зарегистрированного контакта.

Этап 3: когда P-CSCF принимает SUBSCRIBE запрос, то она устанавливает, что запрос был создан объектом, заслуживающим доверия. Один путь достижения этого заключается в сравнении адреса S-CSCF, принятого в запросе, с S-CSCF адресом, ранее сохраненным при процедуре регистрации на Этапе 1. P-CSCF сохраняет адрес S-CSCF, как подписчика на Информацию о Контакте. Обладая авторизованной S-CSCF в качестве доверенного подписчика, P-CSCF отвечает 200 OK на SUBSCRIBE запрос.

Этап 4: P-CSCF затем посылает SIP NOTIFY запрос новому подписчику (S-CSCF) с текущим Документом с Информацией о Контакте, в этом примере указывающим, что контакт соединен.

Этап 5: когда S-CSCF принимает NOTIFY запрос, то он сохраняет Информацию о Контакте для дальнейшего использования и отвечает 200 OK.

Следует заметить, что P-CSCF обеспечивает SIP URI Документа с Информацией о Контакте во время регистрации.

Если сигнальная линия связи потеряна, то это определяется, как и прежде, с помощью P-CSCF (например, с помощью приема указания по R_x интерфейсу). Последовательность сигналов для передачи этой информации иллюстрируется на фиг. 5 и выполняется, как указано далее:

Этап 6: если P-CSCF определяет потерю сигнальной линии связи между ней и UE, то P-CSCF посылает SIP NOTIFY запрос S-CSCF. NOTIFY запрос включает в себя измененный Документ с Информацией о Контакте с новой информацией о состоянии соединения контакта. В этом примере он указывает, что контакт сейчас разъединен.

Этап 7: если S-CSCF принимает NOTIFY запрос, то он обновляет информацию о состоянии соединения контакта и посылает 200 OK ответ.

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

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

Будет понятно, что отклонения от выше описанных осуществлений могут все же выпадать из объема изобретения. Например, все осуществления описывают вышеуказанную ситуацию, когда ясное указание на потерю сигнальной связи принимается P-CSCF по R_x интерфейсу. Однако могут быть предусмотрены и другие механизмы, с помощью которых P-CSCF уведомляют о потере сигнального соединения. Например, может быть использовано отсутствие ответа от UE, после определенного периода времени. Альтернативно, сообщение Протокола Управляющих Сообщений Сети (ICMP) может быть принято от IP транспортной сети. Также могут быть использованы другие механизмы.

Также будет понятно, что все вышеописанные осуществления рассматривают главным образом в связи с потерей сигнального соединения между UE и P-CSCF. Замечено в каждом случае, что S-CSCF может обновить состояние соединения для дальнейшего использования. Если соединение заново установлено, то система в соответствии с настоящим изобретением может быть использована, чтобы направить эту информацию S-CSCF, так что она может опять обновить свое состояние. Изобретение не ограничивается отчетом о потере соединения между UE и P-CSCF: оно относится к отчету о состоянии связи.

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