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

Изобретение относится к технологии беспроводной мобильной связи. Техническим результатом является обеспечение способа переключения с загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) на доставку на основе протокола передачи гипертекста (HTTP) динамичной адаптивной потоковой передачи поверх HTTP (DASH)-форматированного содержания в сети мультимедийной подсистемы (IMS) на базе Интернет-протокола. Предложенный способ включает в себя модуль функции управления услугой (SCF), принимающий повторное приглашение протокола инициирования сеанса (SIP), при приеме мобильным устройством загрузки MBMS в сеансе доставки содержания, включающего DASH-форматированное содержание, при этом SCF-модуль может отправлять приглашение SIP на адаптер HTTP/SIP для выбора HTTP-сервера для доставки на основе HTTP. SCF-модуль может принимать подтверждение SIP от адаптера HTTP/SIP, показывающее выбор HTTP-сервера для сеанса доставки содержания. SCF-модуль может пересылать подтверждение SIP на мобильное устройство, показывающее переключение на HTTP-сервер для сеанса доставки содержания. 4 н. и 26 з.п. ф-лы, 8 ил.

 

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

Технология беспроводной мобильной связи использует различные стандарты и протоколы для передачи данных между передающей станцией и беспроводным мобильным устройством. Некоторые беспроводные устройства поддерживают связь с использованием мультиплексирования с ортогональным частотным разделением каналов (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) можно использовать в качестве прикладной функции в архитектуре РСС. PCRF 270 может принимать решение относительно того, какое управление политикой QoS выполняется для услуги пользователя PSS и MBMS, инициируемой и управляемой IMS. PCRF может использовать SDP, полученную из P-CSCF во время установления сеанса для вычисления правильной авторизации QoS. Соответствующее существование однонаправленных каналов можно использовать или новые требуемые однонаправленные каналы можно выделять с помощью PCRF. Представляется возможным управление однонаправленным каналом, инициированное сетью, и управление однонаправленным каналом, инициированное UE. После получения окончательного SDP, UE 210 может инициировать установление требуемых однонаправленных каналов за исключением случаев, когда процедура выделения однонаправленного канала, инициированное сетью, уже выполняется. Альтернативно UE было выполнено с возможностью использования управления ресурсами, инициированного сетью.

После получения SIP OK 318, UE 210 может покинуть многоадресный канал и может начать загрузку DASH-форматированного содержания по HTTP (адаптивная доставка 320а-с содержания DASH на основании HTTP) таким образом, чтобы сегменты мультимедиа можно было доставить UE с использованием зарезервированного QoS.

В другом примере, радиоинтерфейс между мобильным устройством, таким как UE, и передающей станцией, такой как eNB, может поддерживать одноадресную и многоадресную доставку содержания для того, чтобы разрешить переключение между загрузкой MBMS и доставкой на основе HTTP DASH-форматированного содержания. eNB RAN может поддерживать связь с IMS и модулями, находящимися в пределах IMS, такими как SCF-модуль. Радиоинтерфейс может включать в себя 3GPP LTE или стандарт 802.16. Мобильное устройство и/или передающая станция может использовать 3GPP LTE или протокол 802.16. Стандарт 3GPP LTE может включать в себя LTE Rel-8 (2008), LTE Rel-9 (2009) и LTE Rel-10 (2011). Стандарт IEEE 802.16 может включать в себя IEEE 802.16е-2005, IEEE 802.16k-2007, IEEE 802.16-2009, IEEE 802.16j-2009, IEEE 802.16h-2010 и IЕЕЕ 802.16m-2011.

Фиг.4 иллюстрирует пример переключения с нагрузки MBMS на доставку на основе HTTP DASH-форматированного содержания в сеансе доставки содержания, где файл метаданных MPD получен перед SIP Re-INVITE. UE 210 может сделать запрос для MPD 322 из HTTP-сервера 260. HTTP-сервер может отправить MPD 324 в UE. UE может использовать информацию в MPD для генерирования SIP Re-INVITE 302 для дальнейшего отправления в подсистему 220 IM CN. Остальные операции, показанные на фиг.4, могут быть аналогичными операциям, показанным на фиг.3, которая была описана ранее.

Фиг.5 иллюстрирует пример переключения с доставки на основе HTTP на загрузку MBMS DASH-форматированного содержания в сеансе доставки содержания. Доставку на основе HTTP (например, адаптивная доставка 330а-с содержания DASH на основе HTTP) можно было инициировать раньше, и UE 210 может принимать DASH-форматированное содержание по HTTP из HTTP-сервера 260. DASH-форматированное содержание можно доставить в существующем сеансе SIP.

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

В другом примере MPD может включать в себя информацию для переключения с доставки на основе HTTP на доставку загрузки MBMS, и UE может использовать такую информацию при выдаче запроса на модификацию сеанса, например, SIP Re-INVITE, чтобы переключить на загрузку MBMS. Сообщение SIP Re-INVITE может также содержать URI запроса, который может включать в себя публичный идентификатор услуги (PSI) услуги загрузки MBMS. Заголовок ′То′ SIP Re-INVITE может содержать такой же URI, как и в URI запроса, и заголовок ′From′ SIP Re-INVITE может указывать на общедоступную идентичность пользователя.

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

После получения запроса на модификацию SIP (например, SIP Re-INVITE), SCF 230 может определить, имеет ли содержание, доставляемое в текущий момент времени, поддержку на переключение HTTP на MBMS (например, поддержку переключения НТТР-MBMS). Если переключение HTTP на MBMS недоступно для UE 210, модификацию сеанса можно отклонить и можно поддерживать первоначальный сеанс HTTP (наряду с предыдущими зарезервированными ресурсами). Если переключение HTTP на MBMS доступно для UE, SCF может действовать как B2BUA для установления сеанса загрузки MBMS на основе FLUTE между BMSC.UPF и UE. Протокол связи между SCF и BMSC.UPF можно определить с помощью технических условий (TS) 3GPP 26.346 V10.0.0, опубликованных в марте 2011 г. SCF может отправить приглашение 340 MBMS в BMSC.UPF. Когда BMSC.UPF установлено для загрузки MBMS, BMSC.UPF может отправлять сообщение с подтверждением 342 MBMS в SCF. Если переключение HTTP на MBMS является доступным для UE, SCF может отправить сообщение SIP BYE 336 (запрос на завершение HTTP) в адаптер 250 HTTP/SIP, чтобы завершить сеанс SIP между SCF и адаптером HTTP/SIP.

Адаптер 250 HTTP/SIP может затем разъединить HTTP-сервер 260 и может отправить сообщение подтверждения SIP, такое как SIP OK 338, в SCF 230. После получения сообщения SIP OK из адаптера HTTP, SCF может отправить сообщение SIP OK 344 в подсистему 220 IM CN. Подтверждение SIP может включать в себя ответ SDP. Ответ SDP может включать в себя информацию для загрузки MBMS, такую как описание мультимедиа, канал управления мультимедиа, канал доставки мультимедиа, канал управления описанием представления мультимедиа (MPD), описание доставки и комбинация из этой информации.

Подсистема 220 IM CN может переслать сообщение SIP OK 348 в UE 210. Сообщение SIP OK может включать в себя ответ SDP. P-CSCF можно использовать в качестве прикладной функции в архитектуре РСС. PCRF может принять решение относительно того, какое управление политикой QoS выполняется для пользовательской услуги и связи MBMS, инициируемой и управляемой IMS, для принудительного применения 346a-d однонаправленного канала QoS (аналогично процессу для принудительного применения 316a-d однонаправленного канала QoS, иллюстрированного на фиг.3 между подсистемой IM CN, модулем PCRF и UE). Для переключения на загрузку MBMS, PCRF может не инициировать установления конкретного однонаправленного канала.

После того, как UE 210 получит ответ SIP OK, UE может активизировать соответствующую услугу пользователя MBMS, как описано в SDP, такую как услуга загрузки MBMS на основании FLUTE 350а-с. Инициирование получения загрузки MBMS может соответствовать процедуре активизации режима широковещания MBMS или процедуре активизации режима мультивещания MBMS. UE может проверить параметр сеанса FLUTE в принятом SDP и получить данные загрузки MBMS, соответственно. В случае, когда таблица доставки файлов (FDT) может быть недоступной, UE может получить FDT согласно атрибуту fdt_address в ответе SDP. FDT может содержать информацию об описании содержания для файлов, доставленных в сеансе FLUTE. В случае неполной загрузки, UE может исполнить процедуры восстановления файлов по направлению к серверу, выполняющему восстановление, показанному с помощью атрибута repair-server-address в ответе SDP.

Переключение между загрузкой MBMS и доставкой на основе HTTP может представлять собой агностик характеристик конкретного радиоинтерфейса (например, RAN). Любой радиоинтерфейс или комбинация из многочисленных радиоинтерфейсов может применяться до тех пор, пока связанные с ними сети смогут проводить доставку HTTP на основе IMS и функции доставки загрузки MBMS. Переключение между загрузкой MBMS и доставкой на основе HTTP можно использовать в беспроводных глобальных сетях (WWANs), основанных на стандарте 3GPP или 802.16, и в приложениях на основе IMS, где желательна оптимизированная доставка DASH-форматированного мультимедийного содержания по этим сетям. Процедура сигнализации для обеспечения переключения между доставкой на основе HTTP и доставкой загрузки MBMS для потоковой передачи DASH-форматированного содержания позволяет повысить качество восприятия для пользователя.

На другой пример представлен способ 500 переключения с загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) на доставку на основе протокола передачи гипертекста (HTTP) динамичной адаптивной потоковой передачи поверх HTTP (DASH)-форматированного содержания, как показано на схеме последовательности операций на фиг.6. Способ включает в себя операцию приема повторного приглашения протокола инициирования сеанса связи (SIP) в модуле функции управления услугой (SCF) из мобильного устройства во время, когда мобильное устройство принимает загрузку MBMS в сеансе доставки содержания, включающего в себя DASH-форматированное содержание (этап 510). Далее следует операция отправления приглашения SIP из SCF-модуля в адаптер HTTP/SIP для выбора HTTP-сервера для доставки на основе HTTP (этап 520). В следующей операции способ позволяет принимать подтверждение SIP в SCF-модуле из адаптера HTTP/SIP, показывающее выбор HTTP-сервера для сеанса доставки содержания (этап 530). Способ может дополнительно включать в себя пересылку подтверждения SIP из SCF-модуля в мобильное устройство, показывающего переключение на HTTP-сервер для сеанса доставки содержания (этап 540).

В другом примере представлен способ 600 переключения с доставки на основе протокола передачи гипертекста (HTTP) динамичной адаптивной потоковой передачи по HTTP (ВАЗН)-форматированного содержания на загрузку услуг мультимедийной, широковещательной и многоадресной передачи (MBMS), как показано на фиг.7 в схеме последовательности операций. Способ включает в себя операцию получения повторного приглашения протокола инициирования сеанса (SIP) в модуле функции управления услугой (SCF) из мобильного устройства во время, когда мобильное устройство принимает доставку на основе HTTP в сеансе доставки содержания, включающего в себя DASH-форматированное содержание (этап 610). Далее следует операция отправления сообщения приглашения из SCF-модуля в BMSC для инициирования центра услуг широковещательной и многоадресной передачи (BMSC) для загрузки MBMS (этап 620). В следующей операции способа можно отправлять запрос на завершение SIP из SCF-модуля в адаптер HTTP/SIP для завершения доставки на основе HTTP (этап 630). Далее следует операция приема подтверждения SIP в SCF-модуле из адаптера HTTP/SIP, показывающего завершение доставки на основе HTTP (этап 640). Способ может дополнительно включать в себя пересылку подтверждения SIP из SCF-модуля в мобильное устройство, показывающего переключение на BMSC для сеанса доставки содержания (этап 650).

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

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

В другом примере передающая станция может поддерживать беспроводную связь с мобильным устройством. На фиг.8 представлена примерная иллюстрация мобильного устройства, такого как пользовательское оборудование (UE), мобильная станция (MS), мобильное беспроводное устройство, мобильное коммуникационное устройство, планшетное устройство, телефонная трубка или другой тип мобильного беспроводного устройства. Мобильное устройство может включать в себя одну или более антенн, выполненных с возможностью поддержания связи с узлом, макроузлом, узлом низкой мощности (LPN) или передающей станцией, такой как базовая станция (BS), усовершенствованный Узел В (Node В (eNB)), блок базовой полосы (BBU), дистанционный головной радиоузел (RRH), дистанционное радиооборудование (RRE), ретрансляционная станция (RS), радиооборудование (RE) или другой тип точки доступа беспроводной глобальной сети (WWAN). Мобильное устройство можно выполнить с возможностью поддержания связи с использованием, по меньшей мере, одного стандарта беспроводной связи, включая 3GPP LTE, WiMAX, высокоскоростной пакетный доступ (HSPA), Bluetooth и WiFi. Мобильное устройство может поддерживать связь с использованием отдельных антенн для каждого стандарта беспроводной связи или совместно используемых антенн для многочисленных стандартов беспроводной связи. Мобильное устройство может поддерживать связь в беспроводной локальной сети (WLAN), беспроводной персональной сети (WPAN) и/или WW AN.

На фиг.8 также представлена иллюстрация микрофона и один или более громкоговорителей, который можно использовать для аудиовхода и выхода из мобильного устройства. Экран устройства отображения может представлять собой жидкокристаллический (LCD) экран или другой тип экрана устройства отображения, такой как дисплей на основе органических светоизлучающих диодов (OLED). Экран устройства отображения можно сконфигурировать в виде сенсорного экрана. Сенсорный экран может использовать емкостную, резистивную или другого типа технологию сенсорного экрана. Прикладной процессор и графический процессор могут быть соединены с внутренней памятью для обеспечения возможности обработки и отображения. Порт энергонезависимой памяти можно также использовать для обеспечения опций ввода/вывода данных для пользователя. Порт энергонезависимой памяти можно также использовать для расширения возможностей памяти мобильного устройства. Клавиатуру можно выполнить как единое целое с мобильным устройством или беспроводным образом и подсоединить к мобильному устройству для обеспечения дополнительного ввода пользователя. Виртуальную клавиатуру можно также выполнить с использованием сенсорного экрана.

Различные технологии или некоторые аспекты, или их части могут принимать вид программного кода (то есть инструкций), осуществленных на материальных носителях, таких как гибкие диски, CD-ROM, жесткие диски, энергонезависимый машиночитаемый носитель информации или любой другой машиночитаемый носитель информации, в котором, когда программный код загружается в и исполняется с помощью машины, такой как компьютер, машина становится устройством для применения на практике различных технологий. В случае исполнения программного кода на программируемых компьютерах, вычислительное устройство может включать в себя процессор, носитель информации, считываемый с помощью процессора (включая энергозависимую и энергонезависимую память и/или элементы памяти), по меньшей мере, одно устройство ввода и, по меньшей мере, одно устройство вывода. Энергозависимая и энергонезависимая память и/или элементы памяти могут представлять собой RAM (ОЗУ), EPROM (программируемое постоянное запоминающее устройство (СППЗУ)), флэш-память, привод оптического диска, магнитный жесткий диск или другой носитель, предназначенный для хранения данных в электронном виде. Базовая станция и мобильная станция могут также включать в себя модуль приемопередатчика, модуль счетчика, модуль обработки и/или модуль генератора тактовых импульсов или модуля таймера. Одну или более программ, которые могут реализовывать или использовать различные технологии, описанные здесь, могут использовать интерфейс для прикладного программирования (API), системы управления многократного использования и тому подобного. Такие программы можно реализовать на процедурно- или объектно-ориентированных языках программирования высокого уровня для обеспечения связи с компьютерной системой. Однако, при необходимости, программу(ы) можно реализовать на языке ассемблера или машинном языке, В любом случае, язык может представлять собой транслируемый или интерпретируемый язык и действующий совместно с аппаратными реализациями.

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

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

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

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

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

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

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

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

1. Энергонезависимый машиночитаемый носитель информации, хранящий машиночитаемый программный код, записанный на нем, причем машиночитаемый программный код выполнен с возможностью при исполнении, осуществления способа переключения с загрузки услуг мультимедийной, широковещательной и многоадресной передачи (MBMS) на загрузку на основе потоковой передачи с коммутацией пакетов (PSS), содержащего этапы, на которых:
получают с помощью модуля функции управления услугой (SCF) повторное приглашение протокола инициирования сеанса связи (SIP) от пользовательского оборудования (UE), при приеме UE загрузки MBMS;
отправляют с помощью SCF-модуля приглашение SIP адаптеру протокола передачи гипертекста (HTTP)/SIP для выбора HTTP-сервера для загрузки на основе PSS;
принимают с помощью SCF-модуля подтверждение SIP, указывающее идентификатор выбранного HTTP-сервера, от адаптера HTTP/SIP; и
пересылают с помощью SCF-модуля подтверждение SIP на UE для вызова переключения UE с загрузки на основе MBMS на загрузку на основе PSS.

2. Энергонезависимый машиночитаемый носитель по п.1, дополнительно содержащий этап, на котором с помощью SCF-модуля отправляют запрос на завершение в центр услуг широковещательной и многоадресной передачи (BMSC) для завершения загрузки MBMS после получения повторного приглашения SIP SCF-модулем.

3. Энергонезависимый машиночитаемый носитель по п.1, в котором SCF-модуль, ранее ссылающийся на доменное имя, или идентификатор содержания, ассоциированный с центром услуг широковещательной и многоадресной передачи (BMSC), выполнен с возможностью обеспечения загрузки MBMS на UE, и повторного приглашения SIP, включающего в себя универсальный идентификатор ресурса (URI) запроса для HTTP-сервера для обеспечения загрузки на основе PSS, и HTTP-сервер для загрузки на основе PSS выбранной на основании доменного имени или идентификатора содержания, содержащегося в URI запросе, ссылающемся на HTTP-сервер, причем доменное имя и идентификатор содержания, ссылающиеся на HTTP-сервер, отличаются от доменного имени и идентификатора содержания, ассоциированных с BMSC.

4. Энергонезависимый машиночитаемый носитель по п.1, дополнительно содержащий этап, на котором с помощью SCF-модуля определяют, имеет ли сеанс доставки содержания поддержку для переключения с MBMS на PSS перед отправкой приглашения SIP от SCF-модуля на адаптер HTTP/SIP.

5. Энергонезависимый машиночитаемый носитель по п.1, в котором повторное приглашение SIP принимают SCF-модулем от UE через подсистему базовой сети мультимедийной подсистемы (IMS) на базе Интернет-протокола (IP) (IM CN), а подтверждение SIP пересылают от SCF-модуля на UE через подсистему IM CN.

6. Энергонезависимый машиночитаемый носитель по п.1, в котором радиоинтерфейс между UE и передающей станцией сети радиодоступа (RAN), поддерживающий связь с модулем SCF, выполнен с возможностью поддержки одноадресной и многоадресной доставки содержания.

7. Энергонезависимый машиночитаемый носитель по п.1, в котором UE выполнено с возможностью использования протокола, выбранного из группы, состоящей из стандарта долгосрочного развития (LTE) проекта партнерства 3-го поколения (3GPP) и стандарта 802.16 Института инженеров по электротехнике и радиотехнике (IEEE).

8. Энергонезависимый машиночитаемый носитель по п.1, в котором подтверждение SIP включает в себя ответ протокола описания сеанса (SDP), включающего в себя информацию для загрузки на основе PSS, выбранной из группы, состоящей из описания мультимедиа, канала управления мультимедиа, канала доставки мультимедиа, канала управления описанием представления мультимедиа (MPD), описания доставки и их комбинации.

9. Энергонезависимый машиночитаемый носитель по п.1, в котором повторное приглашение SIP включает в себя предложение протокола описания сеанса (SDP), включающего в себя информацию для загрузки на основе PSS, выбранную из группы, состоящей из описания мультимедиа, канала управления мультимедиа, канала доставки мультимедиа, канала управления описанием представления мультимедиа (MPD), канала доставки для одноадресной потоковой передачи по протоколу передачи гипертекста (HTTP), возможности мультимедиа, имеющиеся на HTTP-сервере, политики, имеющиеся на HTTP-сервере, кодеки и транспортные протоколы и их комбинации.

10. Энергонезависимый машиночитаемый носитель по п.9, в котором возможности мультимедиа и политики, имеющиеся на HTTP-сервере для сеанса потоковой передачи HTTP, получают при загрузке MBMS из ранее принятого файла метаданных MPD.

11. Энергонезависимый машиночитаемый носитель по п.1, дополнительно содержащий этап, на котором верифицируют права пользователя для загрузки на основе PSS перед отправкой приглашения SIP от SCF-модуля на адаптер HTTP/SIP.

12. Энергонезависимый машиночитаемый носитель по п.1, в котором повторное приглашение SIP включает в себя сообщение SIP Re-INVITE, приглашение SIP включает в себя сообщение SIP INVITE, и подтверждение SIP включает в себя SIP OK 200.

13. Энергонезависимый машиночитаемый носитель по п.1, в котором загрузки на основе PSS функционирует с использованием протокола управления передачи (TCP) на транспортном уровне, а доставка MBMS функционирует с использованием протокола дейтаграмм пользователя (UDP) на транспортном уровне и доставки файла по протоколу однонаправленного транспорта (FLUTE).

14. Энергонезависимый машиночитаемый носитель по п.1, в котором SCF-модуль включен в мультимедийную подсистему (IMS) на базе Интернет-протокола (IP).

15. Энергонезависимый машиночитаемый носитель информации, хранящий машиночитаемый программный код, записанный на нем, причем машиночитаемый программный код выполнен с возможностью при исполнении, осуществления способа переключения с доставки протокола передачи гипертекста (HTTP) динамичной адаптивной потоковой передачи поверх HTTP (DASH)-форматированного содержания на загрузку услуги мультимедийной, широковещательной и многоадресной передачи (MBMS), содержащего этапы, на которых:
принимают с помощью модуля функции управления услугой (SCF) повторное приглашение протокола инициирования сеанса (SIP) от мобильного устройства, при приеме мобильным устройством доставки на основе HTTP в сеансе доставки содержания, включая DASH-форматированное содержание;
отправляют с помощью SCF-модуля сообщение приглашения в центр широковещательной и многоадресной передачи (BMSC) для инициирования BMSC для загрузки MBMS сеанса доставки содержания;
отправляют с помощью SCF-модуля запрос на завершение SIP на адаптер HTTP/SIP для завершения доставки на основе HTTP;
принимают с помощью SCF-модуля подтверждение SIP, показывающее завершение доставки на основе HTTP от адаптера HTTP/SIP; и
пересылают с помощью SCF-модуля подтверждение SIP, показывающее переключение на BMSC для сеанса доставки содержания, на мобильное устройство.

16. Энергонезависимый машиночитаемый носитель по п.15, дополнительно содержащий этап, на котором принимают подтверждение BMSC SCF-модуля от BMSC, показывающее выбор BMSC для сеанса доставки содержания после отправки сообщения приглашения SCF-модулем на BMSC.

17. Энергонезависимый машиночитаемый носитель по п.15, в котором SCF-модуль, ранее ссылающийся на доменное имя или идентификатор содержания, ассоциированный с HTTP-сервером, выполнен с возможностью обеспечения передачи DASH-форматированного содержания через доставку на основе HTTP в сеансе доставки содержания, при этом мобильное устройство выполнено с возможностью приема доставки на основе HTTP, и повторного приглашения SIP, включающего в себя универсальный идентификатор ресурса (URI) запроса для BMSC для обеспечения подачи DASH-форматированного содержания через загрузку MBMS в том же самом сеансе доставки содержания, причем различные URI запросы используются для выбора BMSC для загрузки MBMS сеанса доставки содержания, и BMSC для загрузки MBMS выбирают на основании доменного имени или идентификатора содержания, содержащегося в URI запроса, ссылающегося на BMSC, а доменное имя и идентификатор содержания, ассоциированные с HTTP-сервером, отличаются от доменного имени и идентификатора содержания, ссылающихся на BMSC.

18. Энергонезависимый машиночитаемый носитель по п.15, в котором радиоинтерфейс между мобильным устройством и передающей станцией сети радиодоступа (RAN), поддерживающей связь с модулем SCF, выполнен с возможностью поддержки одноадресной и многоадресной доставки содержания.

19. Энергонезависимый машиночитаемый носитель по п.15, в котором мобильное устройство выполнено с возможностью использования протокола, выбранного из группы, состоящей из стандарта долгосрочного развития (LTE) проекта партнерства 3-го поколения (3GPP) и стандарта 802.16 Института инженеров по электротехнике и радиотехнике (IEEE).

20. Энергонезависимый машиночитаемый носитель по п.15, в котором повторное приглашение SIP включает в себя предложение протокола описания сеанса (SDP), включающее в себя информацию для загрузки MBMS, выбранную из группы, состоящей из описания мультимедиа, канала управления мультимедиа, канала доставки мультимедиа, канала управления описанием представления мультимедиа (MPD), канала доставки для многоадресной потоковой передачи по MBMS, возможности мультимедиа, доступные в BMSC, политики, доступные в BMSC, кодеки и транспортные протоколы и их комбинации.

21. Энергонезависимый машиночитаемый носитель по п.15, в котором подтверждение SIP, переданное SCF-модулем, включает в себя ответ протокола описания сеанса (SDP), включающий в себя информацию для загрузки MBMS, выбранную из группы состоящей из описания мультимедиа, канала управления мультимедиа, канала доставки мультимедиа, канала управления описанием представления мультимедиа (MPD), описания доставки, кодеков и транспортных протоколов и их комбинаций.

22. Энергонезависимый машиночитаемый носитель по п.15, дополнительно содержащий этап, на котором выполняют процедуру авторизации услуги для проверки прав услуги DASH-форматированного содержания посредством загрузки MBMS согласно информации о подписке пользователя перед отправкой сообщения приглашения от SCF-модуля на BMSC.

23. Энергонезависимый машиночитаемый носитель по п.15, в котором повторное приглашение SIP включает в себя сообщение SIP Re-INVITE, завершение SIP включает в себя сообщение SIP BYE, и подтверждение SIP включает в себя сообщение SIP OK 200.

24. Энергонезависимый машиночитаемый носитель по п.15, в котором доставка на основе HTTP функционирует с использованием протокола управления передачи (TCP) на транспортном уровне, а загрузка MBMS функционирует с использованием протокола дейтаграммы пользователя (UDP) на транспортном уровне и доставки файла по протоколу однонаправленного транспорта (FLUTE).

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

26. SCF-модуль по п.25, дополнительно содержащий модуль обработки, выполненный с возможностью верификации прав пользователя для DASH-форматированного содержания посредством доставки на основе HTTP и выполнения процедуры авторизации услуги для проверки прав услуги DASH-форматированного содержания посредством загрузки MBMS согласно информации о пользовательской подписке.

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

28. Мобильное устройство по п.27, в котором мобильное устройство выполнено с возможностью осуществления связи с подсистемой IM CN через радиоинтерфейс, выполненный с возможностью одноадресной и многоадресной доставки содержания.

29. Мобильное устройство по п.27, в котором мобильное устройство выполнено с возможностью использования протокола, выбранного из группы, состоящей из стандарта долгосрочного развития (LTE) проекта партнерства 3-го поколения (3GPP) и стандарта 802.16 Института инженеров по электротехнике и радиотехнике (IEEE).

30. Мобильное устройство по п.27, в котором мобильное устройство выполнено с возможностью соединения по меньшей мере с одной из беспроводной локальной сети (WLAN), беспроводной персональной сети (WPAN) и беспроводной глобальной сети (WWAN), при этом мобильное устройство включает в себя антенну, сенсорный экран устройства отображения, громкоговоритель, микрофон, графический процессор, прикладной процессор, внутреннюю память, порт энергонезависимой памяти или их комбинации.