Способ переключения между mbms загрузкой и доставкой на основе http dash-форматированного содержания по ims сети

Способ переключения между mbms загрузкой и доставкой на основе http dash-форматированного содержания по ims сети

Иллюстрации

Показать все

Реферат

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

Технология беспроводной мобильной связи использует различные стандарты и протоколы для передачи данных между передающей станцией и беспроводным мобильным устройством. Некоторые беспроводные устройства поддерживают связь с использованием мультиплексирования с ортогональным частотным разделением каналов (OFDM) в комбинации с желательной схемой цифровой модуляции через физический уровень. Стандарты и протоколы, которые используют OFDM, включают в себя долгосрочное развитие (LTE) проекта партнерства систем связи 3-го поколения (3GPP), стандарт 802.16 (например, 802.16е, 802.16m) Института инженеров по электротехнике и электронике (IEEE), который широко известен в отраслевых группах как WiMAX (глобальная совместимость для микроволнового доступа), стандарт IEEE 802.11, который широко известен в отраслевых группах как WiFi.

В системах LTE сети радиодоступа (RAN) 3GPP, передающая станция может представлять собой комбинацию из узлов В (Node В) выделенной универсальной наземной сети радиодоступа (E-UTRAN) (которые обычно также обозначаются как выделенные узлы Node В, усовершенствованные узлы Node В, eNodeB или eNB) и контроллеров радиосети (RNC), которые поддерживают связь с беспроводным мобильным устройством, известным как пользовательское оборудование (UE). Передача по нисходящей линии связи (DL) может представлять собой связь из передающей станции (или eNodeB) с беспроводным мобильным устройством (или UE), и передача по восходящей линии связи (UL) может представлять собой связь от беспроводного мобильного устройства с передающей станцией.

При передаче по нисходящей линии связи, передающая станция может поддерживать связь с одним беспроводным мобильным устройством с использованием услуги одноадресной передачи. Доставка одноадресной передачи имеет взаимнооднозначное соответствие, которое относится к одному сообщению мобильного устройства для одного мобильного устройства. Альтернативно, передающая станция может поддерживать связь с множеством беспроводных мобильных устройств с помощью подкадра одночастотной сети многоадресной/широковещательной (MBSFN) с использованием услуги мультимедийной, широковещательной и многоадресной передачи (MBMS). Транспортная многоадресная передача и широковещательный трафик в MBMS может иметь только взаимнооднозначные соответствия, относящиеся к одному сообщению для многих мобильных устройств.

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

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

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

фиг.2 иллюстрирует блок-схему подфункциональной архитектуры центра услуг широковещательной и многоадресной передачи (BMSC) согласно примеру;

фиг.3 изображает примерный процесс для переключения с загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) на доставку на основе протокола передачи гипертекста (HTTP) динамичной адаптивной потоковой передачи поверх HTTP DASH-форматированного содержания в сети мультимедийной подсистемы (IMS) на базе Интернет-протокола (IP) согласно примеру;

фиг.4 изображает примерный процесс для переключения с загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) на доставку на основе протокола передачи гипертекста (HTTP) динамичной адаптивной потоковой передачи поверх HTTP (DASН)-форматированного содержания в сети мультимедийной подсистемы (IMS) на базе Интернет-протокола (IP), причем данная сеть включает в себя запрос для описания представления мультимедиа (MPD) согласно примеру;

фиг.5 изображает примерный процесс для переключения с доставки на основе протокола передачи гипертекста (HTTP) на доставку загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) DASH-форматированного содержания в сети мультимедийной подситемы (IMS) на базе Интернет-протокола (IP) согласно примеру;

фиг.6 изображает схему последовательности операций способа переключения с загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) на доставку на основе протокола передачи гипертекста (HTTP) динамичной адаптивной потоковой передачи поверх HTTP (DASН)-форматированного содержания в сети мультимедийной подсистемы (IMS) на базе Интернет-протокола (IP);

фиг.7 изображает схему последовательности операций способа переключения с доставки на основе протокола передачи гипертекста (HTTP) на доставку загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) DASH-форматированного содержания в сети мультимедийной подсистемы (IMS) на базе Интернет-протокола (IP) согласно примеру; и

фиг.8 изображает схему пользовательского оборудования (UE) согласно примеру.

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

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

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

Примерный вариант осуществления

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

Потоковую передачу, поддерживающую протокол передачи гипертекста (HTTP), можно использовать в виде доставки мультимедиа Интернет-видео. Доставка на основе HTTP позволяет обеспечить надежность и простоту развертывания за счет широкого принятия как HTTP, так и основополагающих протоколов HTTP, включающих в себя протокол управления передачей (ТСР)/Интернет-протокол (IP). Доставка на основе HTTP позволяет обеспечить легкую и без усилий потоковую передачу услуг, избегая при этом преобразования сетевых адресов (NAT) и проблемы брандмауэра. Доставка на основе HTTP или потоковая передача позволяет также обеспечить возможность использования стандартных серверов HTTP-серверы и кэш-память вместо специальных потоковых серверов. Доставка на основе HTTP позволяет обеспечить масштабируемость благодаря минимальной или уменьшенной информации о состоянии на стороне сервера.

Динамичная адаптивная потоковая передача поверх HTTP (DASH) представляет собой технологию потоковой передачи мультимедиа, где мультимедийный файл можно разбить на один или более сегментов и доставить клиенту, использующему HTTP. DASH-клиент может получить мультимедийное содержание посредством загрузки сегментов через ряд операций запроса-ответа HTTP. DASH позволяет обеспечить возможность динамичного переключения между различными представлениями скорости передачи данных медиасодержания в виде доступных изменений ширины полосы пропускания. Таким образом, DASH позволяет обеспечить быструю адаптацию к изменению сети и условиям беспроводной линии связи, предпочтениям пользователя и возможностям устройства, таким как разрешение устройства-отображения, тип используемого центрального процессорного устройства (CPU) или доступные ресурсы памяти. Динамичная адаптация DASH позволяет обеспечить более высокое качество восприятия (QoE) для пользователя с более короткими задержками при запуске и меньшим количеством событий повторной буферизации.

Мультимедийная подсистема, поддерживающая Интернет-протокол (IP) или мультимедийная подсистема базовой сети IP (IMS) представляет собой основу архитектуры в 3GPP для доставки услуг IP-мультимедиа. Мультимедийная подсистема базовой сети IP может представлять собой совокупность различных функций базовой сети и сети доступа, связанных с помощью стандартизированных интерфейсов, которые сгруппированы вместе, могут образовывать одну административную сеть IMS. Чтобы облегчить интеграцию с Интернет, IMS может использовать протокол инициации сеанса (SIP). Несколько ролей SIP-серверов или прокси-серверов, которые вместе можно назвать как функция управления сеансами и вызовами (CSCF), можно использовать для обработки сигнальных пакетов SIP в IMS. Фиксированный доступ (например, цифровая абонентская линия (DSL), кабельные модемы или Ethernet, мобильный доступ (например, W-CDMA, CDMA2000, GSM или GPRS) и беспроводный доступ (например, WLAN или WiMax) можно поддерживать с помощью IMS. Другие телефонные системы типа простых старых телефонов (POTS - аналоговых телефонов) и не IMS-совместимые системы передачи голоса по IP (VoIP) можно поддерживать через шлюзы.

DASH-форматированное содержание можно доставить поверх IMS-сети в многоадресном кадре, таком как доставка загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS), или в одноадресном кадре, таком как доставка на основе HTTP. Сеанс доставки содержания, включающий в себя DASH-coдержание, можно доставить, используя способ загрузки MBMS, затем переключиться на способ доставки на основе HTTP в середине сеанса (середина сеанса). Альтернативно, сеанс доставки содержания можно доставить, используя способ доставки на основе HTTP, затем переключиться на способ загрузки MBMS в середине сеанса. Может быть желательным переключение в сети на основе IMS между способом загрузки MBMS и способом доставки на основе HTTP во время передачи DASH-форматированного содержания пользователю.

Как иллюстрировано на примерной блок-схеме (фиг.1), при переключении загрузки MBMS на доставку на основе HTTP DASH-форматированного содержания в IMS-сети, мобильное устройство, такое как пользовательское оборудование (UE) 210, может отправлять повторное приглашение протокола инициирования сеанса (SIP) в модуль функции управления услугой (SCF) 230, когда мобильное устройство принимает загрузку MBMS в текущем сеансе доставки содержания, в том числе содержание DASH. Повторное приглашение SIP может включать в себя сообщение SIP Re-INVITE. Повторное приглашение SIP может включать в себя универсальный идентификатор ресурса (URI) запроса для HTTP сервера 260, чтобы предоставить DASH-содержание через доставку на основе HTTP в том же самом сеансе доставки содержания. URI запроса может включать в себя доменное имя или идентификатор содержания, идентифицирующий (или ссылающийся на HTTP-сервер для обеспечения доставки на основе HTTP). SCF-модуль можно включить в мультимедийную подсистему (IMS) на базе Интернет-протокола (IP). После получения повторного приглашения SIP через подсистему 220 мультимедийной базовой сети на основе IP (IM CN), SCF-модуль может отправлять приглашение SIP в адаптер 250 HTTP/SIP, чтобы выбрать HTTP-сервер 260 для доставки на основе HTTP. Приглашение SIP может включать в себя сообщение SIP INVITE с URI запроса, где SCF-модуль ранее использовал доменное имя или идентификатор содержания, ссылающийся на (или ассоциированный с) центр(ом) услуг широковещательной и многоадресной передачи (BMSC) или подфункции(ями) плоскости пользователя (UPF) BMSC (BMSC.UPF) 240 для установления загрузки MBMS DASH-форматированного содержания через BMSC.

Доменное имя и идентификатор содержания, ссылающийся на HTTP-сервер, может отличаться от доменного имени и идентификатора содержания, ассоциированного с BMSC. SCF-модуль 230 может также отправлять запрос на завершение в BMSC для завершения загрузки MBMS для сеанса доставки содержания. Адаптер HTTP/SIP может установить HTTP-сервер для загрузки на основе HTTP DASH-форматированного содержания для того же самого сеанса доставки содержания, который ранее использовался для загрузки MBMS. Адаптер HTTP/SIP может отправлять подтверждение SIP в SCF-модуль, показывающее выбор HTTP-сервера для сеанса доставки содержания. Подтверждение SIP может включать в себя сообщение SIP OK 200. SCF-модуль может переслать подтверждение SIP в мобильное устройство через подсистему IM CN, показывающее переключение на HTTP-сервер для сеанса доставки содержания. Мобильное устройство может затем принимать DASH-форматированное содержание сеанса доставки содержания через доставку на основе HTTP вместо загрузки MBMS.

При переключении с доставки на основе HTTP на загрузку MBMS DASH-форматированного содержания, мобильное устройство может отправлять повторное приглашение SIP в SCF-модуль 230, когда мобильное устройство принимает доставку на основе HTTP DASH-форматированного содержания в сеансе доставки содержания. Повторное приглашение SIP может включать в себя URI-запрос для BMSC или BMSC.UPF 240 для предоставления DASH-форматированного содержания через загрузку MBMS в том же самом сеансе доставки содержания. URI-запроса может включать в себя доменное имя или идентификатор содержания, идентифицирующий или ссылающийся на BMSC для выполнения загрузки MBMS. После получения повторного приглашения SIP через подсистему 220 IM CN, SCF-модуль может отправлять сообщение приглашения в BMSC или BMSC.UPF для инициирования (или установки) BMSC для загрузки MBMS сеанса доставки содержания. Сообщение приглашения может включать в себя URI-запросы, где SCF-модуль ранее использовал доменное имя или идентификатор содержания, ассоциированный с (или ссылающийся на) HTTP-сервером 260 для установления доставки на основе HTTP DASH-форматированного содержания через HTTP сервер. Доменное имя и идентификатор содержания, ссылающийся на HTTP-сервер, может отличаться от доменного имени и идентификатора содержания, ассоциированного с BMSC. SCF-модуль может принимать подтверждение BMSC из BMSC, показывающее выбор BMSC для сеанса доставки содержания после того, как BMSC установится для загрузки MBMS. SCF-модуль может отправлять запрос на завершение SIP в адаптер 250 HTTP/SIP для разъединения с HTTP-сервером и/или для завершения доставки на основе HTTP для сеанса доставки содержания. Запрос на завершение SIP может включать в себя сообщение SIP BYE.

Адаптер HTTP/SIP может отправлять подтверждение SIP в SCF-модуль 230, показывающее завершение доставки на основе HTTP для сеанса доставки содержания и/или установки BMSC для сеанса доставки содержания. Подтверждение SIP может включать в себя сообщение OK SIP 200. SCF-модуль может переслать подтверждение SIP в мобильное устройство через подсистему IM CN, показывающее переключение на BMSC для сеанса доставки содержания. Мобильное устройство может принимать DASH-форматированное содержание сеанса доставки содержания через загрузку MBMS вместо доставки на основе HTTP.

Ниже представлены дополнительные подробности примеров. Доставка загрузки MBMS может представлять собой альтернативную услугу для выгрузки одноадресной доставки загрузки на основе HTTP. Преимущества использования доставки загрузки MBMS могут включать в себя предоставление возможности поддержки для типов услуг в нереальном времени, предоставление возможности обеспечения содержаний, которые дополняют услуги потоковой передачи MBMS, и максимальное использование увеличивающегося объема памяти на мобильных устройствах. Формат сегмента DASH, который хотя и предназначен, главным образом, для одноадресной транспортировки с помощью HTTP, может быть агностиком среды доставки - одноадресной или многоадресной. DASH-форматированное содержание можно передавать, используя доставку загрузки MBMS с доставкой файла по однонаправленному транспортному протоколу (FLUTE).

FLUTE может представлять собой протокол для однонаправленной доставки файлов по Интернет, который, в частности, может быть подходящим для многоадресных (многовещательных) сетей. FLUTE можно построить на основе асинхронного послойного кодирования (ALC) для массового масштабируемого многоадресного распределения. FLUTE может обеспечить конкретизацию блока построения транспорта с послойным кодированием (LCT). Протокол ALC позволяет объединить блок построения LCT, блок построения контроля перегрузки (СС) и блок построения прямого исправления ошибок (FEC) для обеспечения надежной синхронной доставки с контролируемой перегрузкой. LCT может обеспечить поддержку на уровне транспорта для надежной доставки содержания и протоколов потоковой доставки. Потоковую передачу данных или загрузок можно инкапсулировать в транспортный протокол реального времени (RTP) и транспортировать, используя протокол FLUTE при доставке по однонаправленным каналам MBMS. RTP можно использовать в коммуникационных и развлекательных системах, которые включают в себя потоковую передачу мультимедиа, такую как телефония, приложение видеотелеконференцсвязи, услуги телевидения и особенности радиосвязи нажатием одной клавиши на основе Веб (web).

Три функциональных уровня можно использовать для доставки услуг на основе MBMS, которые могут включать в себя уровень однонаправленных каналов, уровень способа доставки и уровень услуги пользователя или уровень приложений. Уровень однонаправленных каналов может обеспечить механизм, с помощью которого можно транспортировать IP-данные. Однонаправленные каналы могут включать в себя одноадресный однонаправленный канал или однонаправленный канал MBMS. Уровень доставки может обеспечить функциональные возможности, такие как безопасность и распределение ключей, управление надежностью посредством технологий прямого исправления ошибок (FEC) и связанных с ними процедурами доставки, такими как восстановление файлов, верификация доставки. Способы доставки могут включать в себя загрузку и потоковую передачу. Услуга пользователя MBMS позволяет обеспечить приложения. Услуга пользователя может включать в себя услугу передачи мультимедийных сообщений или услугу потоковой передачи с коммутацией пакетов (PSS).

Адаптивная потоковая передача на основе DASH по HTTP может отличаться от адаптивной потоковой передачи на основе протокола потоковой передачи в реальном времени (RTSP). RTSP может представлять собой протокол управления сетью, который используется в развлекательных и коммуникационных системах для управления серверами потоковой передачи мультимедиа. Протокол RTSP можно использовать для установления и управления сеансами мультимедиа между конечными точками методом на основе "проталкивания" и под управлением сервера, хотя адаптивная потоковая передача на основе DASH может базироваться на извлечении информации и находиться под управлением клиента. Клиенты медиасерверов могут выдавать команды типа кассетного видеомагнитофона (VCR), такие как воспроизведение и пауза, чтобы облегчить управление в реальном времени воспроизведением медиафайлов, поступающих из сервера. Аналогично, до некоторой степени, HTTP, RTSP может определять последовательности управления, полезные при управлении воспроизведения мультимедиа. Хотя HTTP может быть без запоминания состояния, RTSP может иметь состояние или идентификатор, используемый при необходимости для отслеживания одновременных сеансов.

Перед использованием технологий адаптивной потоковой передачи на основе DASH, способы прогрессивной загрузки были также доступны для доставки мультимедиа из стандартных web-серверов HTTP. Недостатки прогрессивной загрузки на основе HTTP могут включать в себя то, что пропускная способность может бесполезно расходоваться, если пользователь решит остановить просмотр содержания после начала прогрессивной загрузки (например, при переключении на другое содержание), загрузка не является на самом деле адаптивной скорости передачи данных, или загрузка не поддерживает медиауслуги в прямом эфире. Технология DASH позволяет устранить недостаток потоковой передачи на основе RTP/RTSP и прогрессивной загрузки на основе HTTP.

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

Примеры технологий DASH могут включать в себя плановую потоковую передачу Microsoft IIS, потоковую передачу в прямом эфире Apple HTTP и динамичную потоковую передачу Adobe HTTP. Технология DASH была также стандартизирована организациями, такими как проект партнерства 3-го поколения (3GPP), экспертная группа по движущимся изображениям (MPEG) и открытый форум IPTV (OIPF).

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

Мобильное устройство может иметь уже установленную загрузку MBMS или сеанс доставки DASH-форматированного содержания на основе HTTP. Мобильное устройство может иметь возможность переключения на другой способ доставки, такой как доставка на основе HTTP, в случае приема загрузки MBMS или переключения на загрузку MBMS в случае приема доставки на основе HTTP. Примеры некоторых связанных с этим событием переключений для переключения с загрузки MBMS на способ доставки на основе HTTP можно привести без изменения канала и с изменением канала. Например, без изменения канала пользователь может просмотреть услугу пользователя MBMS и переместиться из зоны действия MBMS. Либо пользователь может инициировать действие в режиме быстрого проигрывания мультимедиа, облегчающего переключение на доставку на основе HTTP. В другом примере содержание может быть только доступным при потоковой передаче с коммутацией пакетов (PSS)/DASH с изменением канала. Примеры некоторых связанных с этим событий переключений для переключения с доставки на основе HTTP на загрузку MBMS можно привести без изменения канала и с изменением канала. Например, без изменения канала пользователь может вернуться из режима быстрого проигрывания мультимедиа к нормальной услуге пользователя MBMS. В другом примере содержание может быть доступным по MBMS с изменением канала.

Фиг.1 иллюстрирует функциональную архитектуру услуги пользователя MBMS и PSS на основе IMS. Функциональные блоки, которые могут облегчить переключение между загрузкой MBMS и доставкой DASH на основе HTTP, могут включать в себя подсистему 220 IM CN, UE 210, SCF 230, адаптер 250 HTTP/SIP, сервер 260 HTTP, BMSC.UPF 240, модуль функции правил политики и тарификации (PCRF) 270, модуль функции выбора услуги (SSF) 290 и адаптер 292 PSS. Другая PSS на основе функционального блока IMS и функциональная архитектура услуги пользователя MBMS могут представлять собой выделенную базовую сеть с коммутацией пакетов (ЕРС)/потоковую передачу с коммутацией пакетов (PS)/RAN 280. ЕРС или развитие системной архитектуры (SAE) может включать в себя модуль управления мобильностью (ММЕ), обслуживаемый шлюз (SGW) и шлюз сети пакетной передачи данных (PDN) (PGW).

Подсистема 220 IM CN может поддерживать регистрацию и аутентификацию пользователя, мобильность и роуминг, управление мультимедийными сеансами, управление качеством обслуживания (QoS), управление политикой, тарификацию и/или обеспечение межсетевого обмена с сетями с коммутацией каналов. UE 210 может содержать универсальные клиенты архитектуры самонастройки (GBA)/IMS/PSS/MBMS, которые могут выполнить обнаружение и выбор услуги, инициирование услуги обработки, модификацию и завершение и/или принимать и предоставлять содержание пользователю.

SCF 230 может обеспечивать логику услуги и функции для поддержания исполнения такой логики услуг. SCF может обеспечить авторизацию услуги во время инициирования сеанса и модификации сеанса, который может включать в себя проверку PSS и подпись на услугу пользователя MBMS для того, чтобы разрешить или запретить доступ к услуге. SCF может выбрать связанные с этим функции мультимедиа PSS и MBMS. Для доставки на основе HTTP, SCF может действовать как прокси или двухсторонний агент пользователя (B2BUA). Для MBMS, SCF может действовать как завершающий агент пользователя (UA). Адаптер 250 HTTP/SIP может устанавливать связь сеанса SIP с входящими запросами HTTP. HTTP-сервер 260 может предоставить DASH-форматированное содержание для доставки на основе HTTP. Модуль PCRF 270 может управлять тарификацией и установлением ресурсов в базовой сети 280 RAN и PS. Модуль SSF 290 может предоставить список имеющихся PSS (в том числе DASH на основе HTTP) и услуги пользователя MBMS и связанную с этим информацию описания услуги. Модуль SSF можно персонализировать с идентичностью клиента. Адаптер 292 PSS может выполнять передачу двунаправленного протокола между SIP и RTSP для того, чтобы предложить управление сервером PSS. BMSC.UPF 240 может включать в себя подфункции пользовательской плоскости (UPF) центра услуг широковещательной и многоадресной передачи (BMSC). BMSC.UPF может предоставить DASH-форматированное содержание для загрузки MBMS.

Фиг.2 иллюстрирует подфункциональную архитектуру BMSC и связанные с ней интерфейсы между UE и BMSC. BMSC или BM-SC 242 может поддерживать связь с и/или управление поставщиком содержания/источником 246 многоадресного широковещания. BM-SC может обеспечивать функции 244 доставки MBMS.

Фиг.3 иллюстрирует пример переключения с нагрузки MBMS на доставку на основе HTTP DASH-форматированного содержания в сеансе доставки содержания на основе IMS. Доставку загрузки 300а-с MBMS на основе FLUTE можно было инициировать ранее, и UE 210 может принимать DASH-форматированное содержание из BMSC.UPF 240. Загрузка MBMS может представлять собой механизм, используемый услугой пользователя MBMS в содержании доставки. Загрузка MBMS может относиться к способу доставки MBMS, который использует однонаправленные каналы MBMS при доставке содержания, и может использовать связанные с этим процедуры. Способ загрузки MBMS, который используется здесь, можно применить для доставки аналоговой среды (например, видео в реальном времени) или для доставки дискретных объектов (например, файлов).

UE 210 может начать потоковую передачу HTTP путем загрузки медиасегментов из HTTP-сервера после получения MPD. Чтобы переключить с загрузки MBMS на доставку на основе HTTP DASH-форматированного содержания, повторное приглашение Re-INVITE 302 протокола инициирования сеанса связи (SIP) (SIP Re-INVITE) можно выдавать с помощью UE и отправлять в подсистему 220 IM CN. Предложение протокола описания сеанса (SDP) и универсальный идентификатор ресурса (URI) запроса можно включить в сообщение повторного приглашения SIP Re-INVITE.

URI запроса может относиться к сеансу доставки на основе HTTP или сеансу SIP, который пользователь желает активизировать. URI запроса может состоять из пользовательской части и доменной части. Пользовательская часть может содержать идентификатор содержания, извлеченный из информации описания услуги пользователя из модуля SSF. Идентификатор содержания может извлечь из информации выбора услуги. Доменная часть может включать в себя доменное имя поставщика услуги, полученное от модуля SSF. Заголовок ′То′ сообщения SIP Re-INVITE 302 и 304 или SIP INVITE 306 может содержать одинаковый URI, как URI запроса. Заголовок ′From′ сообщения SIP Re-INVITE или SIP INVITE может показывать общедоступную идентичность пользователя. Идентификатор содержания можно извлечь из информации выбора услуги.

Предложение SDP может включать в себя возможности мультимедиа и политики, доступные для сеанса потоковой передачи HTTP. Например, предложение SDP может нести в себе параметры, показывающие тип рекомендованной услуги (например, PSS, MBMS или услуга потоковой передачи HTTP), идентификатор содержания и идентификатор целевого UE. Предложение SDP можно получить, основываясь на анализе MPD, а также на основе параметров, принятых из модуля SSF во время процедуры выбора услуги. Предложение SDP можно получить на основе параметров, полученных во время процедуры для извлечения отсутствующих параметров с помощью сообщения SIP OPTIONS.

Запрос сервера HTTP для MPD может быть необязательным, так как UE может уже вызвать MPD во время загрузки MBMS. В примере, если MPD не было получено ранее, UE может отправить запрос HTTP GET в HTTP-сервер для того, чтобы загрузить MPD. В другом примере, предложение SDP может включать в себя ранее согласованные описания мультимедиа с портом, установленным на нуль и два или более дополнительных описаний мультимедиа. Например, описания мультимедиа могут включать в себя канал управления мультимедиа (то есть канал доставки MPD) и канал доставки мультимедиа (то есть канал доставки для одноадресных потоковых передач по HTTP). Предложение SDP может включать в себя информацию для доставки на основе HTTP, такую как описание мультимедиа, канал управления мультимедиа, канал доставки мультимедиа, канал управления MPD, канал доставки для одноадресной потоковой передачи по HTTP, возможности мультимедиа, доступные на HTTP сервере, политики, доступные на HTTP-сервере, и комбинацию из этой информации.

В другом примере, предложение SDP для доставки мультимедиа может быть аналогичным предыдущему предложению SDP, сделанному для широковещания в терминах кодеков и транспортного протокола. Доставка на основе HTTP может работать поверх TCP, тогда как доставка загрузки MBMS на основе FLUTE может работать поверх протокола пользовательских дейтаграмм (UDP). TCP и UDP могут представлять собой протоколы на транспортном уровне. Изменение в основополагающем протоколе, таком как UDP-TCP, можно указать в SDP. UDP представляет собой один из членов стека Интернет-протоколов. С помощью UDP компьютерные приложения могут посылать сообщения, которые называются как дейтаграммы, в другие хосты по IP-сети, не требуя предыдущей связи для установки специальных каналов передачи или каналов передачи данных.

Подсистема 220 IM CN может пересылать сообщение SIP Re-INVITE 304 в SCF 230. После получения запроса на модификацию SIP в SIP Re-INVITE, SCF может определить, имеет ли программа, которая транслируется в текущий момент времени, поддержку переключения MBMS на HTTP (поддержка переключения MBMS-HTTP). Если переключение MBMS на HTTP является недоступным для UE 210, модификацию сеанса можно отклонить и можно поддерживать первоначальную загрузку или сеанс MBMS (наряду с предыдущими зарезервированными ресурсами).

Если переключение MBMS на HTTP доступно для UE 210, то SCF 230 может действовать как B2BUA. После получения SIP Re-INVITE 304 из UE, SCF может проверить или верифицировать права пользователя для запрашиваемого DASH-форматированного содержания, идентифицировать то, что запрос предназначен для потоковой передачи HTTP, выбрать адаптер 250 HTTP/SIP и переслать запрос SIP (SIP INVITE 306) в адаптер HTTP/SIP, который может быть ответственным за услугу потоковой передачи HTTP путем изменения URI запроса, соответственно. При получении ответа 301 или 302 из адаптера HTTP/ SIP, SCF может не переслать сообщение с ответом 301 или 302 в UE. Адаптер HTTP/SIP может вернуть ответ 301, если этот адаптер HTTP/SIP не управляет запрашиваемым содержанием. Адаптер HTTP/SIP может возвратить ответ 302 по любым другим причинам, отличным от отсутствия управления запросом содержания (ответом 301). Например, сообщение с ответом 302 можно отправить по такой причине, как выравнивание нагрузки.

Если URI запроса содержит идентификатор содержания в пользовательской части или доменное имя в доменной части, SCF 230 может выбрать подходящий адаптер 250 HTTP/SIP и выработать запрос SIP INVITE 306 в выбранном адаптере HTTP/SIP. Заголовок ′То′ запроса SIP INVITE может содержать такой же идентификатор содержания, как и в запросе URI запроса на модификацию SIP, принятого из UE 210 с помощью SCF.

SCF 230 может отправить запрос SIP INVITE 306 в адаптер 250 HTTP/SIP с параметрами SDP, включающими в себя возможности мультимедиа и политики, доступные для сеанса потоковой передачи HTTP. Запрос SIP INVITE можно получить на основании анализа MPD. В одном примере предложение SDP может включать в себя ранее согласованные описания мультимедиа с портом, установленным на нуль, и два или более дополнительных описаний мультимедиа. Например, описания мультимедиа могут включать в себя канал управления мультимедиа (то есть канал доставки MPD) и канал доставки мультимедиа (то есть канал доставки для одноадресных потоков по HTTP).

SCF 230 может разъединить сеанс загрузки MBMS на основе FLUTE между BMSC.UPF 240 и UE 210. SCF может отправить запрос 310 на завершение MBMS или сообщение в BMSC.UPF. Протокол связи между SCF и BMSC.UPF можно определить с помощью технических условий (3GPP) (TS) 26.346 V10.0.0, опубликованных в марте 2011 г. BMSC.UPF может отключить любого поставщика содержания/источник многоадресного широковещания (246 на фиг.2) и завершить загрузку MBMS. BMSC.UPF может отправить сообщение с подтверждением (АСК) 312 в SCF, показывающим успешное завершение, или отправить сообщение с отрицательным подтверждением (NACK) в SCF, показывающим неудачное завершение или отключение ресурсов.

После получения запроса на инициирование сеанса потоковой передачи HTTP (например, SIP INVITE 306), адаптер 250 HTTP/SIP может проверить идентификатор содержания, присутствующий в пользовательской части заголовка ′То′, и параметры мультимедиа в SDP и выбрать HTTP-сервер 260 согласно URI запроса. Адаптер HTTP/SIP может отправить сообщение HTTP POST в HTTP-сервер, включающее в себя IP-адрес UE. Адаптер HTTP/SIP может принять решение относительно переадресации запроса в другой сервер адаптера HTTP/SIP. В случае переадресации запроса в другой сервер адаптера HTTP/SIP, адаптер HTTP/SIP может возвратить ответ 301, если этот адаптер HTTP/SIP не управляет содержанием, или ответ 302 по любым другим причинам, таким как балансирование нагрузки. Переадресация адаптера HTTP/SIP может указать один или более адресов HTTP/SIP места назначения в заголовке контакта.

Адаптер 250 HTTP/SIP может возвратить сообщение подтверждения SIP, такое как сообщение SIP OK 308 (например, сообщение SIP OK 200), в SCF 230. Подтверждение SIP может включать в себя ответ SDP. Ответ SDP может описывать сеанс потоковой передачи HTTP (или сеанс SIP). Ответ SDP может включать в себя информацию для доставки на основе HTTP, такую как описание мультимедиа, канал управления мультимедиа, канал доставки мультимедиа, канал управления описанием представления мультимедиа (MPD), описание доставки и комбинацию из этой информации.

SCF 230 может пересылать SIP OK 314 в подсистему 220 IM CN. Подсистема IM CN может взаимодействовать с модулем функции правил политики и тарификации (PCRF) архитектуры управления политикой и начислением (РСС) для совершения резервирования QoS для установления 316а однонаправленного канала QoS. Модуль PCRF может обеспечить установление 316b-d однонаправленного канала QoS между UE и IMS. Подсистема IM CN может затем переслать SIP OK 318 (например, сообщение SIP OK 200) в UE 210.

Посредническую функцию управления состояния вызова (P-CSCF) можно ис