RU2753302C1

RU2753302C1 - Способ, система и объект для сеанса передачи мультимедиа в инфраструктуре ims

Info

Publication number: RU2753302C1
Application number: RU2020121480A
Authority: RU
Inventors: Роджер Аугуст Каспар Йозеф НОЛДУС
Original assignee: Телефонактиеболагет Лм Эрикссон (Пабл)
Priority date: 2017-12-29
Filing date: 2017-12-29
Publication date: 2021-08-12
Also published as: EP3732841A1; WO2019129359A1; CN111492633B; EP3732841B1; US11463485B2; AR115197A1; CN111492633A; US20210058434A1

Abstract

Изобретение относится к беспроводной связи. Для осуществления способа обеспечения ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа в инфраструктуре (150) Мультимедийной Подсистемы на базе Интернет-Протокола (IP) (IMS), инфраструктура (150) содержит Пользовательское Оборудование (UE) (100A) вызывающей стороны, UE (100B) вызываемой стороны, первый тракт (111), выполненный с возможностью передачи сеанса передачи мультимедиа между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны через функциональный блок шлюза (105A). Во время установления сеанса передачи мультимедиа IMS-объект (116A) извлекает абонентскую информацию, информацию, ассоциированную с вызовом UE (100A) вызывающей стороны. Инфраструктура (150) выполняет следующие этапы: IMS-объект (116A) снабжает функциональный блок шлюза (105A) идентификатором, ассоциированным с сеансом вызова UE (100A) вызывающей стороны. Идентификатор идентифицирует вставку сигнатуры сеанса в сеанс передачи мультимедиа. Функциональный блок шлюза (105A) использует идентификатор для составления сигнатуры сеанса и вставляет составленную сигнатуру сеанса в сеанс передачи мультимедиа в первом тракте (111) таким образом, что оценка сигнатуры сеанса обеспечивает ассоциирование сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа. Функциональный блок шлюза (105А) содержит блок обработки, модули приёмника, обработки и вставки. Заявлен машиночитаемый носитель, содержащий компьютерную программу (603) для обеспечения ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа. Достигается технический результат – обеспечение возможности предусматривать несовместный трафик плоскости управления и плоскости пользователя, за счет обнаружения конкретной сигнатуры сеанса передачи мультимедиа и ее характеристик. 5 н. и 10 з.п. ф-лы, 8 ил.

Description

Область техники

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

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

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

В целях оптимизации тракта передачи сеанса передачи мультимедиа непрерывно совершенствуется сетевая архитектура Проекта партнерства 3-го поколения (3GPP), Четвертого Поколения (4G) и Пятого Поколения (5G), например, чтобы позволить сеансу передачи мультимедиа «вырваться» на ранней стадии вблизи абонентского терминала или Пользовательского Оборудования (UE). При рассмотрении, например, обычного вызова с поддержкой Речевой Связи в сетях Долгосрочного Развития (VoLTE) соединение в Пакетной Сети Передачи Данных (PDN) устанавливается между UE и PDN-Шлюзом (PDN-Gw). В рамках PDN-Соединения устанавливается множество каналов Развитой Пакетной Системы (EPS):

1. Так называемый «используемый по умолчанию» EPS-канал скомпонован для переноса пакетов управления вызовами. Этот канал концептуально относится к плоскости управления. Протокол Информации Сеанса (SIP) является широко реализуемым примером протокола, применяемого в используемом по умолчанию канале применительно к Мультимедийной Подсистеме на базе Интернет-Протокола (IP) (IMS);

2. Так называемый «выделенный» EPS-канал, скомпонованный для переноса (поддержания) сеанса передачи мультимедиа для вызова, содержащего речевую компоненту; этот канал концептуально относится к плоскости пользователя. Протокол Реального Времени (RTP) и Протокол Управления Передачей в Реальном Времени (RTCP) являются примерами реализаций протоколов, применяемых в плоскости пользователя;

3. Еще один выделенный, но необязательный EPS-канал - это канал, скомпонованный для переноса видеокомпонентов вызова в случае видеовызова, и он также относится к плоскости пользователя. RTP и RTCP являются также протоколами, которые могут использоваться для поддержки видео.

PDN-Gw содержится в Опорной Сети с Коммутацией Пакетов (EPC). EPC определяется как EPS без сети Доступа. И плоскость управления, и плоскость пользователя переносятся вплоть до PDN-Gw через единое PDN-Соединение. От PDN-Gw плоскость управления и плоскость пользователя разделяются:

1. Сигнализация плоскости управления маршрутизируется к функции (функциональному блоку) Граничного Шлюза Сеанса (SBG) и маршрутизируется оттуда через Контроллер Шлюза Сеанса (SGC), содержащийся в SBG, через опорную сеть IMS. SBG находится на периферии IMS-сети;

2. Пакеты, проходящие в плоскости пользователя, маршрутизируются к Функции (функциональному блоку) Граничного Шлюза (BGF), также содержащейся в SBG, находящийся на периферии IMS-сети. BGF управляется SGC.

Предпринимались попытки оптимизации маршрутизации плоскости пользователя путем размещения PDN-Gw и BGF ближе к сети доступа, т.е., ближе к eNodeB (для доступа в LTE) или ближе к Wifi-сети доступа (для вызова через Wifi). PDN-Gw и BGF могут быть объединены или совмещены в eNodeB для достижения оптимального тракта.

Объединение последних объектов может стать реализуемым, когда IMS и EPC развертываются в виде виртуализованных сетей. PDN-Gw (и другие функциональные объекты EPC) и BGF развертываются в виде Виртуализованной Сетевой Функции (VNF), обозначаемой также как виртуальный PDN-GW (vPDN-Gw) и виртуализованная BGF (vBGF). При условии, что vPDN-Gw и vBGF продолжают иметь заданные эталонные точки для связи с другими (виртуализованными) функциональными объектами, это оптимизированное размещение PDN-Gw и BGF не влияет на фундаментальную топологию IMS-сети. Фактически оператор может продолжать иметь PDN-Gw в EPC для универсального интернет-доступа, и в то же время логический PDN-Gw и логический BGF, совмещенные с eNodeB или расположенные поблизости от него, для услуг IMS-связи.

Когда IMS-абонент подключается к EPC, устанавливается PDN-Соединение с идентификатором Имени Точки Доступа (APN), таким как «ims», чтобы сослаться на имя PDN-Gw и определить, какой тип сетевого соединения должен быть создан.

Узел Управления Мобильностью, MME, содержащийся в EPC, может для этого PDN-Соединения выбирать (логический) PDN-Gw, который близок к местоположению UE вызывающей или вызываемой стороны. Аналогичным образом, когда сеанс IMS-связи устанавливается от этой UE вызывающей или вызываемой стороны или к ней, SBG может выбирать BGF для плоскости пользователя, которая близка к местоположению абонента. Желаемый результат выбора PDN-Gw и BGF, близких к конечному пользователю, состоит в том, что плоскость пользователя может маршрутизироваться эффективно с минимальной задержкой и минимальным использованием сетевых ресурсов.

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

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

Совместная маршрутизация плоскости управления и плоскости пользователя для сеансов связи, которые проходят через коммутируемую сеть, предусматривается Ассоциацией Глобальной Системы Мобильной Связи (GSMA).

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

При LBO находящийся в роуминге IMS-абонент подключен к гостевой EPS (не домашней сети) с APN = «ims» таким образом, что установление PDN-Соединения маршрутизируется к PDN-Gw в этой гостевой EPS. Гостевая PDN-Gw обеспечивает Локальный Прорыв. EPC в гостевой сети функционально соединена с IMS-сетью в этой самой гостевой сети. Управляющая сигнализация SIP от находящегося в роуминге абонента маршрутизируется к SBG в этой гостевой IMS-сети. Аналогичным образом, плоскость пользователя маршрутизируется к тому же SBG в этой гостевой EPC. Гостевая сеть может также обозначаться как «внешняя» сеть.

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

Существует дилемма при оптимизации маршрутизации плоскости пользователя для находящегося в роуминг абонента. Как указано, плоскость управления должна маршрутизироваться к объектам домашней IMS, таким как Обслуживающая Функция Управления Вызовом/Состоянием S-CSCF обслуживаемого находящегося в роуминге абонента.

Реализация оптимизированной маршрутизации плоскости пользователя зависит от пункта назначения вызова. Например, когда вызов от находящегося в роуминге абонента устанавливается к абоненту пункта назначения, который является абонентом гостевой IMS-сети (являющейся его домашней сетью), оптимизированная маршрутизация плоскости пользователя осуществляется через локальную сеть передачи, например, к SBG, который выбирается IMS-сетью абонента пункта назначения в гостевой IMS-сети. Эффект состоит в том, что плоскость пользователя маршрутизируется через сетевую инфраструктуру, отличную от сетевой инфраструктуры плоскости управления при том, что:

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

2. Плоскость пользователя маршрутизируется внутри в локальной сети передачи, расположенной в гостевой сети.

Данная ситуация, в общем, рассматривается как нежелательная, поскольку в результате гостевая IMS-сеть содействует плоскости управления в ее SIP-передачах без RTP-передачи, в явной форме сопровождаемой ее соответствующей плоскостью управления. Данную ситуацию может рассматривать как «отсутствие управления» во всей плоскости пользователя.

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

1. Плоскость управления маршрутизируется от гостевой IMS-сети, где находится вызывающая сторона, к домашней IMS-сети вызывающей стороны и оттуда к домашней сети вызываемой стороны;

2. Плоскость пользователя маршрутизируется от гостевой IMS-сети вызывающей стороны через сеть передачи к домашней сети вызываемой стороны.

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

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

Чтобы обеспечить решение проблемы наличия несопровождаемой плоскости пользователя с ассоциированной сопровождающей плоскостью управления, разработана методология принудительной маршрутизации плоскости управления назад к гостевой IMS-сети вызывающей стороны и оттуда маршрутизации плоскости управления и плоскости пользователя вместе в качестве сопровождающих плоскостей через коммутируемую сеть к домашней сети вызываемой стороны. Этот способ известен как: Архитектура Роуминга для VoicE через IMS с Локальным Прорывом (RAVEL).

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

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

Целью представленных вариантов осуществления является обеспечение способа, системы и объекта для обеспечения ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа в транспортной сети Интернет-Протокола (IP).

В первом аспекте решения предлагается способ, действующий в инфраструктуре Мультимедийной Подсистемы на базе Интернет-Протокола (IP) (IMS), где задача состоит в обеспечении ассоциирования сеанса передачи мультимедиа с оператором, который начинает, поддерживает или упрощает сеанс передачи мультимедиа. Инфраструктура содержит Пользовательское Оборудование (UE) вызывающей стороны, UE вызываемой стороны, первый тракт, выполненный с возможностью действия в качестве транспортной IP-сети. Транспортная IP-сеть выполнена с возможностью передачи сеанса передачи мультимедиа между UE вызывающей стороны и UE вызываемой стороны через функцию шлюза, которая может представлять собой Граничный Шлюз Сеанса, действующий в инфраструктуре Мультимедийной Подсистемы на базе IP.

При инициализации или во время сеанса передачи мультимедиа IMS-объект, такой как сервер приложений Мультимедийной Телефонии (MMTel-AS), извлекает абонентскую информацию из абонентской базы данных, такой как Опорный Абонентский Сервер (HSS), связанный с UE вызывающей стороны. Способ осуществляется в соответствии с рядом этапов:

- в качестве этапа IMS-объект, такой как MMTel-As, обеспечивает функцию шлюза, такую как SBG, с идентификатором, который ассоциирован с сеансом вызова UE вызывающей стороны. Этот идентификатор идентифицирует, должна ли произойти вставка сигнатуры сеанса в сеансе передачи мультимедиа, и содержит любую информацию о сеансе UE вызывающей стороны. Прием идентификатора в SBG может выполняться объектом Контроллера Шлюза Сеанса (SGC), содержащимся в логическом SBG.

- в качестве еще одного этапа функция шлюза, такая как SBG, использует идентификатор для составления сигнатуры сеанса. Составление сигнатуры сеанса может выполняться либо SGC, либо объектом Функции Граничного Шлюза (BGF).

- в качестве еще одного этапа функция шлюза, такая как SBG, вставляет составленную сигнатуру сеанса в сеанс передачи мультимедиа в первом тракте, таком как транспортная IP-сеть.

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

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

Инфраструктура содержит Пользовательское Оборудование (UE) вызывающей стороны, UE вызываемой стороны, первый тракт, выполненный с возможностью действия в качестве транспортной IP-сети. Транспортная IP-сеть выполнена с возможностью передачи сеанса передачи мультимедиа между UE вызывающей стороны и UE вызываемой стороны через функцию шлюза, которая может представлять собой Граничный Шлюз Сеанса, действующий в Инфраструктуре Мультимедийной Подсистемы на базе IP.

- в качестве этапа функция шлюза, такая как SBG, принимает идентификатор, который ассоциирован с сеансом вызова UE вызывающей стороны, от IMS-объекта, такого как MMTel-AS. Этот идентификатор идентифицирует, должна ли происходить вставка сигнатуры сеанса в сеанс передачи мультимедиа, и содержит любую информацию о сеансе UE вызывающей стороны. Прием идентификатора в SBG может выполняться объектом Контроллера Шлюза Сеанса (SGC), содержащимся в логическом SBG.

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

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

Инфраструктура дополнительно содержит Пользовательское Оборудование (UE) вызывающей стороны, UE вызываемой стороны, первый тракт, выполненный с возможностью действия в качестве транспортной IP-сети. Транспортная IP-сеть выполнена с возможностью передачи сеанса передачи мультимедиа между UE вызывающей стороны и UE вызываемой стороны через функцию шлюза, которая может представлять собой Граничный Шлюз Сеанса, действующий в инфраструктуре Мультимедийной Подсистемы на базе IP. Функция шлюза содержит блок обработки, который выполнен с возможностью инициирования исполнения функцией шлюза:

- приема идентификатора, который ассоциирован с сеансом вызова UE вызывающей стороны, от IMS-объекта, такого как MMTel-AS. Этот идентификатор идентифицирует, должна ли произойти вставка сигнатуры сеанса в сеанс передачи мультимедиа, и содержит любую информацию по сеансу UE вызывающей стороны. Прием идентификатора в SBG может выполняться объектом Контроллера Шлюза Сеанса (SGC), содержащийся в логическом SBG.

- использования или обработки идентификатора для составления сигнатура сеанса. Составление сигнатуры сеанса может выполняться либо SGC, либо объектом Функции Граничного Шлюза (BGF).

- вставки составленной сигнатуры сеанса в сеанс передачи мультимедиа в первом тракте, таком как транспортная IP-сеть.

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

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

Инфраструктура, в которой находится функция шлюза, дополнительно содержит Пользовательское Оборудование (UE) вызывающей стороны, UE вызываемой стороны, первый тракт, выполненный с возможностью действия в качестве транспортной IP-сети. Транспортная IP-сеть выполнена с возможностью передачи сеанса передачи мультимедиа между UE вызывающей стороны и UE вызываемой стороны через функцию шлюза, которая может представлять собой Граничный Шлюз Сеанса, действующий в инфраструктуре Мультимедийной Подсистемы на базе IP. Функция шлюза содержит блок обработки, который выполнен с возможностью инициирования исполнения функцией шлюза:

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

- приема идентификатора, который ассоциирован с сеансом вызова UE вызывающей стороны, от IMS-объекта, такого как MMTel-AS. Этот идентификатор идентифицирует, должна ли произойти вставка сигнатуры сеанса в сеанс передачи мультимедиа, и содержит любую информацию по сеансу UE вызывающей стороны. Прием идентификатора в SBG может выполняться объектом Контроллера Шлюза Сеанса (SGC), содержащимся в логическом SBG.

- использования или обработки идентификатора для составления сигнатуры сеанса. Составление сигнатуры сеанса может выполняться либо SGC, либо объектом Функции Граничного Шлюза (BGF).

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

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

- модуля приемника для приема идентификатора, который ассоциирован с сеансом вызова UE вызывающей стороны, от IMS-объекта, такого как MMTel-AS. Этот идентификатор идентифицирует, должна ли произойти вставка сигнатуры сеанса в сеанс передачи мультимедиа, и содержит любую информацию по сеансу UE вызывающей стороны. Прием идентификатора в SBG может выполняться объектом Контроллера Шлюза Сеанса (SGC), содержащимся в логическом SBG.

- модуля обработки для составления или обработки сигнатуры сеанса на основе принятого идентификатора. Составление сигнатуры сеанса может выполняться либо SGC, либо объектом Функции Граничного Шлюза (BGF).

- модуля вставки для вставки составленной сигнатуры сеанса в сеанс передачи мультимедиа в первом тракте, таком как транспортная IP-сеть.

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

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

Идея изобретения описывается далее на примере со ссылкой на перечисленные чертежи;

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

Фиг. 2 схематически детализирует часть системы, изображенной на фиг. 1;

Фиг. 3A схематически отображает диаграмму сигнализации;

Фиг. 3B схематически отображает еще одну диаграмму сигнализации;

Фиг. 4 схематически отображает еще одну деталь, изображенную на фиг. 1;

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

Фиг. 6 схематически иллюстрирует пример компьютерного программного продукта, содержащего машиночитаемый носитель, в соответствии с вариантом осуществления.

Фиг. 7 схематически иллюстрирует пример функциональных компонентов функции шлюза.

Подробное описание

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

Фиг. 1 схематически иллюстрирует систему 150 связи, в которой должен применяться способ. В общих чертах показаны сеть доступа, Расширенная Пакетная Опорная сеть (EPC) и инфраструктура сети Мультимедийной Подсистемы на базе Интернет-Протокола (IP) (IMS).

Фиг. 1 иллюстрирует ситуацию, в которой Пользовательское Оборудование (UE) 100A вызывающей стороны имеет сеанс передачи мультимедиа с UE 100B вызываемой стороны через IMS-сеть, при этом плоскость управления маршрутизируется различным образом от плоскости передачи мультимедиа, при этом обе UE находятся в роуминге. UE 100A вызывающей стороны соединена через канал 101A доступа с сетью 102A доступа, такой как сеть доступа Долгосрочного Развития (LTE). Сеть 102A доступа соединена с использованием Соединения 103A с Шлюзом 104A Пакетной Сети Передачи Данных (PDN-Шлюзом, PDN-Gw).

PDN-Gw 104A имеет двойное соединение с Граничным Шлюзом Сеанса (SBG) 105A. SBG 105A соединен с PDN-Gw 104A через канал 109A для переноса плоскости управления, в общем, передающей сообщения Протокола Инициирования Сеанса (SIP). SBG 105A также соединен с PDN-Gw 104A через канал 110A для переноса сеанса передачи мультимедиа, представляющего плоскость пользователя, в общем, передающую сообщения Протокола Реального Времени (RTP). RTP определяется в Запросе на Комментарии (RFC) 3550 Инженерной Группой по Развитию Интернета (IETF).

SBG 105A содержит Контроллер Шлюза Сеанса (SGC) 106A и Функцию Граничного Шлюза (BGF) 107A. SGC 106A предназначен для поддержки плоскости управления и для управления BGF 107A через канал 108A.

Хотя объекты SBG, SGC и BGF отображены как объекты, эти объекты могут быть реализованы в виде аппаратных средств, программных средств или комбинации обоих. Решения, например, в облачной среде выполнения являются примером реализации. SBG 105A может содержать некоторое число SGC 106A и BGF 107A, где, в общем, SGC 106A предназначен для выбора BGF 107A, которая является наиболее подходящей по отношению к местоположению UE 100A вызывающей стороны. В тех случаях, когда в данном объяснении или формуле изобретения SBG (105A) принимает, передает, обрабатывает, сохраняет или извлекает информацию плоскости пользователя или плоскости управления, следует понимать, что эти действия выполняет соответствующая BGF 107A или SGC 106A.

SGC 106A также соединен с коммутируемой сетью, также известной как IPX-сеть (IPX-A) 112A, выполненной с возможностью передачи сообщений по плоскости управления. IPX-A-сеть соединена с IMS-сетью (IMS-A) 114A, которая имеет соединения с объектом Абонентской базы данных, Домашней Абонентской Системой (HSS-A) 115A и Сервером Приложений Мультимедийной Телефонии (MMTel-AS) 116A.

Как показано, тракт управления маршрутизируется от UE 100A вызывающей стороны к IMS-сети - IMS-A 114A. От IMS-A 114A имеется канал плоскости управления к IMS-сети UE 100B вызываемой стороны. IMS-A 114A соединена с возможностью связи с IMS-B 114B - Домашней сетью UE 100B вызываемой стороны.

В отношении сеанса передачи мультимедиа, BGF 107A соединена с транспортной IP-сетью 111, которая маршрутизирует плоскость передачи мультимедиа в направлении BGF 107B, связанной с UE 100B вызываемой стороны. Транспортная сеть помимо прочего выполнена с возможностью передачи RTP-сообщений.

Фиг. 1 иллюстрирует всю сетевую инфраструктуру 150, где вызываемая сторона с UE 110B вызываемой стороны иллюстрируется как концептуальное отражение сетевой инфраструктуры UE 110A вызывающей стороны. Описания объектов канала 101B вызываемой стороны, сети 102B доступа, соединения 103B, PDN-Gw 104B, SBG 105B, SGC 106B, BGF 107B, канала 108B, канала 109B, канала 101B, IPX-сети 112B, IMS-сети 114B, объекта HSS-B 115B Абонентской базы данных, MMTel-AS 116B все же соответствуют описанию соответствующих объектов 101A, 102A, 103A, 104A, 105A, 106A, 107A, 108A, 109A, 1010A, 112A, 114A, 115A и 116A вызывающей стороны.

Как указано в разделе уровня техники, в ситуации, в которой развертываются IPX-сети 112A, 112B, на предшествующем уровне техники плоскость управления маршрутизировалась совместно с плоскостью передачи мультимедиа. Фиг. 1 показывает ситуацию, в которой плоскость управления не маршрутизируется с плоскостью передачи мультимедиа, которая маршрутизируется в отдельной транспортной IP-сети 111. Хотя фиг. 1 показывает несовместную маршрутизацию плоскостей управления и передачи мультимедиа, представленное решение может также применяться в реализациях совместно маршрутизируемых плоскостей управления и передачи мультимедиа.

Фиг. 2 схематически детализирует часть системы, изображенной на фиг. 1, в которой объясняется развертываемый способ. SBG 105A содержит SGC 106A и BGF 107A. SGC106A управляет BGF 107A через канал 108A, развертывающий, например, Протокол Управления Шлюзами H.248, как определено Международным Союзом Электросвязи (ITU).

Плоскость управления связывается с UE 100A вызывающей стороны через канал 109A с SGC 106A. Плоскость управления также связывается с IMS-сетью 114A через IPX-сеть IPX-A 112A, несущую SIP-сеанс, содержащий сообщения Протокола Описания Сеансов (SDP). Плоскость пользователя связывается с UE 100A вызывающей стороны через канал 110A и связывается через BGF 107A к транспортной IP-сети 111.

Схематически пакеты, содержащие данные, отправляемые по плоскости пользователя через BGF 107A, отображены на временной диаграмме 201 как RTP-пакеты. Кроме того, пакеты Протокола Управления Передачей в Реальном Времени (RTCP), отображенные на временной диаграмме 202, передаются в плоскости пользователя, которая обеспечивается BGF 107A, и передаются в направлении UE 101B вызываемой стороны. RTCP-пакеты применяются для любой обратной связи, синхронизации, управления пользовательским интерфейсом, связи с задержкой, флуктуаций сигнала и перегрузки в канале связи. RTCP не передает пакеты сеанса передачи мультимедиа, как предусматривается RTP.

RTCP определен в Рабочем Предложении (RFC) 3550, определенном Инженерной Группой по Развитию Интернета (IETF). В качестве альтернативы при необходимости может развертываться более безопасная версия RTCP, такая как Защищенный Протокол Реального Времени (SRTP) и его управляющий протокол - защищенный RTCP (SRTCP), обеспечивающие шифрование и/или аутентификацию потока, такую, как определено RFC 3711.

Термин «RTP-поток», в общем, относится к комбинации передачи RTP-сообщения и ассоциированной передачи RTCP-сообщения. RTP-сообщения и RTCP-сообщения, согласно замыслу, передаются по одному и тому же IP-адресу (и исходят из одного и того же IP-адреса), но используют различные номера портов для начального IP-адреса и IP-адреса пункта назначения.

Для сеанса передачи мультимедиа абонент-абонент, в общем, имеются два одновременно применяемых потока RTP-сеанса передачи мультимедиа, по одному в каждом направлении. На каждом конце IP-адрес и порт, от которого отправляется RTP/RTCP, является также IP-адресом и портом, на котором принимается RTP/RTCP.

Когда находящаяся в роуминге UE 100A вызывающей стороны вызывает UE 100B вызываемой стороны, SIP-сеанс устанавливается от UE 100A вызывающей стороны к UE 100B вызываемой стороны. В соответствии с этим решением, процедура установления SIP-сеанса расширяется с использованием следующего аспекта: SIP-сообщение, отправляемое к вызывающей стороне, несущей SDP-ответ, который используется для Инициирования Сеанса передачи мультимедиа, содержит также инструкцию с учетом SIP-сеанса в плоскости пользователя.

SGC 106A, обслуживающий UE 100A вызывающей стороны, в соответствии с предшествующим уровнем техники направляет SDP-ответ к BGF 107A через канал 108A. Инструкция, которая содержится в SIP-сообщении, содержащем SDP-ответ, оказывает такое действие, что SGC 106A создает «идентификатор сеанса» и передает идентификатор сеанса в BGF 107A. BGF 107A периодически передает идентификатор сеанса в идентификаторе RTCP-сеанса RTP-потока, проходящего через BGF 107A, в направлении к BGF 107B, ассоциированной с UE 100B вызываемой стороны, через транспортную IP-сеть 111.

RTP-поток сеанса передачи мультимедиа, который маршрутизируется от BGF 107A в направлении UE 100B вызываемой стороны, дополняется идентификатором RTCP-сеанса, действующим как «сигнатура» для сеанса, обеспечиваемого RTP-потоком, называемая далее «сигнатурой сеанса». Ввиду наличия этой сигнатуры сеанса плоскость пользователя может проходить по оптимизированному маршруту, например, через транспортную IP-сеть 111. Фактически этот способ «подписания» плоскости пользователя, представленной RTP-потоком, может применяться также в случаях, когда плоскость пользователя остается в пределах собственной сети оператора. Под «оператором» подразумевается оператор Опорной Наземной Сети Мобильной Связи Общего Пользования (HPLMN) обслуживаемого абонента UE 100A вызываемой стороны.

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

Фиг. 3A схематически представляет диаграмму сигнализации инициирования процедуры установления вызова в соответствии с представленным решением. Предполагается, что абонент, ассоциированный с UE 100A вызывающей стороны, предусмотрен в абонентской базе данных HSS-A 115A, а абонент, ассоциированный с UE 100B вызываемой стороны, предусмотрен в абонентской базе данных HSS-B 115B соответственно.

Когда UE 100A, 100B регистрируется в соответствующей IMS-сети 114A, 114B, информация о подписке передается от соответствующего HSS 115A, 115B к соответствующей Обслуживающей Функции Управления Вызовом/Состоянием (S-CSCF) IMS-узла, где поднабор этих элементов подписки передается от соответствующей S-CSCF к соответствующему SBG 105A, 105B. Примеры таких элементов, например:

- Идентификатор UE 100A вызывающей стороны (URI, MSISDN), для которого устанавливается этот вызов;

- Домашняя сеть UE 100A вызывающей стороны, и

- Идентификаторы SIP-сеансов, такие как идентификатор Вызова, метка «От», метка «К».

В данном решении предлагается, чтобы профиль услуги IMS, содержащийся в виде непрозрачных данных в HSS 115A, 115B, расширялся с помощью идентификатора, реализуемого элементом подписки «сигнатура сеанса» для плоскости пользователя. Этот элемент подписки передается от HSS 115A, 115B к соответствующей S-CSCF, а также от S-CSCF к соответствующему SBG 105A, 105B. На фиг. 3A и 3B S-CSCF, ассоциированная с UE 100A вызывающей стороны, упоминается со ссылкой на ссылочную позицию 114A, чтобы показать, что этот объект содержится в IMS-сети 114A.

В качестве примера еще одна процедура объясняется для ситуации, в которой UE 100A вызывающей стороны осуществляет вызов, хотя процедура может также применяться с необходимыми изменениями, когда UE 100A является вызываемой, UE 100B является вызываемой или является вызывающей. Передача элемента подписки «сигнатуры сеанса» происходит в рамках существующих процедур и обмена сообщениями. А именно:

- Элемент подписки переносится как Пара «Атрибут-Значение» (AVP) в Diameter-сообщении Ответа Регистрации в Сервере (SAA) от HSS 115A к S-CSCF; и

- Элемент подписки также переносится как SIP-заголовок в 200 Ok [сообщение SIP-Регистра] от S-CSCF к SBG 105A.

Благодаря перечисленным выше этапам процедуры SBG 105A информируется, что RTP-сеансы от UE 100A вызывающей стороны должны дополняться сигнатурой сеанса.

Вставка сигнатуры сеанса в RTP-поток плоскости пользователя может управляться для каждого сеанса вызова для UE 100A, 100B вызывающей или вызываемой стороны. Вставка сигнатуры сеанса не всегда требуется в зависимости от фактического установления вызова или, например, от прохождения RTP-потока плоскости пользователя для этого вызова. Маршрут, который будет пройден плоскостью пользователя, определяется во время установления вызова.

На фиг. 3A и 3B SBG 105 представлен таким образом, что он содержит BGF 107A, что показывает, что он управляет BGF с помощью входящего в его состав SGC 105A.

Установление вызова следует стандартным процедурам, включая сквозную Invite-транзакцию 301, 305, 307, 308, 309 SIP и резервирование 303 ресурсов для UE 100A вызывающей стороны к UE 100B вызываемой стороны. После Invite-транзакции SIP в направлении UE 100B вызываемой стороны выполняется Сквозная сигнализация 311A и 311B, такая как сигнализация, относящаяся к резервированию ресурсов, (раннему) установлению диалога и изменению.

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

Когда 200 Ok [Invite-сообщение SIP] 351 принимается с направления UE 100B вызываемой стороны, S-CSCF 114A IMS-сети, ассоциированной с вызывающей стороной, информирует 353 MMTel-AS 116A, ассоциированный с UE 100A вызывающей стороны, что на установление вызова получен ответ от UE 100B вызываемой стороны.

После этого MMTel-AS 116A, ассоциированный с UE 100A вызывающей стороны, сигнализирует 355, 357 через S-CSCF 114, SBG 105A, чтобы выдать в BGF 107A команду ввести сигнатуру сеанса в плоскость передачи мультимедиа через S-CSCF, при условии, что элемент подписки «сигнатура сеанса плоскости пользователя» предусмотрен для текущего вызова/сеанса.

Вставка сигнатуры сеанса может также интерпретироваться как введение или добавление сигнатуры сеанса в RTP-поток, например, в форме RTCP.

Инструкция вставки принимает форму назначенного SIP-заголовка или назначенной метки в существующем SIP-заголовке. Пример последней метки: «Require: insert-session-signature». Включение метки «Require: insert-session-signature» в SIP-сигнализацию 359 к SBG 105A ограничено условием, что Invite-запрос 359 от SBG 105A содержит «Supported: insert-session-signature».

Вместо «insert-session-signature» может также применяться эквивалент «inject-session-signature».

SGC 106A сигнализирует 361 в BGF 107A в ответ на прием «Require: insert-session-signature» от MMTel-AS 116A, что BGF 107A вставляет сигнатуру сеанса в RTP-поток сеанса передачи мультимедиа на плоскости пользователя. Эта инструкция от SGC 106A к BGF 107A вставляет фактическую сигнатуру сеанса, которая используется для этого RTP-потока сеанса передачи мультимедиа. RTP-поток сеанса передачи мультимедиа для текущего сеанса на плоскости пользователя будет расширен с использованием сигнатуры сеанса для сеанса передачи мультимедиа к сети. BGF 107B, ассоциированная с UE 100B вызываемой стороны, предпочтительно отфильтровывает RTCP-сообщения сигнатуры сеанса перед выдачей RTP-потока в UE 100B вызываемой стороны.

Когда инициализируется сеанс передачи мультимедиа, будет иметься поток 363A сеанса передачи мультимедиа без сигнатуры сеанса между UE 100A вызывающей стороны и SDB 107A, а также поток сеанса передачи мультимедиа с сигнатурой сеанса 363B от SBG 107A через транспортную IP-сеть 111.

Предлагается, чтобы сигнатура сеанса передавалась в RTCP-пакете типа «APP» (Тип пакета=Определенные в Приложении RTCP-Пакеты). Однако в соответствии с рекомендацией IETF выделенный Тип Пакета определяется, когда представленный в данном документе способ вводится в коммерческую эксплуатацию.

Ниже приведен формат APP-Пакета RTCP.

Описание применяемых сокращений:

V	Версия. Идентифицирует версию RTP. Версия, используемая для RTCP-потока, является такой же, как и версия соответствующего RTP-потока. IETF определяет, что она задается равной 2.
P	Заполнение. Для некоторых алгоритмов шифрования необходимо, чтобы RTCP-пакет имел некоторую длину. Бит заполнения используется, чтобы показать, что некоторое число «заполняющих октетов» добавляется к RTCP-пакету, чтобы получить требуемую длину RTCP-пакета.
Subtype	Пятиоктетное поле, которое может определяться приложением. Предлагается нижеследующее использование этого поля:
	0 Сигнатура сеанса вызывающей стороны
	1 Сигнатура сеанса вызываемой стороны
	2-31 Не определены
PT	Тип Пакета. Имеет значение 204 (PT=APP).
Length	Длина (число 32-битовых слов) этого RTCP-пакета, включая заголовок и любое заполнение, уменьшенная на 1.
SSRC	Источник потока RTP-пакетов, как определено для RTP.
CSRC	Содействующий источник, как определено для RTP.
Name	Имя для RTCP-пакета Приложения. Оно идентифицирует использование этого типа RTCP-пакета; оно имеет значение «сигнатура сеанса».
Data	Зависящие от приложения данные. Они содержат фактическую сигнатуру сеанса. Они представляют собой BER-кодирование (Основные Правила Кодирования) структуры данных, которая содержит следующие поля:

Причина предложения представленного контента сигнатуры сеанса состоит в следующем:

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

- P-asserted-id (PAI) идентифицирует и оператора (часть домена PAI), и обслуживаемого абонента (подсистема пользователя PAI).

- Параметр Sequence представляет собой порядковый номер сообщения сигнатуры сеанса. Если сигнатура сеанса передается в RTCP-сообщении каждые 30 с, то макс. значение sequence, равное 65535 (216-1), отображает интервал времени >546 часов. Это считается достаточным. Однако для Sequence может выбираться больший диапазон, например, 0..4294967295 (232-1). Каждый из этих параметров может маркироваться как OPTIONAL в определении ASN.1.

Сигнатура сеанса может быть вставлена только один раз или множество раз, чтобы позволять провайдеру транспортной IP-сети 111 более одного раза обнаруживать, какая сторона/оператор генерирует поток RTP-пакетов через транспортную IP-сеть. В качестве примера, сигнатура сеанса вставляется с периодическими интервалами, например, каждые 5 с. Частота вставки сигнатуры сеанса может сигнализироваться через квалификатор в заголовке Require SIP, например:

Require: insert-session-signature(30)

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

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

Когда оператор IP-инфраструктуры 111, которая передает поток сеанса передачи мультимедиа RTP, должен узнать о происхождении потока, оператору обеспечивается возможность - благодаря RTCP-сообщениям, содержащим сигнатуру сеанса - обнаружения происхождения упомянутого потока. Предполагается, что в начале RTP-потока имеется RTCP-сообщение, несущее сигнатуру сеанса. Из стека 401 RTCP-пакетов, проходящих через транспортную IP-сеть, верхний уровень будет извлекать RTCP-информацию для определения сигнатуры сеанса, чтобы обнаружить происхождение пакета. SDN-контроллер (или SDN-приложение, функционально соединенное с SDN контроллером) в транспортной IP-сети 111 определяет по сигнатуре сеанса происхождение сопровождающего RTP-потока и может определять, допустимо ли прохождение этого потока через транспортную IP-сеть. Кроме того, статистика по упомянутым потокам может развертываться путем обнаружения сигнатуры сеанса.

Вставка сигнатуры сеанса описана выше через SIP-заголовок Require: insert-session-signature. Например, SDP-ответ, который возвращается к SBG 105A, во время установления SIP-сеанса может содержать заголовок Require с меткой insert-session-signature. Этот SIP-заголовок вставляется с помощью MMTel-AS 116A, ассоциированного с UE 100A вызывающей стороны. SDP-запрос, который отправляется к UE 100B вызываемой стороны, может в равной мере содержать заголовок Require с меткой insert-session-signature; этот заголовок вставляется с помощью MMTel-AS 116B, ассоциированного с UE 100B вызываемой стороны.

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

Наряду с принципом резервирования ресурсов и сигнализации предусловий, для отражения ситуация с ресурсами в SDP вставка сигнатуры сеанса может также быть отражена в SDP. Иными словами, SDP-ответ, который принимается SBG 105A от MMTel-AS 116A, может на каждый поток сеанса передачи мультимедиа содержать атрибут, который показывает, что для этого потока сеанса передачи мультимедиа вставляется сигнатура сеанса. Ниже приведен пример.

Версия протокола описания сеанса (v): 0

Владелец/Производитель, идентификатор сеанса (o): - 670440233 2054234882 IN IP4 172.16.11.180

Имя сеанса (s): -

Информация о соединении (c): в IP4 172.16.150.222

Описание времени, активное время (t): 0 0

Атрибут сеанса (a): sendrecv

Описание мультимедиа, имя и адрес (m): audio 34880 RTP/AVP 100 105

Информация о соединении (c): в IP4 172.16.150.222

Информация о полосе частот (b): AS:41

Атрибут мультимедиа (a): curr:qos remote sendrecv

Атрибут мультимедиа (a): curr:qos local sendrecv

Атрибут мультимедиа (a): des:qos mandatory remote sendrecv

Атрибут мультимедиа (a): des:qos mandatory local sendrecv

Атрибут мультимедиа (a): sendrecv

Атрибут мультимедиа (a): rtpmap:100 AMR-WB/16000

Атрибут мультимедиа (a): rtpmap:105 telephone-event/16000

Атрибут мультимедиа (a): fmtp:100 max-red=0; mode-change-capability=2

Атрибут мультимедиа (a): fmtp:105 0-15

Атрибут мультимедиа (a): ptime:20

Атрибут мультимедиа (a): maxptime:40

Атрибут мультимедиа (a): insert-session-signature(30)

Атрибут insert-session-signature(30) показывает, что сигнатура сеанса вставляется каждые 30 с для этого потока сеанса передачи мультимедиа. Для вызова, который содержит аудиопоток и видеопоток, имеются два отдельных определения потока сеанса передачи мультимедиа в SDP. Каждое определение потока сеанса передачи мультимедиа может при этом иметь атрибут, чтобы показывать, что сигнатура сеанса вставляется в RTCP для этого потока сеанса передачи мультимедиа. SBG 105A, согласно замыслу, действует как пользовательский агент типа Back to Back (B2BUA). Следовательно, SBG 105A может удалять атрибут insert-session-signature из SDP перед направлением SDP к UE 100A вызывающей стороны.

Если во время вызова маршрутизация RTP-потока изменяется, приводя к тому, что вставка сигнатуры сеанса более не требуется, либо когда вставка сигнатуры сеанса более не требуется по другой причине, MMTel-AS 116A может инициировать повторное согласование SDP с целью удаления атрибута insert-session-signature из SDP.

В качестве дополнительного расширения фактическая сигнатура сеанса для вставки в RTP-поток может обеспечиваться MMTel-AS вместо того, чтобы использовать SBG/SGC 105A, 106A для создания или составления сигнатуры сеанса. Это может осуществляться следующим образом:

Атрибут мультимедиа (a): insert-session-signature; freq=30; realm=ims.mnc302.mcc270.3gppnetwork.org; signature=akjsgf23490askdjl^%$sdflg

Поля этого атрибута имеют следующее значение:

freq	Это поле показывает, как часто вставляется сигнатура сеанса, измеряется в секундах. В данном примере - каждые 30 с.
realm	Это поле содержит доменное имя обслуживающего оператора, т.е., оператора, под управлением которого (под руководством которого) устанавливается поток сеанса передачи мультимедиа.
signature	Фактическая вставляемая сигнатура сеанса. Сигнатура сеанса прозрачна для SBG 105A; SBG 105A вставляет сигнатуру сеанса непосредственно после приема, не анализируя сигнатуру сеанса. MMTel-AS 116A может создавать сигнатуру сеанса через комбинацию идентификатора Вызова, метки «От» и метки «К» (используемой в SIP-сеансе на стороне доступа MMTel-AS 116A). Однако MMTel-AS 116A может быть выработана любая схема для создания сигнатуры SIP-сеанса на каждый SIP-сеанс.

Realm и Signature в этом случае передаются как отдельные параметры в вышеописанном RTCP-заголовке. Сигнатура сеанса, которая переносится в RTCP-заголовке, при этом имеет следующее определение ASN.1:

Объект в транспортной IP-сети 111, которая передает/направляет RTP-поток, может считывать поле Realm RTCP-пакета назначенного типа приложения сигнатуры сеанса и проверять, что оператор, начинающий поток, имеет право передавать сеанс передачи мультимедиа через транспортную IP-сеть 111. Поле Signature может использоваться для дополнительной проверки. Этот параметр маркируется как OPTIONAL в ASN.1. MMTel-AS 116A включает этот параметр только тогда, когда это требуется. Когда SIP-сеанс должен быть подписан с использованием только области оператора, атрибут inject-session-signature в SDP имеет следующий вид:

Атрибут мультимедиа (a): inject-session-signature; freq=30; realm=ims.mnc302.mcc270.3gppnetwork.org

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

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

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

Преимущества, достигаемые с помощью предложенного решения:

- Улучшенные возможности оптимизации маршрутизации плоскости пользователя для сеанса связи на основе IMS; это приводит к следующему:

- пониженные расходы на передачу передачи мультимедиа;

- уменьшенная задержка передачи мультимедиа (ввиду более короткого маршрута);

- уменьшенная общая сложность сеанса связи (поскольку медиаданные проходят через меньшее число узлов).

- Улучшенные возможности оптимизации маршрутизации плоскости управления для сеанса связи на основе IMS, поскольку эта маршрутизация не обязательно должна выполняться совместно с плоскостью пользователя; это приводит к следующему:

- снижение себестоимости оборудования (пониженная нагрузка на различные SIP-прокси);

- сокращенное время установления вызова (ввиду меньшего числа SIP-прокси, через которые необходимо проходить);

- уменьшенная общая сложность сеанса связи (ввиду меньшего числа SIP-прокси, через которые необходимо проходить, например, TRF не нужны).

В случае, если выбирается вариант осуществления, в котором MMtel-AS составляет сигнатуру сеанса, вставляемую BGF 107A, имеются дополнительные преимущества, состоящие в следующем:

- Имеется пониженная сложность для SBG/SGC 105A, 106A; SBG/SGC 105A, 106A не нужно создавать или составлять сигнатуру сеанса.

- Прозрачные средства для объектов в транспортной IP-сети 111 для сеанса передачи мультимедиа, для извлечения объекта обслуживающего оператора из RTP-потока (сообщение о сигнатуре сеанса RTCP).

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

Фиг. 5 является схематической диаграммой, изображающей вариант осуществления, представляющий в ряде функциональных блоков компоненты функции SBG 105A, 105B шлюза. SBG 105A, 105B в приведенном выше описании рассматривается как единый блок, вследствие чего инструкции по обработке плоскости пользователя принимаются через плоскость управления и исполняются для плоскости пользователя. Реализация функций SBG осуществляется логическими блоками SGC 106A, 106B для плоскости управления и BGF 107A, 107B для плоскости пользователя. Логические блоки SGC и BGF не обязательно должны находиться в одном и том же местоположении. Когда в приведенном выше тексте указано, что SBG 105A, 105B выполнен с возможностью выполнения некоторых этапов, следует понимать, что эти действия реализуются на SGC и BGF для плоскости управления и плоскости пользователя соответственно.

Схемы 501A, 501B обработки предусмотрены с использованием одного или более подходящих центрального процессора (CPU), мультипроцессора, микроконтроллера, цифрового сигнального процессора (DSP) и т.д., способных исполнять команды, хранящиеся в компьютерном программном продукте 601A, 601B (показанном на фиг. 6), например, в форме информационного носителя 503A, 503B. Схемы 501A, 501B обработки могут дополнительно предусматриваться, например, в качестве подходящего компьютерного блока обработки или распределенного облака вычислительных средств.

Блок 501A, 501B обработки выполнен с возможностью инициирования исполнения функцией (105A) шлюза:

- приема идентификатора, ассоциированного с сеансом вызова UE 100A вызывающей стороны, причем идентификатор идентифицирует вставку сигнатуры сеанса в сеанс передачи мультимедиа;

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

- вставки сигнатуры сеанса в сеанс передачи мультимедиа в первом тракте (111) таким образом, что оценка сигнатуры сеанса обеспечивает ассоциирование сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа. Первый тракт следует понимать как плоскость пользователя между UE 100A, 100B вызывающей и вызываемой стороны.

Информационный носитель 503A, 503B может хранить набор операций, причем схемы 501A, 501B обработки выполнены с возможностью извлечения набора операций из информационного носителя 503A, 503B, чтобы инициировать выполнение сетью SBG 105A, 105B набора операций. Набор операций может предусматриваться в виде набора исполнимых инструкций.

Функция SBG 105A, 105B шлюза может дополнительно включать в себя интерфейс 505A, 505B связи, который выполнен с возможностью:

- Осуществления связи, внешней по отношению к SBG 105A, 105B, по существу между SGC 106A, 106B и BGF 107A, 107B через канал 108A, 108B соответственно.

- Осуществления связи с PDN-Gw 104A, 104 для передачи управления и плоскости пользователя

- Осуществления связи с любой IMS-сетью 114A, 114B и транспортной IP-сетью 111.

По существу, интерфейс 505A, 505B связи может содержать один или более передатчиков и приемников. Схемы 501A, 501B обработки управляют общим выполнением функции SBG 105A, 105b шлюза, например, путем отправки и приема данных и управляющих сигналов в интерфейс 505A, 505B связи и информационный носитель 503A, 503B.

Фиг. 6 схематически иллюстрирует пример компьютерного программного продукта, содержащего машиночитаемый носитель в соответствии с вариантом осуществления. Фиг. 6 показывает один пример компьютерного программного продукта, содержащего машиночитаемый носитель 605. На этом машиночитаемом носителе может храниться компьютерная программа 603, которая может инициировать осуществление схемами 501A, 501B обработки соответственно и ассоциированными с возможностью связи объектами и устройствами, такими как интерфейс 505A, 505B связи и информационный носитель 503A, 503B способов в соответствии с описанными вариантами осуществления.

В изображенном на фиг. 6 примере компьютерный программный продукт 601A, 601B иллюстрирован как диск с поверхностью 605, на которой могут храниться данные программы. Компьютерный программный продукт 601A, 601B может также быть осуществлен в виде памяти, такой как оперативное запоминающее устройство (RAM), постоянное запоминающее устройство (ROM), или в виде энергонезависимого информационного носителя устройства во внешней памяти. Компьютерная программа 603 в данном случае схематически изображена как дорожка, хранящаяся на показанном диске.

Фиг. 7 схематически иллюстрирует пример функциональных компонентов функции шлюза. Функция 700 шлюза показана с

- модулем 701 приемника для приема идентификатора, ассоциированного с сеансом вызова UE (100A) вызывающей стороны, причем идентификатор идентифицирует вставку сигнатуры сеанса в сеанс передачи мультимедиа;

- модулем 703 обработки для составления сигнатура сеанса на основе принятого идентификатора, и

- модулем 705 вставки для вставки сигнатуры сеанса в сеанс передачи мультимедиа в первом тракте (111) таким образом, что оценка сигнатуры сеанса обеспечивает ассоциирование сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа.

Claims

1. Способ обеспечения ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа в инфраструктуре (150) Мультимедийной Подсистемы на базе Интернет-Протокола (IP) (IMS) , причем инфраструктура (150) содержит Пользовательское Оборудование (UE) (100A) вызывающей стороны, UE (100B) вызываемой стороны, первый тракт (111), выполненный с возможностью передачи еанса передачи мультимедиа между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны через функциональный блок шлюза (105A),

причем во время установления сеанса передачи мультимедиа IMS-объект (116A) извлекает абонентскую информацию, информацию, ассоциированную с вызовом UE (100A) вызывающей стороны, и при этом инфраструктура (150) выполняет следующие этапы:

- IMS-объект (116A) снабжает функциональный блок шлюза (105A) идентификатором, ассоциированным с сеансом вызова UE (100A) вызывающей стороны, причем идентификатор идентифицирует вставку сигнатуры сеанса в сеанс передачи мультимедиа;

- функциональный блок шлюза (105A) использует идентификатор для составления сигнатуры сеанса; и

- функциональный блок шлюза (105A) вставляет составленную сигнатуру сеанса в сеанс передачи мультимедиа в первом тракте (111) таким образом, что оценка сигнатуры сеанса обеспечивает ассоциирование сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа.

2. Способ обеспечения функциональным блоком шлюза (105А) ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа в инфраструктуре (150) Мультимедийной Подсистемы на базе Интернет-Протокола (IP) (IMS), причем инфраструктура (150) содержит Пользовательское Оборудование (UE) (100A) вызывающей стороны, UE (100B) вызываемой стороны, первый тракт (111), выполненный с возможностью передачи сеанса передачи мультимедиа между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны через функциональный блок шлюза (105А), выполненный с возможностью:

- приема идентификатора, ассоциированного с сеансом вызова UE (100A) вызывающей стороны, причем идентификатор идентифицирует вставку сигнатуры сеанса в сеанс передачи мультимедиа;

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

- вставки сигнатуры сеанса в сеанс передачи мультимедиа в первом тракте (111) таким образом, что оценка сигнатуры сеанса обеспечивает ассоциирование сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа.

3. Способ по п. 2, причем вставленная сигнатура сеанса содержит по меньшей мере одно из: адреса оператора Домашней сети UE (100A) вызывающей стороны, SIP-идентификатора сеанса, такого как идентификатор вызова, метка «От» или метка «К».

4. Способ по любому из пп. 2, 3, причем этап вставки повторяется заданное число раз, повторяемых во время заданного периода, или причем сигнатура сеанса вставляется по запросу объекта, содержащегося в IMS-сети.

5. Способ по любому из пп. 2, 3, причем сигнатура сеанса вставляется в сеанс передачи мультимедиа во втором тракте, отличном от первого тракта (111), причем второй тракт находится между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны.

6. Способ по любому из пп. 2, 3, причем сигнатура сеанса применяет Протокол Управления Передачей в Реальном Времени (RTCP) или защищенный RTCP (SRTCP) протокол.

7. Способ по любому из пп. 2, 3, причем принимаемый идентификатор, ассоциированный с сеансом вызова UE (100A) вызывающей стороны, содержит индикацию того, что этап составления должен быть основан на информации, доступной для функционального блока шлюза, или быть основан на информации, содержащейся в идентификаторе.

8. Способ по любому из пп. 2, 3, причем объект (115A) Абонентской базы данных, ассоциированный с UE (100A) вызывающей стороны, содержит атрибут, указывающий, что сигнатура сеанса вставляется в первом тракте или втором тракте.

9. Функциональный блок шлюза (105А), находящийся в инфраструктуре Мультимедийной Подсистемы на базе Интернет-Протокола (IP) (IMS), для обеспечения ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа, причем инфраструктура (150) содержит Пользовательское Оборудование (UE) (100A) вызывающей стороны, UE (100B) вызываемой стороны, первый тракт (111), выполненный с возможностью передачи сеанса передачи мультимедиа между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны через функциональный блок шлюза (105А),

причем функциональный блок шлюза (105А) содержит блок обработки, причем блок обработки выполнен с возможностью инициирования выполнения функциональным блоком шлюза (105А):

10. Функциональный блок шлюза (105А) по п. 9, причем блок обработки выполнен с возможностью многократной вставки сигнатуры сеанса заданное число раз, многократной вставки сигнатуры сеанса во время заданного периода или вставки сигнатуры сеанса по запросу объекта, содержащегося в IMS-сети.

11. Функциональный блок шлюза (105А) по любому из пп. 9, 10, причем блок обработки выполнен с возможностью вставки сигнатуры сеанса во втором тракте, отличном от первого тракта (111), причем второй тракт находится между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны.

12. Функциональный блок шлюза (105А) по любому из пп. 9, 10, причем блок обработки выполнен с возможностью применения Протокола Управления Передачей в Реальном Времени (RTCP) или защищенного RTCP (SRTCP) протокола для вставленной сигнатуры сеанса.

13. Функциональный блок шлюза (105А) по любому из пп. 9, 10, причем блок обработки выполнен с возможностью принятия решения по принятой (357) индикации для составления сигнатуры сеанса на основе информации, доступной для функционального блока шлюза, или составления сигнатуры сеанса по информации, содержащейся в индикации.

14. Машиночитаемый носитель, содержащий компьютерную программу (603) для обеспечения ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа, причем инфраструктура (150) для обеспечения управления сеансом передачи мультимедиа является сетевой инфраструктурой (150) IMS, причем инфраструктура (150) содержит функциональный блок шлюза (105А), UE (100A) вызывающей стороны, UE (100B) вызываемой стороны, объект (115A) Абонентской базы данных, содержащий данные подписки, ассоциированные с UE (100A) вызывающей стороны, причем первый тракт выполнен с возможностью передачи сообщений о передаче мультимедиа между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны,

и причем компьютерная программа содержит программный код, который при запуске на схемах обработки функционального блока шлюза (105А) инициирует исполнение функциональным блоком шлюза (105А):

15. Функциональный блок шлюза (105А), находящийся в инфраструктуре (150) Мультимедийной Подсистемы на базе Интернет-Протокола (IP) (IMS), для обеспечения ассоциирования сеанса передачи мультимедиа с оператором, начинающим сеанс передачи мультимедиа, причем инфраструктура (150) содержит Пользовательское Оборудование (UE) (100A) вызывающей стороны, UE (100B) вызываемой стороны, первый тракт (111), выполненный с возможностью передачи сеанса передачи мультимедиа между UE (100A) вызывающей стороны и UE (100B) вызываемой стороны через функциональный блок шлюза (105А), содержащий:

- модуль приемника для приема идентификатора, ассоциированного с сеансом вызова UE (100A) вызывающей стороны, причем идентификатор идентифицирует вставку сигнатуры сеанса в сеанс передачи мультимедиа;

- модуль обработки для составления сигнатуры сеанса на основе принятого идентификатора; и

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