Передача информации непрерывности сеанса в многокомпонентном сеансе связи

Передача информации непрерывности сеанса в многокомпонентном сеансе связи

Иллюстрации

Показать все

Реферат

По настоящей заявке испрашивается приоритет по дате подачи предварительной заявки на патент США, серийный номер 61/073902, озаглавленной «Передача информации непрерывности сеанса в многокомпонентом сеансе связи», поданной 19 июня 2008г. и переуступленной патентообладателю настоящей заявки, и полностью включенной в настоящий документ посредством ссылки.

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

Данное изобретение, в целом, имеет отношение к связи и, более конкретно, оно имеет отношение к обмену информацией и ее обработке в сеансе связи с множеством компонентов сеанса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, в последующем описании, для краткости и ясности, используется терминология, связанная со стандартами широкополосного множественного доступа с кодовым разделением (WCDMA), как провозглашается Проектом партнерства третьего поколения (3GPP) посредством Международного союза по телекоммуникации (ITU). Следует подчеркнуть, что изобретение также пригодно и для других таких технологий, как технологии и связанные с ними стандарты, имеющие отношение к множественному доступу с кодовым разделением (CDMA), множественному доступу с временным разделением (TDMA), множественному доступу с частотным разделением (FDMA), ортогональному множественному доступу с частотным разделением (OFDMA) и т.д. Терминологии, связанные с различными технологиями, могут различаться, например, в зависимости от рассматриваемой технологии, абонентское оборудование (UE), используемое в стандартах WCDMA, иногда может называться терминалом доступа (AT), пользовательским терминалом, мобильной станцией (MS), абонентским модулем, абонентским оборудованием (UE) и т.д., и это лишь некоторые из вариантов. Аналогично, сеть доступа (AN), используемая в стандартах WCDMA, иногда может называться точкой доступа, узлом доступа, узлом B, базовой станцией (BS) и т.д. Здесь следует отметить, что различные терминологии относятся к различным технологиям, когда применимо.

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

На Фиг.1, для простоты и легкости описания, система 10 изображается как содержащая три сети доступа (ANs) 12, 14 и 16.

В данном примере, сеть 12 AN является сетью связи по технологии Долгосрочного развития (LTE), допускающей предоставление непрерывности протокола сети Интернет (IP) с мультимедийными службами, предлагаемыми посредством мультимедийной подсистемы 30 на базе протокола IP (IMS). Сеть 12 AN содержит различные сетевые элементы, такие, как элемент системы 32 управления мобильностью (MME), Узел B 34, обслуживающий шлюз 36 (SGW), и шлюз 38 PDN (сети передачи данных общего пользования) (PGW). Такой пользовательский элемент, как оборудование 22 UE в мобильном устройстве в данном примере, взаимодействует по беспроводной связи с узлом B 34 на уровне радиоканала.

Сеть 14 AN является сетью WLAN, например, сетью, работающей в соответствии со стандартами IEEE 802.11 и другими технологиями локальной сети передачи данных. Сеть 14 AN содержит, помимо прочего, точку 27 доступа (AP). Другой пользовательский элемент, такой, как другое оборудование 26 UE, может взаимодействовать по беспроводной связи с точкой 27 AP, например, для подключения к магистральной сети 20 связи.

Сеть 16 AN является еще одной сетью, например, сетью доступа CDMA2000. Сеть 16 AN содержит, помимо прочего, узел 29 обслуживания пакетных данных (PDSN), узел 31 доступа (AS) и контроллер 33 обслуживающей радиосети (SRNC). В качестве еще одного пользовательского элемента, такое другое оборудование 25 UE может взаимодействовать по беспроводной связи с сетью 31 AN, например, для подключения к магистральной сети 20 связи.

На Фиг.1 все три AN 12, 14, 16 AN связаны с базовой сетью подсистемы 30 IMS. Базовая сеть подсистемы 30 IMS, описанная в данном варианте осуществления, является сетью с архитектурным форматом, поддерживаемым посредством различных организаций по стандартизации, например 3GPP, 3GPP2 (Проектом партнерства третьего поколения 2), IEEE (Институтом инженеров по электротехнике и электронике), и т.д., и это лишь некоторые из них. Базовая сеть подсистемы 30 IMS использует протоколы IP и соединяется с магистральной сетью 20 связи. Магистральная сеть 20 связи может являться сетью Интернет или интранет.

На Фиг.1 единицы оборудования 22, 26 и 25 UE изображены как соединенные с базовой сетью подсистемы 30 IMS через сеть 12 AN LTE, сеть 14 AN WLAN и сеть 16 AN доступа CDMA2000 соответственно. Следует подразумевать, что одиночное оборудование UE может получить подключение к базовой сети подсистемы 30 IMS через одну, любую из, или все сети AN. Например, оборудование 22 UE может получить подключение к базовой сети подсистемы 30 IMS как через сеть 12 AN LTE, так и через сеть 14 AN WLAN, одновременно или в различные периоды времени.

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

В последующем описании используется терминология и протоколы, связанные с передачей сигналов и обменом данными, в соответствии со стандартами подсистемы IMS. Основные принципы стандартов подсистемы IMS могут быть найдены в публикации, озаглавленной «Протокол управления мультимедийным вызовом на базе протокола сети Интернет (IP), на основе протокола установления сеанса (SIP) и протокола описания сеанса (SDP)», 3GPP TS 24.229, изданной 3GPP.

Предположим изначально, что существует оборудование 22 UE, которое согласовывается с другим оборудованием 25 UE через базовую сеть подсистемы 30 IMS. Оборудование 22 UE получает подключение к базовой сети подсистемы 30 IMS через сеть 12 AN. Аналогично, оборудование 25 UE получает подключение к базовой сети подсистемы 30 IMS через сеть 16 AN.

В базовой сети подсистемы 30 IMS, это включает в себя прокси сервер 40 функции управления сеансом вызова (P-CSCF), обслуживающий сервер 42 функции управления сеансом вызова (C-CSCF), сервер 46 (AS) непрерывности сеанса (SC) и другие элементы 44 подсистемы IMS. Сервер 46 непрерывности сеанса (SC) является одним из типов сервера приложений в пределах базовой сети подсистемы 30 IMS, который предоставляет функциональные возможности для разрешения бесперебойной передачи сеанса из сеансов связи между различными подключениями. В данном примере, для поддержки непрерывности сеанса подсистемы IMS, все сеансы подсистемы IMS привязываются к серверу 46 SC.

В данном иллюстративном варианте осуществления, предположим изначально, что у оборудования 22 UE имеется сеанс подсистемы IMS с оборудованием 25 UE с несколькими мультимедийными компонентами. При данной спецификации и приложенной формуле изобретения, термин «много» или «несколько» означает более одного. Как упоминалось раньше, сеанс подсистемы IMS привязывается к серверу непрерывности 46 SC. Примером такого сеанса может являться ведение видеоконференции оборудования 22 UE с оборудованием 25 UE, в котором имеется несколько речевых и видео потоков. В целях описания, предположим, что в сеансе связи существует три компонента сеанса, а именно, голосовой #1, видео #2 и видео #3. Например, видео #2 может являться видео лицом к лицу пользователей оборудования 22 и 25 UE, а видео #3 может являться демонстрационным видео продукта.

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

Предположим, в данном примере, что оборудование 22 UE является мобильным и допускающим подключение к нескольким сетям AN, таким, как сети 12, 14 и 16 AN. Если оборудование 22 UE перемещается между различными сетями AN, то для оборудования 22 UE является весьма желательным возможность передачи сеанса связи подсистемы IMS или любого компонента сеанса, из одной сети AN в другую сеть AN.

Для иллюстрации, предположим, например, что сначала оборудование 22 UE взаимодействует с оборудованием 25 UE через сеть AN 12 LTE с вышеупомянутыми тремя компонентами мультимедийных данных, голосовым #1, видео #2 и видео #3. Если, например, оборудование 22 UE может получить подключение к сети 14 AN WLAN, то оборудование 22 UE может иметь дополнительную возможность передачи компонента мультимедийных данных видео #3 через сеть 14 AN WLAN, но при этом поддержки другого компонента мультимедийных данных голосового #1 и видео #2 через сеть 12 AN LTE.

Ниже описываются схемы упрощения сеанса и передачи компонента сеанса из одной сети AN в другую сеть AN через сервер непрерывности 46 SC.

Такому пользовательскому элементу подсистемы IMS, как оборудование 22 UE, разрешается установление нескольких мультимедийных сеансов с несколькими корреспондентами, как упомянуто выше. Например, оборудование 22 UE может иметь вышеупомянутый сеанс подсистемы IMS с оборудованием 25 UE, тогда как в то же самое время, оборудование 22 UE также может иметь другой сеанс подсистемы IMS с оборудованием 26 UE. Чтобы позволить передачу сеанса, все мультимедийные сеансы привязываются к серверу 46 непрерывности SC подсистемы IMS, упрощающему передачу сеанса оборудования 22 UE в его домашней сети подсистемы IMS. Если оборудование 22 UE запрашивает сервер 46 непрерывности SC 46 о передаче некоторых компонентов мультимедийных данных в пределах сеанса, обрабатываемого в настоящее время оборудованием 25 UE, в одну или несколько других сетей AN, то оборудованию 22 UE требуется точно идентификация и указания того, что сеанс с компонентами мультимедийных данных для передачи является намеченным сеансом, а не каким-либо другим сеансом. В данном примере, намеченный сеанс является сеансом оборудования 22 UE, взаимодействующего с оборудованием 25 UE, с тремя компонентами мультимедийных данных, голосовым #1, видео #2 и видео #3, как упомянуто выше. Он не является другим сеансом, если таковые вообще имеются, в котором, например, оборудование 22 UE также может взаимодействовать с оборудованием 26 UE.

Чтобы отличать различные сеансы, сервер 46 непрерывности SC подсистемы IMS назначает уникальные идентификаторы (ID) (идентификатор) для каждого сеанса, который оборудование 22 UE ведет с каждым конкретным удаленным конечным пользовательским элементом. Этот уникальный идентификатор (ID), который называется идентификатором STI (идентификатором передачи сеанса) в данном иллюстративном варианте осуществления, может принимать следующий формат: URI (идентификатор пользовательского ресурса), такой, как идентификатор URI SIP (протокола установления сеанса), телефонный идентификатор URI, идентификатор (ID) диалога протокола SIP из диалога протокола SIP и т.д. Приведенное ниже описание является схемами передачи данной информации, подтверждающей идентичность идентификатора STI между сервером 46 непрерывности SC и подсистемой IMS оборудования 22 UE.

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

Сначала предположим, что оборудование 22 UE запускает мультимедийный сеанс подсистемы IMS, как упомянуто выше, посредством посылки сообщения «INVITE» протокола SIP в базовую сеть 30 подсистемы 30 IMS через сеть 12 AN, как показано посредством маршрута сообщения 48, изображенного на Фиг.2. В последующих схемах последовательности операций вызова, таких, как на Фиг.2-6, единицы оборудования UE (например, единицы оборудования 22, 25 и 26 UE) получают подключение к базовой сети 30 и ее элементам (например, серверу 46 непрерывности SC) через сети AN (например, сети 12, 14 и 16 AN). Однако, для ясности, сети AN со связанными с ними маршрутами сообщений в этих схемах последовательности операций вызова не показываются. Таким образом, на Фиг.2-6 изображаются исключительно логические маршруты сообщений. Соответствующая сеть AN для каждой конкретной последовательности будет упоминаться в описании по мере необходимости. Теперь возвратимся к Фиг.2. Сообщение «INVITE» протокола SIP направляется сквозь сервер 46 непрерывности SC через маршрут 30 сообщения для целей привязки и, кроме того, посылается на оборудование 25 UE через маршрут 52 сообщения, как показано на Фиг.2.

Если оборудование 25 UE принимает многокомпонентный сеанс видеоконференции, вызываемый посредством оборудования 22 UE, то оборудование 25 UE посылает сообщение «200 OK» обратно на сервер 46 непрерывности SC через маршрут 54 сообщения.

После получения сообщения «INVITE» протокола SIP через маршрут 30 или сообщение «200 OK» через маршрут 54, сервер 46 непрерывности SC назначает идентификатор STI для сеанса видеоконференции. Процесс обозначается посредством ссылочного номера 55 на Фиг.2. Целью назначения идентификатора STI является разрешение оборудованию 22 UE позже, при необходимости, ссылаться на этот сеанс подсистемы IMS для передачи сеанса, или любого компонента сеанса, из одной сети AN в другую сеть AN. Идентификатор STI отличает сеанс видеоконференции между оборудованием 22 UE и оборудованием 25 UE от других возможных сеансов, которые могут установить оборудование 22 UE как с оборудованием 25 UE, так и с другими элементами. Кроме того, назначенный идентификатор STI также отличает текущий сеанс от других сеансов, установленных посредством других единиц оборудования UE, но не взаимодействующих с оборудованием 22 UE, если эти сеансы также проходят через этот же сервер 46 непрерывности SC.

В данном варианте осуществления, однажды назначенный посредством сервера 46 непрерывности SC идентификатор STI передается на оборудование 22 UE через ответное сообщение протокола SIP, такое, как сообщение «200 OK», посланное на оборудование 22 UE через базовую сеть 30 подсистемы IMS 30 через сеть 12 AN, по маршрутам 56 и 58 сообщений, соответственно, как показано на Фиг.2. Более конкретно, назначенный идентификатор STI включается в состав нового заголовка протокола SIP в сообщении «200 OK». В данном конкретном примере, новый заголовок протокола SIP называется «P-STI». Следует отметить, что для нового заголовка также могут использоваться и другие названия. Заголовок P-STI, наряду с контентом сообщения, включается в состав сообщения «200 OK», посланного через маршруты 56 и 58 сообщений, как показано на Фиг.2. В данном конкретном примере, контент или значение идентификатора STI помечены как «ABC» на Фиг.2. Например, ABC может являться протоколом установления сеанса - идентификацией ресурса пользователем (SIP-URI) или телефонной идентификацией URI, или идентификатором (ID) диалога сеанса протокола SIP.

Следует отметить, что, если идентификатор STI существует в форме идентификатора (ID) диалога протокола SIP, то не имеется никакой потребности в наличии какого-либо явно заданного заголовка, такого, как заголовок «P-STI» для посылки идентификатора STI на оборудование 22 UE через такое сообщение протокола SIP, как сообщение протокола SIP «200 OK», посланное через маршруты 56 и 58, поскольку существующее сообщение протокола SIP, такое, как сообщение «200 OK» протокола SIP, уже поддерживает неявное включение идентификатора STI в состав различных заголовков.

При приеме идентификатора STI, оборудование 22 UE позднее может использовать идентификатор STI для запроса на передачу сеанса, и, кроме того, как будет описано ниже. После получения сообщения «200 OK», оборудование 22 UE может послать сообщение подтверждения на сервер 46 непрерывности SC через базовую сеть 30 подсистемы IMS через маршруты 57 и 59 сообщения соответственно.

Фиг.3 показывает сценарий, в котором оборудование 25 UE инициирует сеанс видеоконференции, вместо оборудования 22 UE. Снова, как только идентификатор STI назначается посредством сервера 46 непрерывности SC, как показано посредством этапа 55 процесса, информация идентификатора STI может быть послана на оборудование 22 UE в сообщении «INVITE» протокола SIP, посланном через маршруты 60 и 62 сообщений, как показано на Фиг.3. После приема, оборудование 22 UE может послать сообщение «200 OK» в качестве подтверждения через маршруты 61 и 62 сообщений, как описывалось выше. Для краткости, Фиг.3 дополнительно не разъясняется.

Здесь следует отметить, что сообщения и их последовательности, описанные во всех вариантах осуществления, могут иметь изменения, и, кроме того, им могут быть присвоены различные наименования. В отдельных случаях, является возможным посылка промежуточного сообщения, такого, как сообщение «18x» перед посылкой заключительного сообщения «200 OK» вызываемым оборудованием UE, например, в данном случае, оборудованием 25 UE.

Теперь возвращаемся к Фиг.2 в соединении с Фиг.1.

Предположим, что после приема сообщения «200 OK» через маршруты 58 и 56 сообщений, оборудование 22 UE выполняет видеоконференцию с оборудованием 25 UE. В сущности, установлено три компонента мультимедийных данных. Эти три компонента мультимедийных данных обозначаются посредством ссылочных номеров 65, 67 и 69 для голосового #1, видео #2 и видео #3 компонентов сеанса соответственно, как показано на Фиг.4. На Фиг.4 последовательности сообщений, перед установлением туннелей 65, 67 и 69 данных, копируются из Фиг.2.

Предположим, что в определенное время посреди видеоконференции, оборудование 22 UE принимает решение о передаче компонента сеанса связи из сети 12 AN в сеть 14 AN. Может существовать много причин для такой передачи. Иллюстративные причины передачи могут быть основаны на таких факторах, как загрузка сетей, стоимости, определенные политики, установленные в сетях, возможности сетей, предпочтение пользователя оборудования UE, и это лишь некоторые из них.

Чтобы инициировать передачу компонента сеанса, оборудование 22 UE посылает сообщение «INVITE» протокола SIP на сервер 26 непрерывности SC через целевую сеть 14 AN в базовую сеть 30 подсистемы IMS через маршруты 70 и 68 сообщении соответственно, как показано на Фиг.4.

Если идентификатор STI, то есть, идентификатор STI со значением контента ABC, как показано на Фиг.2 и 3, является идентификатором URI протокола SIP или телефонным идентификатором URI, как в предыдущем примере, то новый заголовок идентификатора SIP, заголовок P-STI, наряду со значением контента ABC, также включается в состав сообщения «INVITE» протокола SIP, посылаемого через маршруты 68 и 70. Как упоминалось ранее, в отличие от идентификатора URI протокола SIP или идентификатора SIP телефона, ABC может сильно отличаться от таких идентификаторов (ID), как идентификатор (ID) диалога протокола SIP. Для контента заголовка P-STI, ABC, в данном случае, предполагается такое же значение идентификатора STI, какое было назначено посредством сервера 46 непрерывности SC 46, с помощью этапа 55 процесса, как показано на Фиг.2-4.

Сервер 46 непрерывности SC, после получения сообщения «INVITE» протокола SIP, которое включает в себя идентификатор STI, может сопоставить запрос на передачу сеанса, принятый через сеть 14 AN, с исходным сеансом, установленным по сети 12 AN на Фиг.2-4, и выполнить необходимую операцию по передаче сеанса.

Если идентификатор STI существует в форме, например, идентификатора (ID) диалога протокола SIP, вместо прямолинейного идентификатора URI протокола SIP или идентификатора URI телефона, то возможны несколько других схем передачи идентификатора STI сервера 46 непрерывности SC.

Во-первых, в сообщении «INVITE» SIP, посланном через маршруты 68 и 70, как показано на Фиг.4, в поле запроса идентификатора URI заголовка «INVITE» протокола SIP, в дополнение к заданному запросу идентификатора URI, может быть присоединена новая дополнительная информация о параметре идентификатора URI. Примером является ситуация, показанная на Фиг.5, в которой маршруты 68 и 70 скопированы с Фиг.4, но с отличающимся сообщением «INVITE» протокола SIP. Заданным запросом идентификатора URI, как упомянуто выше, является IP адрес «sc@wireless.com», как показано на Фиг.5. Информация «идентификатор STI: ABC», как показано на Фиг.5, является новой прикрепленной дополнительной информацией о параметрах идентификатора URI, идентифицирующей исходный сеанс, компонент которого должен быть передан.

В другой схеме, если идентификатор (ID) диалога протокола SIP используется в качестве идентификатора STI, то может использоваться заголовок Замен протокола SIP для переноса идентификатора STI в запросе на передачу сеанса. Кроме того, заголовок Замен в заголовке сообщения «INVITE» протокола SIP может быть дополнен новым параметром заголовка. Обычно, заголовок Замен указывает на то, что идентифицированный сеанс должен быть заменен посредством передачи сеанса. Однако контент нового поля параметра заголовка может переносить информацию о том, что этот запрос протокола SIP является запросом на передачу сеанса (например, исключительно частью передачи компонентов мультимедийных данных) вместо замены. Примером является ситуация, показанная на Фиг.6, в которой маршруты 68 и 70 сообщений дублированы из Фиг.4, но с отличающимся сообщением «INVITE» протокола SIP, имеющим область заголовка «замены», в котором контент включает в себя новый параметр заголовка «только для передачи» для указания того, что идентифицированный сеанс подвергается передаче сеанса, вместо замены сеанса.

Мультимедийный сеанс подсистемы IMS может содержать несколько компонентов мультимедийных данных, как описано в вышеупомянутом примере. При выполнении передачи сеанса, оборудование UE подсистемы IMS может выбирать передачу исключительно части сеанса для нового подключения (например, вывода видео #3 из существующего голосового #1 и видео #2). Ниже описываются схемы оборудования UE подсистемы IMS для указания того, какой компонент мультимедийных данных передать.

Теперь вернемся к Фиг.1 и 4. Предположим, что после того, как три компонента 65, 67 и 69 мультимедийных данных установлены, где-то посреди видеоконференции оборудование 22 UE решает передать часть, но не весь сеанс связи из сети 12 AN в сеть 14 AN. В качестве иллюстративного изображения, предположим, что оборудование 22 UE хочет передать компонент видео #3 из сети 12 AN в сеть 14 AN, но поддерживает другие компоненты видео #2 и голосовой #1. Причиной передачи может являться одна или несколько причин, как указано выше.

Оборудование 22 UE может идентифицировать компонент, который будет передан, и информировать сервер 46 непрерывности SC. Снова, имеется несколько возможных схем.

Во-первых, основная часть протокола описания сеанса (SDP) предложения/ответа является включенной в состав основной части каждого сообщения «INVITE» протокола SIP (например, через маршрут 52) и сообщения «200 OK» (например, через маршрут 54) на Фиг.2 и 4, или сообщения «INVITE» протокола SIP (например, через маршруты 60 и 62) или «200 OK» (например, через маршруты 61 и 63) на Фиг.3. Основная часть протокола SDP определяет свойство каждого компонента мультимедийных данных.

Фиг.7 схематично и частично изображает основную часть протокола SDP, которая показывает такую структуру. Фиг.7, как правило, изображает часть основной части протокола SDP сообщений «INVITE» протокола SIP, посланных посредством оборудования 22 UE через маршруты 48, 50 и 52 сообщений (Фиг.2 и 4). На Фиг.7 письмо «m», в основном, задает то, что строка имеет отношение к описанию компонента мультимедийных данных. Например, в первой строке с «m», помимо прочего, устанавливается использование порта с номером «1000» оборудования 22 UE для компонента аудио. Остальная часть строки описывает протокол, используемый в качестве транспортного протокола реального времени/аудио-видео профиля (RTP/AVP), как установлено документом RFC (запрос для комментариев) 3551, изданным рабочей группой по стандартам для сети Интернет (IETF). Также излагается понятие кодера/декодера (кодирования и декодирования) компонента мультимедийных данных.

В первой схеме передачи компонента сеанса, компоненты мультимедийных данных на Фиг.7 связаны с определенными значениями или значениями индекса, которые могут быть назначены. Назначение определенных значений может являться явно заданным или неявно заданным. Иллюстративное явно заданное назначение может быть основано на предварительно согласованной методологии, такой, как на основе порядка появления компонентов мультимедийных данных в протоколе SDP. Например, в звуковом компоненте, индекс «#1» назначается этому компоненту. Одному видео компоненту назначается индекс «#2», а другому видео компоненту назначается индекс «#3». Все объекты, такие, как сервер 46 непрерывности SC и единицы оборудования 22 и 25 UE, связанные с многокомпонентным сеансом, используют одну и ту же методологию назначения значения индекса. В силу этого, в данном случае, как оборудование 22 UE, так и сервер 46 непрерывности SC осведомлены о значениях индекса, как соответствующих компонентам мультимедийных данных основной части протокола SDP в создаваемом сообщении протокола SIP, таком, как, показанное на Фиг.7. Все вовлеченные элементы перенимают ту же самую схему назначения, таким образом, предоставляя последовательность предложения/ответа во время последующих обменов сообщениями протокола SIP.

Определенные или заданные значения также могут быть назначены неявно. Определенные значения не могут явно переноситься в пределах основной части протокола SDP, непосредственно во время обменов предложениями/ответами протокола SIP. Однако основные части протоколов SDP последующих сообщений протокола SIP всегда поддерживают один и тот же порядок перечисления компонентов мультимедийных данных. Каждый затрагиваемый элемент, такой, как сервер 46 непрерывности SC или единицы оборудования 22 или 25 UE, связанные с многокомпонентным сеансом, может получать определенные значения из последовательного порядка перечисления компонентов мультимедийных данных в последующих сообщениях протокола SIP, причем порядок перечисления является таким же, как в первоначальном сообщении протокола SIP. Например, как показано на Фиг.7, звуковой компонент с номером порта 1000, появляется первым из остальных компонентов. В силу этого, определенное значение #1 может быть получено посредством всех затрагиваемых элементов. В качестве другого примера, видео компонент с номером порта 1004, изображенный на Фиг.7, появляется третьим из остальных компонентов в порядке перечисления. Следовательно, определенное значение #3 может быть получено посредством всех затрагиваемых элементов.

Теперь возвращаемся к первой схеме передачи компонента сеанса. С заданным или определенным значением как явно, так и неявно назначенным, если оборудование 22 UE делает запрос на передачу одного компонента, видео #3 в данном примере, то оборудование 22 UE может осведомить сервер 46 непрерывности SC о таком запросе посредством посылки на сервер 46 непрерывности SC сообщения, включающего в себя назначенное определенное значение компонента (то есть, #3) в пределах исходного сеанса через новый атрибут протокола SDP, в данном примере, «orig-mid», как графически и иллюстративно показано на Фиг.8. На Фиг.8 строка атрибута «a» задает атрибут компонента мультимедийных данных, непосредственно над строкой. Следует отметить, что, очевидно, возможны и другие названия нового атрибута протокола SDP. Более конкретно, в данном примере, оборудование 22 UE может включать в себя определенное значение (то есть #3) в таком сообщении «INVITE» протокола SIP, посланном на сервер 46 непрерывности SC, как сообщение, посланное через маршруты 68 и 70, изображенные на Фиг.4-6. Иллюстративное сообщение «INVITE» протокола SIP, как упомянуто выше, изображено на Фиг.8, причем в этом сообщении основная часть протокола SIP показывается частично с назначенным определенным значением компонента для передачи, обозначенным как #3, с использованием нового атрибута протокола SDP «orig-mid» и новой строки мультимедийных данных, описывающей компонент для передачи, как имеющий вновь назначенный номер порта «2000».

Что касается сервера 46 непрерывности SC, сравнивая описания мультимедийных данных предыдущего и недавно принятого сообщения «INVITE» протокола SIP и внимательного рассмотрения нового атрибута каждого назначенного индекса сообщений, сервер 46 осведомлен о том, какой компонент должен быть передан. Затем, сервер 46 непрерывности SC предпринимает действия посредством передачи обозначенного компонента на новое подключение, при поддержке оставшихся компонентов исходным подключением.

В другой схеме, вместо описанной выше методологии, оборудование 22 UE осведомляет сервер 46 непрерывности SC о компонентах для передачи посредством посылки на сервер 46 непрерывности SC сообщения без какого-либо явного или неявного значения индекса или какого-либо нового атрибута протокола SDP. Вместо этого оборудование 22 UE включает в состав основной части протокола SDP описание для передачи сеанса отличным от описанной ранее схемы способом.

Предположим изначально, что компоненты мультимедийных данных задаются в основной части исходного сообщения «INVITE» протокола SIP, посланного посредством оборудования 22 UE через маршруты 48, 50 и 52 сообщений (Фиг.2 и 4), как показано на Фиг.9.

В данной схеме, все компоненты мультимедийных данных исходного сеанса включены в состав запроса на передачу сеанса, посланного через маршруты 68 и 70 в том же самом порядке, в котором они появляются в протоколе SDP, согласованном перед исходным сеансом. Для компонентов, которые не должны передаваться, оборудованию 22 UE назначается предварительно определенное значение, например «0» номера порта, соответствующего компонентам мультимедийных данных. С другой стороны, для компонентов, которые должны передаваться, оборудованию 22 UE назначается номер порта, как при нормальной обработке предложения/ответа протокола SDP. Снова, оборудование 22 UE может передавать такую информацию в таком сообщении «INVITE» протокола SIP, как сообщение, посланное через маршруты 68 и 70, изображенные на Фиг.4-6. На Фиг.10, схематично показывается основная часть протокола SDP в сообщении «INVITE» протокола SIP, посланном через маршруты 68, и 70, в котором во всех компонентах мультимедийные данные в исходном сеансе включены в состав в таком же порядке. Компонентам, которые не предназначаются для передачи оборудованием 22 UE, назначается предварительно определенное значение «0», тогда как компоненту, который предназначается для передачи, назначается нормальное значение номера порта, например «2008».

Снова, для сервера 46 непрерывности SC, сравнивая описания мультимедийных данных предыдущего и недавно принятого сообщения «INVITE» протокола SIP, в связи с тем, что новое сообщение «INVITE» протокола SIP делает запрос на передачу сеанса и указывает предварительно определенное значение 0 для компонентов мультимедийных данных аудио #1 и видео #2, сервер 46 непрерывности SC понимает, что данные два компонента мультимедийных данных не будут переданы. Тогда, сервер 46 непрерывности SC передает исключительно компонент #3 видео на новое подключение, где данному компоненту мультимедийных данных назначается номер порта «2008».

Фиг.11 является блок-схемой, обобщающей процессы в описанном выше иллюстративном примере, как выполняемые посредством такого пользовательского элемента, как оборудование 22 UE.

Фиг.12 является другой блок-схемой, обобщающей процессы в описанном выше иллюстративном примере, как выполняемые посредством такого сетевого элемента, как сервер 46 непрерывности SC.

Фиг.13 показывает часть варианта реализации устройства выполнения схем и процессов в аппаратных средствах описанным выше способом. Устройство канала связи обозначается посредством ссылочного номера 90, и оно может быть реализовано в таком пользовательском элементе, как единицы оборудования 22 и 25 UE, или таком сетевом э