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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

Обмен сигналами о возможностях (или просто сигнализация о возможностях) позволяет серверам содержания мультимедиа предоставлять самым разнообразным устройствам контент, адаптированный для конкретного клиентского мобильного устройства (именуемого абонентским терминалом или просто терминалом UE), запросившего контент. Сигнализация о возможностях представляет собой стандартизованную функцию для серверов, которые могут использовать стандарты одного или нескольких типов потоковых сервисов, и в том числе разработанный Группой проекта партнерства 3-го поколения (3GPP) потоковый сервис с пакетной коммутацией (PSS), динамически адаптивная потоковая передача по протоколу HTTP (HTTP (DASH)) и сервис PSS на основе интегрированной мультимедийной подсистемы (IMS) и сервиса мультимедийного широкого и многоадресного вещания (MBMS) (сокращенно - сервис IMS PSS MBMS). Например, сигнализация о характеристиках стандартизована в документах «Прозрачный сквозной потоковый сервис с пакетной коммутацией (PSS); Протоколы и кодеки» (3GPP TS 26.234, "Transparent end-to-end packet switched streaming service (PSS); Protocols and codecs"); «Прозрачный сквозной потоковый сервис с пакетной коммутацией (PSS); Прогрессивное скачивание и динамически адаптивная потоковая передача по протоколу HTTP (3GP-DASH)» (3GPP TS 26.247, "Transparent end-to-end packet switched streaming service (PSS); Progressive download and dynamic adaptive streaming over HTTP (3GP-DASH)"); и «Потоковый сервис с пакетной коммутацией (PSS) на основе мультимедийной подсистемы по интернет-протоколу (IMS) и сервис мультимедийного широкого и многоадресного вещания (MBMS) Протоколы» (3GPP TS 26.237, "IP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User Service; Protocols").

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

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

Фиг. 2 представляет диаграмму в соответствии со стандартом схемы описания ресурсов (RDF), показывающую профиль функциональных возможностей устройства для потоковых сервисов PSS и IMS PSS MBMS согласно одному из вариантов.

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

Фиг. 4 представляет блок-схему, показывающую подробно клиента и сервер для сервиса DASH, изображенных на Фиг. 3.

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

Фиг. 6 представляет диаграмму управления потоком сообщений, показывающую описание сервиса на основе протокола инициирования сеансов (S1P) с использованием абонентских и оповещающих сообщений в рамках потокового сервиса IMS PSS MBMS согласно одному из вариантов.

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

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

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

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

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

Фиг. 1 иллюстрирует пример системы 100 обмена сигналами о характеристиках для сервиса PSS. Мобильный терминал 110 (или терминал UE 110) сообщает 115 серверу 112 PSS свой идентификатор путем включения в HTTP-запрос указаний типа модели и изготовителя, адреса URL для обнаружения профиля функциональных возможностей или другой идентифицирующей информации. Сервер 112 затем запрашивает 125 соответствующий профиль возможностей устройства от сервера 130 профилей устройств, который сохраняет профили 135 возможностей устройств, каждый из которых перечисляет функциональные возможности конкретного типа мобильного терминала. Сервер 112 принимает 140 соответствующий профиль и согласует мультимедийное содержание, адаптируемое для устройства 110, в соответствии с информации, полученной из профиля возможностей устройства, указывающего поддерживаемые типы ориентации. Выбранное содержание мультимедиа затем передают 150 устройству 110 с использованием потокового протокола, такого как протокол HTTP или RTSP.

Во время установки потокового сеанса сервер 112 использует информацию из профиля возможностей устройства для предоставления мобильному терминалу 110 совместимого мультимедийного содержания. Поэтому сервер 112 именуется также удаленным сервером 112 медиасодержания, медиасервером 112, веб-сервером 112 или другим подобным образом. Другими словами, сервер 112 получает через сеть информацию, описывающую возможности мобильного терминала, и использует эту информацию для определения потока медиасодержания, который нужно передать мобильному терминалу. Например, сервер 112 может сравнить возможности воспроизведения и свойства мобильного терминала для идентификации множества доступных вариантов медиапотока, совместимых с этим терминалом. После этого терминал 110 может запросить идентифицированный поток. В некоторых вариантах серверы используют профиль возможностей устройства для выбора или создания файла протокола описания сеанса (session description protocol (SDP)) (в контексте сервиса PSS или сервиса IMS PSS MBMS) или файла метаданных презентации медиа (media presentation description (MPD)) (в контексте сервиса DASH), которые идентифицируют потоки, адаптированные к возможностям терминала 110.

Фиг. 1 также схематично иллюстрирует сетевую среду в соответствии с различными вариантами. Эта сетевая среда 160 содержит терминалы UE 110, связанные по радио с сетью 168 радио доступа (radio access network (RAN)). Сеть RAN 168 содержит усовершенствованную базовую станцию (eNB) 172, конфигурированную для связи с терминалом UE 110 через радио (ОТА) интерфейс. Сеть RAN 168 может быть частью сети согласно усовершенствованному стандарту долговременной эволюции (long-term evolution (LTE) advanced) разработки 3GPP и может быть обозначена как EUTRAN. В других вариантах могут быть использованы другие технологии сетей радио доступа.

Терминал UE 110 может осуществлять связь с удаленным медиасервером 112 через сеть RAN 168. Хотя узел eNB 172 показан как осуществляющий связь непосредственно с сетевыми объектами через сеть RAN 168, должно быть понятно, что трафик связи может проходить через ряд промежуточных сетевых компонентов, например переключателей, маршрутизаторов, шлюзов или других сетевых устройств в различных вариантах. Например, в некоторых вариантах сеть RAN 168 может быть связана с сетью базовых сервисов (CSN), которая соединяет сеть RAN 168 с сетью большего размера, например глобальной сетью связи, частью которой можно считать медиасервер 112, для осуществления связи с этой большой сетью.

Хотя Фиг. 1 описывает сетевую среду как сеть радиосвязи, другие варианты могут быть использованы в сетях другого типа, например в кабельных сетях связи. Должно быть понятно, что другие сетевые среды, в которых может быть использовано настоящее изобретение, могут содержать большее число компонентов, меньшее число компонентов или другие компоненты по сравнению с теми, какие показаны в примере, представленном на Фиг. 1. Например, в варианте настоящего изобретения, используемом в кабельной сети связи, медиасервер 112 и терминал UE 110 осуществляют связь один с другим без участия сети RAN 168.

На Фиг. 2 представлен пример метаданных 200, входящих в состав профиля возможностей устройства для сервисов PSS и IMS PSS MBMS. Профиль возможностей устройства представляет собой файл электронного документа, содержащий метаданные на расширяемом языке разметки (XML), форматированные в соответствии со схемой описания ресурсов (RDF), как это задано в документе «WWW-консорциум (W3C), Рекомендации: «Язык описания словаря RDF 1.0: схема RDF» (World Wide Web Consortium (W3C) Recommendation: "RDF Vocabulary Description Language 1.0: RDF Schema", http://www.w3.org/TR/2004/RECrdf-schema-20040210/), февраль 2004 г. Этот документ RDF о профиле возможностей устройства соответствует структуре Комплексных возможностей/Профилей предпочтений (Composite Capabilities/Preference Profiles (СС/РР)), являющейся словарным расширением схемы RDF, как это указано в Рекомендациях консорциума W3C: «Комплексные возможности/Профили предпочтений (СС/РР): Структура и словари 1.0» ("Composite Capability/Preference Profiles (СС/РР): Structure and Vocabularies 1.0", http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/), январь 2004 г.В некоторых вариантах профиль возможностей устройства представляет собой Профиль агента пользователя (User Agent Profile (UAProf)), который является приложением профиля СС/РР, описывающего возможности и предпочтения, специфичные для устройств радиосвязи. Другими словами, профили UAProf - заданные в документе Открытого сообщества производителей мобильной связи: «Профиль агента пользователя, версия 2.0» (Open Mobile Alliance: "User Agent Profile Version 2.0"), февраль 2006 г., - содержат словарь атрибутов, значения которых используются для спецификации возможностей и предпочтений терминала UE.

Фиг. 2 показывает пример множества имен атрибутов, допустимых значений и семантики. Как отмечено выше, такая информация может быть использована провайдерами содержания (например, сервером 112) для создания или предоставления содержания, подходящим образом сформатированного для клиентского устройства, в соответствии с некоторыми описанными здесь вариантами. Поле 210 метаданных «ТерминалАппаратура» ("[TerminalHardware]"), например, указывает, что терминал UE 110 может представлять на устройстве отображения цветной контент 220 из расчета 4 бит на пиксель 230 и поддерживать адаптивную потоковую передачу 240. Совокупность других интересующих атрибутов сигнализации о возможностях устройства (не показаны), как указано в упомянутом выше стандарте TS 26.234, может содержать (не ограничиваясь этим) следующие параметры: размер буфера перед декодером; первоначальный период буферизации; возможности декодера, свойства устройства отображения, такие как размер экрана, разрешение, разрядность цвета или другие свойства, поддержку адаптации потоковых способов, включая протоколы RTSP, HTTP, или другие; поддержку качества QoE; поддержку сообщений согласно расширенному протоколу управления транспортным протоколом реального времени (extended Real-time Transport Protocol (RTP) Control Protocol) (сокращенно RTCP); поддержку быстрого переключения содержания; равно как поддерживаемые профили протокола RTP и атрибуты протокола описания сеанса (Session Description Protocol (SDP)).

Сервер PSS или IMS PSS MBMS получает описание конкретных возможностей мобильного терминала, т.е. описание возможностей устройства. Для анализа возможностей ориентации для сервисов PSS и IMS PSS MBMS главным образом многократно используют словарь профилей UAProf и определяют дополнительный словарь, специфичный для сервиса, чтобы обеспечивать согласование содержания для потоковой передачи со стороны сервера. В некоторых вариантах словарь сервиса PSS содержит атрибуты обмена сигналами о возможностях устройства для «Ориентация» ("Orientation") и «Ориентация по умолчанию» ("DefaultOrientation"). Табл. 1 и 2 ниже показывают соответствующие примеры для атрибутов "Orientation" и "DefaultOrientation", входящих в показанное на Фиг. 2 поле 250 метаданных «[PssОбщий]» ("[PssCommon]") базового словаря сервиса PSS, заданного в документе TS 26.234.

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

В некоторых вариантах может быть возможно, чтобы группа типов ориентации могла содержать и другие типы, позволяющие поворачивать представляемые на устройстве отображения изображения на промежуточные углы (например, углы между разнесенными на 90 градусов основными типами ориентации) на основе изменений ориентации устройства. Например, атрибуты «Типы ориентации при считывании» (OrientationModesCapture) и «Типы ориентации при представлении на устройстве отображения» (OrientationModesDisplay), определенные выше, могут также иметь дополнительные возможные значения, определяющие «дробные» промежуточные углы ориентации. Таким образом, эти два дополнительных атрибута могут быть использованы для того, чтобы охарактеризовать возможности датчика ориентации устройства и способствовать осведомленности об ориентации устройства соразмерно угловой дробности, с которой датчик устройства может определять изменения ориентации в процессе считывания изображения или в процессе отображения/представления на устройстве отображения. Ниже приведены примеры таких атрибутов.

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

В некоторых вариантах атрибуты, приведенные в таблицах 7 и 8, объединяют, чтобы охарактеризовать осведомленность устройства об ориентации, как в режиме считывания (съемки) изображения, так и в режиме отображения/представления на устройстве отображения. Например, такие атрибуты могут быть определены следующим образом:

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

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

Возвращаясь к Фиг. 1, сервер 130 профилей устройств предоставляет профили возможностей устройств серверу PSS 112 в ответ на сообщение 125 HTTP-запроса. В некоторых вариантах мобильный терминал 110 может дополнить сигналы идентификации, передаваемые сервером 130, дополнительными атрибутами или поменять атрибуты, определенные в его профиле возможностей устройства по умолчанию. Такой дополнительный обмен информацией обозначен как обмен сигналами разности профилей (ProfDiff), что временно позволяет подстроить атрибуты в профиле возможностей устройства. В одном из примеров такая временная подстройка может быть запущена посредством предпочтений пользователя, например, если пользователь хотел бы во время конкретного сеанса получать монофонический звук, даже хотя терминал способен обрабатывать и воспроизводить стереозвук.

В некоторых вариантах изготовитель терминала или поставщик программного обеспечения поддерживает сервер профилей устройств 130 и обновляет профили 135 устройств с использованием профилей возможностей устройств для выпускаемых им терминалов UE. В других вариантах специальный оператор управляет сервером 130 профилей устройств для своих абонентов и позволяет этим абонентам для внесения специфичных для этого абонента обновлений в профили 135. Этот сервер 130 профилей устройств может также, в некоторых вариантах, базироваться на серверном оборудовании, используемом им совместно с сервером 112 содержания мультимедиа.

Способ адаптации мультимедиа на основе обмена сигналами о возможностях устройства и датчика ориентации в составе терминала содержит две составляющих. Во-первых, клиентское устройство передает серверу информацию, указывающую, имеет ли клиент датчик ориентации и какие типы ориентации поддерживаются, например, портрет, ландшафт, морской пейзаж или другие промежуточные состояния (Табл. 1). Кроме того, клиентское устройство может также временно преодолевать действие атрибута «Ориентация по умолчанию» (DefaultOrientation) (Табл. 2) посредством передачи сигнала о текущей ориентации устройства путем обмена разностями ProfDiff. Во-вторых, сервер рассматривает сигнал поддержки датчика ориентации от клиентского устройства и предоставляет различные кодированные версии содержания в форматах, наилучшим образом подходящих для различных возможных типов ориентации устройств (в более общем случае называются состояния ориентации, углы зрения или просто, ориентации). Более того, если сервер также управляет процессами считывания изображений для производства/подготовки содержания, он может дать команду модулю видеокамеры для считывания и сжатия нескольких копий одного и того же содержания, наилучшим образом подходящих для различных возможных ориентации устройства. Например, пользователь, наблюдающий за футбольным матчем, может изменить положение терминала UE 110 таким образом, чтобы указать, что камера должна совершить «наезд» и выделить конкретного футболиста на футбольном поле. Сервер может также динамически осуществлять транскодирование «на лету» для согласования содержания с текущей ориентацией устройства.

Описанный выше способ адаптации мультимедиа на основе ориентации устройства может быть использован для передачи и приема потоковых передач в соответствии с парадигмами активного запроса (pull) и активной рассылки (push). Примером активного запроса является сервис DASH. Примерами активной рассылки являются сервисы PSS и IMS PSS MBMS на основе соответствующих протокола RTSP и протокола инициирования сеанса (SIP).

Фиг. 3 представляет взаимодействие 300 высокого уровня клиент-сервер в контексте сервиса DASH. В этом контексте сервер 310 может принимать 320 обмен сигналами о возможностях устройства от клиентского устройства 330 с целью получения различных поддерживаемых устройством состояний ориентации. Сигнализация 320 о возможностях устройства может также содержать атрибут «Ориентация по умолчанию» (DefaultOrientation) (Табл. 2), который указывает ориентацию устройства в отсутствие какой-либо дополнительной сигнализации от клиента 330. Группу ориентации устройства и соответствующую информацию содержания сообщают 340 клиенту 330 в файле метаданных MPD. Плеер клиента затем контролирует текущее состояние ориентации устройства и запрашивает соответствующие версии содержания, указанные в файле MPD и адаптированные для текущей ориентации устройства. Более того, при вызове файла MPD по протоколу HTTP клиент 330 может вставить информацию об ориентации устройства в запрос GET, вместе с какими-либо временными подстройками ориентации устройства на основе сигнала ProfDiff (текущая ориентация устройства может отличаться от ориентации устройства по умолчанию). Таким образом, сервер HTTP 310 передает оптимизированный файл MPD 340 терминалу UE 330.

Фиг. 4 представляет сеть 400 с адаптивной потоковой передачей и поддержкой сервиса DASH, содержащую клиента 330, получающего услуги мультимедиа от вебсервера 320 (Фиг. 3), который в свою очередь получает мультимедийное содержание от веб или медиа сервера 414, на котором хранится это мультимедийное содержание. Этот веб/медиа сервер 414 получает мультимедийное содержание, которое может представлять собой входной поток в реальном времени или ранее записанное медиасодержание, через аудио/видео вход 416, здесь медиа передают в виде потока клиенту 410. Веб/медиа сервер 414 может содержать модуль 424 кодирования медиасодержания в подходящем формате и модуль 426 сегментирования, разбивающий входное медиасодержание на ряд фрагментов или отрывков, подходящих для организации потоковой передачи. Клиент 410 может иметь веб-браузер 418 для взаимодействия с веб-сервером 412 и медиа декодер/плеер 420 для декодирования и отображения потокового содержания мультимедиа.

В некоторых вариантах клиент 410 открывает одно или более соединений протокола TCP с одним или более стандартными серверами протокола HTTP или кэшами. Клиент 410 затем вызывает файл MPD (метаданные), предоставляющий информацию о структуре и различных версиях медиасодержания, хранящихся на веб/медиа сервере 414, включая, например, различные скорости передачи данных, частоты кадров, разрешения, типы кодеков и другую информацию, указанную в стандарте ISO/IEC 23009-1: 2012(E) для модели данных MPD для сервиса DASH. Файл данных MPD используется для передачи адреса HTTP URL каждого сегмента и ассоциированной информации метаданных для отображения этих сегментов на ось времени презентации медиа. Клиент 410 запрашивает новые данные в отрывках с использованием сообщений HTTP GET или частичных сообщений HTTP GET для получения сегментов данных меньшего размера (HTTP GET URL(FRAG1 REQ), FRAGMENT 1, HTTP GET URL(FRAGi REQ), FRAGMENTi) из состава выбранной версии медиа файла с индивидуальными сообщениями HTTP GET, имитарующими потоковую передачу через короткое скачивание, как показано на Фиг. 4. Адрес URL в составе сообщения HTTP GET указывает веб-серверу 412, какой Сегмент или Сегменты запрашивает клиент. В результате веб-браузер 418 вызывает и получает медиа контент от веб-сервера 412 Сегмент за Сегментом (или Под-сегмент за Под-сегментом на основе запросов диапазона байтов).

На Фиг. 5 показано взаимодействие 500 высокого уровня сервер-клиент в контексте потоковых передач с активной рассылкой (сервисы PSS и IMS PSS MBMS). В этом контексте сервер 510 принимает от клиента 520 информацию 530 обмена сигналами о возможностях и адаптирует содержание на основе ориентации устройства. В модели на основе активной рассылки сервер 510 выбирает одну из версий содержания из совокупности хранящихся версий содержания или динамически транскодирует содержание на основе текущей ориентации устройства и передает поток содержания клиенту 520. Метаданные, относящиеся к сеансу, передают 540 клиенту 520 согласно протоколу описания сеанса (SDP), который описывает информацию об ориентации устройства, ассоциированную с потоковым содержанием.

При использовании сервиса PSS клиент 520 обычно передает информацию об ориентации устройства в виде сообщения RTSP DESCRIBE серверу 510. Это сообщение может также содержать атрибут «Ориентация по умолчанию» (DefaultOrientation) (Табл. 2), указывающий ориентацию устройства в отсутствие какой-либо дополнительной сигнализации от клиента 520. Дополнительно, сигнализация ProfDiff используется для временной подстройки профиля возможностей устройства, когда текущая ориентация устройства отличается от ориентации устройства по умолчанию. Серверы содержания для сервиса PSS, поддерживающие обмен информацией о возможностях, могут также принимать информацию об ориентации устройства от клиента в составе каких-либо последующих запросах по протоколу HTTP или RTSP.

При использовании сервиса IMS PSS MBMS клиент 520 может передать информацию об ориентации устройства в составе сообщения SIP SUBSCRIBE в подсистему опорной сети (Core Network (CN)) мультимедиа по интернет-протоколу (IP Multimedia (IM)) в ходе поиска сервиса и затем направляет сообщение для функции поиска сервиса (Service Discovery Function (SDF)).

Например, Фиг. 6 показывает обмен 600 сообщениями об ориентации устройства между терминалом UE 610 (таким же или взаимозаменяемым с терминалом UE 110), подсистемой ГМ CN 620 и функцией SDF 630. Подсистема IM CN 620 и функция SDF 630 могут быть частью области опорной сети, сопряженного с областью сети доступа, например, сети RAN 168 (Фиг. 1).

Сообщение SIP SUBSCRIBE 640 может также содержать атрибут ориентации устройства по умолчанию, указывающий ориентацию устройства в отсутствие какой-либо дополнительной сигнализации от клиента 610. Функция SDF 630 определяет правильную информацию о поиске сервиса, например, согласно возможностям терминала UE 610, для профиля абонента (Поиск персонализированного сервиса (Personalized Service Discovery)). Функция SDF 630 передает терминалу UE 610 сообщение SEP NOTIFY 650, содержащее информацию о поиске сервиса, для подсистемы ГМ CN 620, которая ретранслирует сообщение SB? NOTIFY 650 назад терминалу UE 610. Каждая такая ретрансляция сообщения квитируется сообщением SIP OK. Такая схема обмена сообщениями позволяет оптимизировать поиск сервиса, использующего информацию об ориентации устройства, в совокупности сервисов PSS и MBMS. После этого, во время сеанса подсистемы IM (IMS), терминал UE 610 может также использовать сигнализацию по протоколу SIP для указания обновлений, включая любые временные подстройки ориентации устройства на основе разницы ProfDiff, т.е., если текущая ориентация устройства отличается от ориентации устройства по умолчанию.

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

Фиг. 7 показывает блок-схему системы 700 для работы с информацией, способной реализовать обмен сигналами о характеристиках ориентации устройства и адаптацию мультимедийного содержания на сервере в соответствии с ориентацией устройства согласно одному или более вариантам. Система 700 для работы с информацией, показанная на Фиг. 7, может материально реализовать один или более сетевых элементов из состава сети связи 100, как это показано на Фиг. 1, 3, 4 или 5 и описано в связи с этими чертежами. Например, система 700 для работы с информацией может представлять аппаратуру клиента 110, медиасервера 112 или сервера 130 возможностей устройств с большим или меньшим числом компонентов в зависимости от спецификации аппаратуры конкретного устройства или сетевого элемента. Например, в качестве терминала UE система 700 обычно должна иметь датчик ориентации. Хотя система 700 для работы с информацией представляет один из примеров множества типов компьютерных платформ, эта система 700 может содержать больше или меньше элементов и/или представлять другое соединение элементов, чем показано на Фиг. 7.

Система 700 для работы с информацией содержит один или несколько процессоров, таких как процессор 710 и/или процессор 712, которые могут иметь одно или более процессорных ядер. Эти один или более процессоров 710, 712 могут быть соединены с одним или несколькими запоминающими устройствами 716 и/или 718 через мост 714 памяти, который может быть расположен вне процессоров 710, 712 или по меньшей мере частично расположен в одном или более процессорах 710, 712. Запоминающее устройство 716 и/или запоминающее устройство 718 может представлять собой полупроводниковое запоминающее устройство, например энергозависимую память и/или энергонезависимую память. Мост 714 памяти может быть соединен с графической системой 720 для управления устройством отображения (не показано), соединенным с системой 700 для работы с информацией.

Система 700 для работы с информацией может дополнительно содержать мост 722 ввода/вывода для соединения с различными типами систем ввода/вывода. Система 724 ввода/вывода может быть, например, быть системой типа системы с универсальной последовательной шиной (USB), системой по стандарту IEEE 1394 или другой подобной системой для соединения одного или нескольких периферийных устройств с системой 700 для работы с информацией. Система 726 шин может содержать один или несколько типов шин, таких как шина для соединения периферийных компонентов (peripheral component interconnect (PCI)) или подобная шина для соединения одного или нескольких периферийных устройств с системой 700 для работы с информацией. Система 728 контроллера накопителей на жестких дисках (hard disk drive (HDD)) может соединять один или несколько накопителей на жестких дисках или подобные устройства с системой 700 для работы с информацией. Это могут быть, например, накопители типа Serial ATA или аналогичного типа или, в качестве альтернативы, полупроводниковый накопитель, содержащий флэш-память, память на основе фазовых переходов и/или память халькогенидного типа или другую подобную память. Коммутатор 730 может быть использован для соединения одного или нескольких коммутируемых устройств с мостом 722 ввода/вывода, например устройства (Gigabit Ethernet) или аналогичного типа. Более того, как показано на Фиг. 7, система 700 для работы с информацией может содержать радио приемопередатчик 732, имеющий высокочастотные схемы и устройства, соединенные с одной или несколькими антеннами 734, для радиосвязи с другими устройствами радиосвязи и/или через сети радиосвязи, такие как система связи 400, показанная на Фиг. 4. Если система для работы с информацией содержит несколько антенн 734, радио приемопередатчик 732 может реализовать схему связи с несколькими входами и несколькими выходами (multiple-input, multiple-output (MIMO)), хотя объем заявляемого предмета изобретения в этом отношении не ограничивается. Пример варианта системы для работы с информацией в контексте терминала UE показан на Фиг. 8 и рассмотрен ниже применительно к этому устройству.

Фиг. 8 представляет изометрический вид системы 700 для работы с информацией, показанной на Фиг. 7 и реализованной в виде сотового телефона, смартфона, планшетного устройства или другого аналогичного устройства. Система 700 содержит клиента НО, изображенного на Фиг. 1, реализует обмен сигналами о возможностях ориентации устройства и инициирует адаптацию мультимедийного содержания на сервере в соответствии с ориентацией устройства. Система 700 для работы с информацией может содержать корпус 810 с устройством 812 отображения, которое может иметь сенсорный экран 814 для приема тактильного ввода данных и команд, вводимых с использованием пальца 816 пользователя и/или стилуса 818, для управления одним или более процессорами 710 или 712. В корпусе 810 могут находиться один или более компонентов системы 700 для работы с информацией, например, один или более процессоров 710, 712 одно или более запоминающих устройств 716, 718 или приемопередатчик 732. Система 700 для работы с информацией может также в некоторых вариантах содержать область 820 физического воздействия, которая может содержать клавиатуру или кнопки для управления системой для работы с информацией посредством одной или более кнопок или переключателей. Система 700 для работы с информацией может также содержать порт или слот 822 для присоединения энергонезависимой памяти, такой как, например, флэш-память, в форме защищенной цифровой карты (SD) или модуля идентификации абонента (SIM). В некоторых вариантах система 700 для работы с информацией может дополнительно содержать один или несколько громкоговорителей 823 и микрофонов 824 и порт для соединения этой системы 700 для работы с информацией с другим электронным устройством, доком, устройством отображения, зарядным устройством для аккумуляторов и т.п. Кроме того, система 700 для работы с информацией может иметь гнездо 828 для