УПРАВЛЕНИЕ СЕАНСОМ СВЯЗИ ДЛЯ ПЕРЕДАЧИ МЕДИАПОТОКА Российский патент 2015 года по МПК H04L29/06 H04W28/10 

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

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

Предшествующий уровень техники

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

Доставка мультимедиа в основанных на IP (протоколе межсетевого взаимодействия) сетях может использовать различные транспортные протоколы. Традиционно, для потоковой передачи данных в реальном времени и основанной на пакетах потоковой передачи данных используется либо RTP (транспортный протокол реального времени) через UDP (протокол пользовательских дейтаграмм), либо HTTP (протокол передачи данных гипертекста) через TCP (протокол управления передачей) для загрузки целых файлов, главным образом для более позднего использования, но также и для живой потоковой передачи данных. RTP предусматривает динамическую адаптацию к доступной битовой скорости передачи данных, определяемой клиентом. Недостаток RTP и связанного протокола управления RTSP (протокола непрерывной передачи данных и контроля данных в реальном масштабе времени) заключается в необходимости в специализированном и более сложном программном обеспечении сервера, в то время как HTTP может использовать широко используемое и недорогое программное обеспечение сервера HTTP. Последнее усовершенствование, адаптивная потоковая передача данных HTTP (AHS), стремится объединить преимущества обоих подходов. AHS стандартизирована в 3GPP (Проекте партнерства 3-его поколения), и также принята и немного расширена на Открытом форуме IPTV (IP-телевидения) (OIPF). MPEG (Экспертная группа по вопросам движущегося изображения) также работает над AHS.

В AHS содержимое кодируется в различных версиях, обычно соответствующих различным битовым скоростям передачи данных. Если содержимое представляет собой, например, видеосигнал с дорожкой видеозаписи и дорожкой звукозаписи, дорожка видеозаписи может быть закодирована в трех версиях с отличающейся битовой скоростью передачи данных каждая, а дорожка звукозаписи - в высококачественной стереофонической и монофонической версии. Каждая версия дополнительно делится на сегменты продолжительностью в несколько секунд. Например, версии видеосигналов могут быть разделены на множество последовательных сегментов продолжительностью 10 с каждый. Сегменты могут быть отформатированы в соответствии с форматом файлов MPEG-4 или в соответствии с форматом транспортных потоков MPEG-2.

Фактическая передача дорожек видеозаписи и звукозаписи выполняется посредством загрузки одного сегмента за другим, инициируемой клиентом. В этой процедуре клиент загружает сегмент, используя стандартный запрос HTTP, распаковывает, декодирует и воспроизводит его, а затем выполняет то же самое для следующего сегмента и т.д. У клиента имеется знание о доступных версиях качества и о разделении сегмента в течение некоторого времени посредством описания мультимедиа, так называемого описания представлений мультимедиа (MPD). Формат MPD, как определено в 3GPP и OIPF, является закодированным XML (расширяемым языком разметки) файлом, содержащим соответствующую информацию и атрибуты для описания мультимедиа. MPD представляет собой первый ресурс, передаваемый клиенту, чтобы запустить основанную на AHS доставку мультимедиа. MPD, как определяется посредством 3GPP, содержит различные доступные качества и информацию относительно того, как они выполнены в сегментах.

Каждый сегмент загружается на максимально доступной скорости при существующих эксплуатационных условиях сети, используемой для передачи, и клиент осуществляет текущий контроль скорости загрузки, которую он испытывает. На основании испытываемой скорости загрузки клиент выбирает самую подходящую из доступных версий качества. От сегмента к сегменту это может быть отличающейся версией, и клиент может загружать различные качества в зависимости от существующих эксплуатационных условий, следовательно, это атрибут "адаптивной" потоковой передачи данных HTTP. Фиг.1 визуализирует принцип и показывает различные представления мультимедиа для адаптивной потоковой передачи данных HTTP элемента содержимого в виде функции времени воспроизведения. Три представления на фиг.1 могут соответствовать представлению высокой, средней и низкой битовой скорости передачи данных, соответственно, элемента содержимого, то есть потока. Начало и конец времени воспроизведения для потоковых сегментов различных представлений совпадают так, чтобы было возможно плавное переключение между представлениями. Вертикальная шкала на фиг.1 иллюстрирует размер данных различных представлений потоков, например, их битовую скорость передачи данных. В зависимости от клиентской реализации, возможны улучшенные процедуры выбора для переключения между представлениями, например, включая гистерезис, чтобы избегать чрезмерных колебаний качеств при просмотре или прослушивании потока.

Другая тенденция в мультимедийных коммуникациях заключается в использовании мультимедийной IP-подсистемы (IMS) для инициирования и управления мультимедийными сеансами связи. В 3GPP стандартизированные решения для управляемой IMS потоковой передачи данных RTP, так же как для управляемой IMS прогрессивной загрузки HTTP, определяются в 3GPP TS 26.237 V9.3.0 (2010-06) с заголовком: "Основанная на мультимедийной подсистеме IP (IMS) потоковая передача данных с коммутацией пакетов (PSS) и обслуживание пользователя услуги мультимедийной широковещательной/многоадресной передачи (MBMS); Протоколы". Эти решения извлекают выгоду из стандартизированных признаков, предлагаемых IMS, таких как тарификация, аутентификация или резервирование QoS (качества обслуживания).

Фиг.2 показывает различные этапы передачи сигналов в случае управляемой IMS прогрессивной загрузки HTTP, как определено в 3GPP TS 26.237. Сеанс связи инициируется сообщением INVITE SIP (протокола инициирования сеанса связи), которое включает в себя информацию SDP (протокола описания сеанса связи). URL (унифицированный указатель ресурсов) HTTP для загрузки поставляется на оборудование пользователя (UE), то есть клиенту, через сообщение SIP 200 OK (подтверждение работоспособности). Кроме того, может быть выполнено резервирование QoS для сеанса прогрессивной загрузки HTTP. Сама прогрессивная загрузка инициируется посредством UE командой GET HTTP, передаваемой на сервер HTTP, который в ответ реагирует запрашиваемым файлом содержимого (контент-файлом). Более подробно, выполняются следующие этапы:

1. UE инициирует сеанс прогрессивной загрузки, отправляя INVITE SIP, включающее в себя SDP-запрос, в подсистему CN IM.

2. Подсистема CN IM пересылает сообщение INVITE SIP в SCF (функцию управления сеансом связи).

3. SCF верифицирует права пользователя относительно запрашиваемого содержимого, выбирает адаптер.

4. Адаптер HTTP/SIP выбирает сервер HTTP и отправляет сообщение POST (самотестирование при включении питания) HTTP, включающее в себя IP-адрес UE, на сервер HTTP.

5. Сервер HTTP отвечает адаптеру HTTP/SIP ответным сигналом HTTP 200 OK.

6. Адаптер HTTP/SIP отправляет в SCF ответ SIP 200 OK, включающий в себя URL загрузки запрашиваемого файла содержимого в ответе SDP.

7. SCF пересылает SIP 200 OK в подсистему CN IM.

8. Подсистема CN IM пересылает SIP 200 OK на UE.

9. UE отправляет запрос HTTP в URL, полученный из сообщения SIP 200 OK.

10. Сервер HTTP поставляет файл содержимого в ответе HTTP для UE.

Современная концепция AHS, как определено, например, в 3GPP TS 26.234 "Прозрачное сквозное обслуживание потоковой передачи данных с коммутацией пакетов (PSS)", Открытый IPTV форум - Спецификация версии 2, "Адаптивная потоковая передача данных HTTP", DRAFT V0.06 - 7 июня 2010 г., или в собственных решениях, таких как "Microsoft Smoothstreaming or Apple streaming" (Плавная потоковая передача Microsoft или потоковая передача Apple) (см. R. Pantos, "HTTP Live Streaming" (живая потоковая передача данных), http://tools.ietf.org/html/draft-pantos-http-live-streaming-01), определяет только механизмы пакетирования мультимедиа, описания мультимедиа и загрузки. Никакое соединение для объединения этого механизма с механизмами резервирования ресурсов или QoS не предусматривается. Таким образом, даже в управляемых системах, в которых возможны резервирование QoS и управление, действия AHS выполняются с максимально доступным качеством, и поэтому, в общем, все еще требуют адаптации.

3GPP TS 26.234 V9.3.0, XP050441685 (2010-06) описывает, что адаптивный протокол HTTP-потоковой передачи данных 3GPP предоставляет услугу потоковой передачи данных между стандартным сервером HTTP и клиентом потоковой передачи данных HTTP, чтобы доставлять содержимое от стандартного сервера HTTP клиенту HTTP-потоковой передачи данных. Чтобы инициировать услугу потоковой передачи данных для пользователя, клиент потоковой передачи данных HTTP загружает соответствующие метаданные и впоследствии данные мультимедиа.

Проект TS 26.cde-HSD-V0.03 3GPP, XP050460440 (2010-06) описывает, что услуга потоковой передачи данных HTTP и загрузки (HSD) обеспечивает услугу непрерывной поставки содержимого мультимедиа (медиаконтента) по HTTP от сервера HSD клиенту HSD с использованием протокола HTTP/1.1.

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

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

Представлены способы, медиаклиент, медиасервер, объект управления и медиапрокси в соответствии с независимыми пунктами формулы изобретения.

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

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

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

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

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

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

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

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

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

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

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

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

Фиг.1 иллюстрирует представления мультимедиа для медиапотока;

фиг.2 показывает схему передачи сигналов управляемой IMS загрузки HTTP;

фиг.3 показывает блок-схему последовательности операций предлагаемого способа;

фиг.4 показывает медиаклиента, выполненного с возможностью выполнения предлагаемого способа;

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

фиг.5a показывает способ, выполняемый на медиасервере;

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

фиг.6a показывает способ, выполняемый в объекте управления;

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

фиг.7a показывает способ, выполняемый в медиапрокси;

фиг.8 показывает схему передачи сигналов для варианта осуществления предлагаемого способа.

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

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

В способе описание мультимедиа для медиапотока получают 32, например, из файла, загруженного клиентом. Описание мультимедиа указывает начальный элемент из элементов потока, например, такой как медиаисточник, подобный URI (универсальному индикатору ресурсов), от которого можно получить начальный элемент. В общем, медиаисточники также могут быть указаны с помощью шаблона для генерирования клиентом индикаторов URI для элементов, чтобы избегать необходимости индивидуально передавать источник для каждого элемента потока, например, обеспечивая правило для генерирования источника n-го элемента потока в виде функции n. В терминологии представленного текста, медиаисточник указывает определенный начальный адрес элемента потока, в отличие от размещения информации платформы (например, сохранения или генерирования) и обеспечения элемента потока, например, сервера или сети. Соответственно, запрос может адресоваться, например с помощью IP-адреса и номера порта, для платформы и включать в себя медиаисточник, например, в форме сообщения GET (получения) HTTP, включенного в запрос.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Медиаклиент 48, выполненный с возможностью выполнения аспектов вышеупомянутых способов, показан на фиг.4. Он содержит контроллер 50, соединенный с передатчиком 52 и приемником 54. Передатчик 52 и приемник 54 могут быть выполнены с возможностью отправки и приема радиопередач в системе стационарной или беспроводной связи, например, в виде частей приемопередатчика. Передачи могут отправляться, например, в виде IP-пакетов, содержащих запросы и ответы HTTP. Контроллер 50 может быть реализован, например, в системе 56 обработки данных с запоминающим устройством 58, которая выполняет подпрограммы управления, реализованные, например, посредством программ системы программного обеспечения.

Контроллер 50 выполнен с возможностью управления передачей медиапотока, содержащего множество последовательных элементов 60 потока, и получения описания 62 мультимедиа для медиапотока. Управление передачей может быть выполнено с помощью управляющих сообщений, инициируемых приемником, в частности, запросами 66 элементов потока от медиаисточников. Описание мультимедиа указывает начальный элемент 64 из элементов потока, например, такой как медиаисточник. Контроллер 50 дополнительно выполнен с возможностью инициирования отправки запроса 66 начального элемента потока передатчиком 52, например, на платформу, вмещающую медиаисточник, и инициирования процедуры управления сеансом связи для передачи медиапотока.

Изображенный медиаклиент также содержит аппаратное оборудование, такое как экран 70 или акустическая система 72, чтобы воспроизводить принимаемый поток для пользователя. С этой целью клиент содержит логическую схему 74 для воспроизведения, которая также может быть реализована в системе 56 обработки данных. Логическая схема 74 для воспроизведения принимает элементы 60 потока от приемника 54, и распаковывает и декодирует их для воспроизведения посредством экрана 70 или акустической системы 72. Контроллер 50 также может быть выполнен с возможностью запрашивания одного или больше дополнительных элементов 60 потока, когда они необходимы для воспроизведения, чтобы выбирать представление медиапотока, основываясь на информации в описании 62 мультимедиа и контролируемой битовой скорости передачи данных принимаемых элементов потока, и инициировать запросы 66 с помощью передатчика 52 для соответствующего представления. Текущий контроль битовой скорости передачи данных может выполняться, например, посредством обнаружения размеров элементов потока и измерения времени для их передачи. В случае AHS, определенные запросы 66 соответствуют определенным элементам 60 потока, как указано метками элементов на чертеже.

Медиасервер 80, выполненный с возможностью выполнения аспектов вышеупомянутых способов, показан на фиг.5. Он содержит контроллер 82 для управления передачей медиапотока, содержащего множество последовательных элементов 84 потока, в ответ на запросы 86 элементов потока от клиента, например, клиента, как описано относительно фиг.4. Медиасервер 80 содержит передатчик 88 для отправки элементов 84 потока клиенту и приемник 90. Передатчик и приемник могут быть выполнены с возможностью радиопередачи или передачи данных по проводам. Приемник 90 выполнен с возможностью приема запроса 86 начального элемента 92 из элементов потока, при этом запрос 86 указывает начальный элемент 92, например, такой как медиаисточник, подобный URI. Приемник 90 также выполнен с возможностью приема результата процедуры управления сеансом связи для передачи медиапотока, например, от объекта управления сети, передающего медиапоток, и пересылки его в контроллер 82.

Помимо этого, приемник 90 выполнен с возможностью приема дополнительного запроса последующего элемента 94 из элементов потока. Дополнительный запрос может содержать дополнительный медиаисточник последующего элемента. В случае AHS, определенные запросы 86 соответствуют определенным элементам 84 потока, как указано метками элементов на чертеже.

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

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

В варианте осуществления медиасервера 80 передатчик 88 выполнен с возможностью отправки клиенту описания 100 мультимедиа для медиапотока. Передача описания 100 мультимедиа также может инициироваться запросом от клиента, который на чертеже не показан. Описание 100 мультимедиа указывает медиаисточник для начального элемента 92 из элементов потока, а также, факультативно, дополнительный медиаисточник последующего элемента 94 потока.

В этом варианте осуществления процессор 102 может быть выполнен с возможностью получения начального описания мультимедиа, например, от запоминающего устройства 98, содержащего множество описаний представлений, при этом каждое описание представления указывает отличающееся представление медиапотока и, факультативно, указания относительно связанных медиаисточников. Процессор 102 дополнительно может быть выполнен с возможностью удаления, по меньшей мере, одного из описаний представлений из начального описания мультимедиа, чтобы определить описание 100 мультимедиа для передачи. Процессор также может модифицировать описание представления, например, к значениям, которые избегают выбора клиентом. Если указание источника существует, оно также может быть удалено или модифицировано, например, чтобы заменить источник высокого качества на источник низкого качества. Факультативно, процессор может просто удалить медиаисточник, сохраняя описание представления, чтобы информировать приемник о существовании представления без получения связанного источника. Точно так же, вместо того, чтобы просто удалить описание представления со связанным источником, вместо удаленных представлений может быть включен тег, который указывает клиенту, что доступно, по меньшей мере, одно дополнительное представление. Таким образом, сервер может генерировать модифицированное описание мультимедиа, которое может использоваться до процедуры управления сеансом связи. Процессор 102 может быть частью системы 104 обработки данных.

Фиг.5a изображает соответствующий способ на медиасервере, управляющем передачей медиапотока, содержащего множество последовательных элементов потока, в ответ на запросы элементов потока от клиента. Способ начинается с этапов приема 110 запроса начального элемента из элементов потока. Запрос указывает начальный элемент, например, такой как медиаисточник, идентифицирующий элемент потока. В ответ на запрос клиенту отправляется 112 начальный элемент. В любой момент времени в течение выполнения способа результат процедуры управления сеансом связи для передачи медиапотока принимается 114 медиасервером. Когда медиасервер принимает 116 дополнительный запрос последующего элемента из элементов потока, он может управлять 118 отправкой последующего элемента на основании результата процедуры управления сеансом связи.

Фиг.6 показывает объект 200 управления для управления сеансом связи с медиаклиентом для передачи медиапотока, содержащего множество последовательных элементов потока, от медиасервера, например, сервера, как упомянуто выше. Объект управления может быть реализован, например, как адаптер HTTP/SIP. Объект 200 управления содержит приемник 202 для приема управляющих сообщений 204 процедуры управления сеансом связи для передачи медиапотока, например, сообщений SIP. Сообщения, например, инициируются медиаклиентом, как упомянуто выше, и пересылаются дополнительными сетевыми элементами, которые также могут получать связанную с сеансом связи информацию из процедуры управления сеансом связи, и таким образом способны выполнять или инициировать операции управления, связанные с сеансом связи.

Контроллер 206 завершает передачу сигналов, то есть он представляет собой оконечное устройство для передачи сигналов. Соответственно, он обрабатывает сигнальные сообщения 204 и может инициировать отправку ответов 208 передатчиком 210. С этой целью контроллер 206 соединен с приемником 202 и передатчиком 210. Кроме того, контроллер 206 выполнен с возможностью ассоциирования медиапотока с сеансом связи в процедуре управления сеансом связи. Например, контроллер 206 может выбрать существующий сеанс связи для передачи медиапотока и, возможно, модифицировать параметры сеанса связи для этой цели, или контроллер может установить новый сеанс связи для этого медиапотока. Запоминающее устройство 212 позволяет сохранять и выводить информацию для сеанса связи. Контроллер может быть реализован в системе 214 обработки данных объекта 200 управления.

На основании результата процедуры управления сеансом связи контроллер 206 инициирует отправку команды 216 передатчиком 218. Команда 216 инициирует управление передачей последующего элемента из элементов потока в соответствии с правилом управления сеансом связи и может быть отправлена на медиасервер, передающий медиапоток, или в точку принудительного установления политики сеанса связи. Приемник 220, соответствующий передатчику 218, позволяет принимать, например, подтверждение 222 приема для команды 216. Объект управления также может получать через приемник 220 информацию, которая может быть отправлена клиенту или использоваться в определении параметров сеанса связи, например, описания мультимедиа или медиаисточников. Передатчик 218 и приемник 220 могут быть идентичными передатчику 210 и приемнику 202 или могут быть отличающимися объектами, и они также могут использовать отличающийся протокол, например HTTP, возможно, в зависимости от получателей. Передатчик 218 и приемник 220 также могут соответствовать внутреннему интерфейсу устройства, если команда отправляется объекту, реализованному на той же платформе.

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

Медиапрокси 250 для пересылки описаний мультимедиа от сервера клиенту изображен на фиг.7. В общем, медиапрокси также пересылает множество других сообщений, запросов и ответов между клиентом и сервером, например, элементы потока и запросы элементов потока. Медиапрокси 250 содержит приемник 252 для приема от сервера описания 254 мультимедиа, содержащего множество описаний представлений. Каждое описание представления указывает отличающееся представление медиапотока. В примере, описание 254 мультимедиа содержит три описания представлений R1-R3 медиапотока со связанным источником S1-S3 для каждого представления. Также возможно, что описание мультимедиа содержит описания представлений без медиаисточника, как указано для описания R4 представления. В этом случае клиента информируют о существовании представления, но прежде, чем получить источник, необходимо выполнить дополнительные этапы, например, ассоциирование медиапотока с сеансом связи.

Процессор 256, который может быть частью системы 258 обработки данных, выполнен с возможностью модифицирования описания мультимедиа посредством удаления или модифицирования, по меньшей мере, одного из описаний представлений и/или связанного источника из описания 254 мультимедиа. В примере, описание представления R2 удаляется вместе со связанным источником S2, например, если радиосеть, к которой подключен клиент, не поддерживает необходимую скорость передачи данных. Для представления R3 удаляется только источник S3, например, если для медиапотока требуется предшествующая установка сеанса связи, чтобы гарантировать необходимое качество обслуживания, или если для представления должна выполняться тарификация. Представление R1 с источником S1 остается в описании мультимедиа, чтобы начальный источник был доступен для клиента, например, для обеспечения возможности инициировать воспроизведение с использованием однонаправленного канала максимально доступного качества. Запоминающее устройство 260 позволяет сохранять и выводить данные, требуемые для модифицирования описания мультимедиа.

Передатчик 262 отправляет клиенту модифицированное описание 264 мультимедиа. В общем, также существуют соответствующий приемник 266 для передатчика 262 и передатчик 268 для приемника 252, чтобы обеспечить возможность для выполнения соответствующих передач в обратном направлении. Возможно, что функции обоих передатчиков выполняются одним и тем же физическим устройством; то же самое применяется к обоим приемникам.

Обработка для модифицирования описания мультимедиа, как описано для процессора 256, также может быть выполнена в других объектах, например, на медиасервере.

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

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

Предлагаемый способ может использоваться, например, в основанном на IMS резервировании QoS для адаптивной потоковой передачи данных HTTP. В этом случае он определяет концепцию для интеграции адаптивной потоковой передачи данных HTTP с основанной на SIP передачей сигналов управления с управляемой IMS инфраструктурой, и позволяет и обеспечивает возможность для определяемых IMS признаков, таких как QoS, тарификация, аутентификация и т.д., для адаптивной потоковой передачи данных HTTP. Предлагаемая интеграция обеспечивает возможность обратной совместимости AHS с устройствами без функции IMS, быстрого запуска обслуживания и дифференцирования категории обслуживания. Эта интеграция основана на идее включения управляющей информации IMS, например, URI (универсального идентификатора ресурса) SIP, в MPD.

В дальнейшем более подробное техническое описание вариантов осуществления, применяющих некоторые из вышеупомянутых общих концепций, сделано в отношении управляемой IMS AHS. Предположим, что клиент получил URL файла описания представлений мультимедиа (MPD) каким-либо образом, например, в виде ссылки на странице HTML или в сообщении. Фиг.8 изображает последовательное взаимодействие задействованных объектов, например, узлов.

Объекты, которые участвуют в потоке сообщений, являются оборудованием пользователя (UE), например, мобильным телефоном в качестве примера медиаклиента, и подсистемой базовой сети мультимедийных IP-услуг (подсистемой CN IM), которой может быть, например, базовая сеть системы мобильной телефонной связи с сетью с радиодоступом, чтобы обеспечить возможность мобильности для UE. Функция управления сеансом связи (SCF) обеспечивает логику услуги и функции, требуемые для поддержки выполнения такой логики, которая может включать в себя, например, авторизацию услуги во время инициирования сеанса связи и модификации сеанса связи, проверяя подписку на услугу пользователя, чтобы предоставить или отклонить доступ к услуге или выборам функций мультимедиа. Правила таких функций и их активация подвергаются воздействию реализации оператора. Адаптер HTTP/SIP в качестве примера объекта управления завершает передачу сигналов SIP и устанавливает связь с сервером HTTP, который выполняет, в качестве примера медиасервера, потоковую передачу данных мультимедиа.

Во многих вариантах осуществления описанных процедур подсистема CN IM и SCF могут быть стандартными компонентами IMS и тогда подвергаются воздействию только правил реализации и элементов для управления передачей мультимедиа. В потоковой передаче мультимедиа может использоваться больше чем единственный сервер HTTP, например, когда MPD и различные качества мультимедиа распределяются через различные серверы. Кроме того, вместо серверов HTTP может использоваться сеть доставки содержимого (CDN). Адаптер HTTP/SIP и сервер HTTP могут быть реализованы как компоненты на том же аппаратном оборудовании или даже в пределах единственного программного обеспечения. В этом случае интерфейс между этими двумя компонентами может отличаться от примера, показанного на фиг.8, то есть может быть основан не на HTTP. Вместо этого интерфейс может быть основан, например, на API-вызовах (вызовах интерфейса прикладного программирования).

В потоке сигналов на фиг.8 UE выполняет запрос 10a HTTP к URL MPD, то есть к серверу HTTP, который обеспечивает MPD. Сервер HTTP отвечает с MPD, которое содержит описания представлений для всех уровней качества или, в качестве варианта осуществления, только для уровней качества, которые рассматриваются как подходящие для передачи максимально доступного качества в сети. Возвращенное MPD в ответе 10b HTTP сопровождается URI SIP, который обеспечивает возможность терминалам с функцией SIP запрашивать установку сеанса связи для сеанса связи AHS. URI SIP может быть включен, например, как стандартизированный новый атрибут MPD, он может быть объединен в пакет в существующем элементе MPD, или он может быть частью ответа 10b на запрос HTTP, например, как часть составного ответа, содержащего множество HTTP или других элементов.

Для этих этапов существуют несколько вариантов выбора:

• Запрос 10a может быть проксирован шлюзом уровня приложений (ALG), который может быть расположен в сети, например, в подсистеме CN IM. ALG представляет собой пример медиапрокси и может производить обзор запросов относительно файлов MPD, удалять представления и добавлять URI SIP, чтобы запрашивать QoS для сеанса связи.

• Вместо включения URI SIP в MPD он может быть включен как отдельный элемент и транспортирован в составном сообщении ответа 10b.

• Ответ 10b, включающий в себя MPD, также может включать в себя дополнительную информацию, которую UE может использовать для того, чтобы генерировать файл SDP для последующего сообщения 1 INVITE SIP. Это может быть, например, дополнительной информацией о мультимедиа, которая может использоваться для создания части мультимедиа SDP или шаблона SDP, который UE может использовать после завершения переменных частей шаблона. Таким образом, UE может либо использовать хранящуюся информацию и подпрограммы, чтобы создавать часть мультимедиа SDP, либо принимать шаблон для запроса, содержащий определенные информационные элементы, которые должны быть заполнены в подобных портах или форматах мультимедиа.

• Вместо включения URI SIP в MPD может быть включен другой тип URI (например, URL HTTP), который может быть преобразован в URI SIP, например, посредством переадресации.

На этапе 10c оборудования UE и с функцией IMS, и без функции IMS инициируют сеанс связи AHS. Это обеспечивает возможность получения быстрого времени запуска потоковой передачи данных и может быть сделано с использованием соединения максимально доступного качества, например, на устанавливаемом по умолчанию однонаправленном канале к подсистеме CN IM. Таким образом, также возможна обратная совместимость, при которой UE без функции IMS может проигнорировать обеспеченный URI SIP.

Устройства, которые являются устройствами с функцией IMS, могут параллельно с запуском сеанса связи AHS пересылать сообщения 11-13 INVITE SIP на адаптер SIP/HTTP. INVITE относится к ранее сообщенному URI SIP. Сообщение INVITE включает в себя либо файл не SDP, файл SDP, сгенерированный клиентом, либо заполненный шаблон SDP, который клиент мог принять с ответом MPD в ответе 10b.

Если адаптер SIP/HTTP и сервер HTTP представляют собой два отдельных объекта, адаптер SIP/HTTP посылает запрос 14 HTTP, например, запрос POST или GET, на сервер HTTP, чтобы получить URL для исходного MPD и/или непосредственно исходное MPD, которое возвращается в ответе 15. Термин "исходный" указывает, что это MPD может содержать неотфильтрованный список описаний представлений мультимедиа, доступных на сервере, в то время как у MPD, включенного в ответ 10b, могут быть удалены некоторые из представлений. Благодаря информации в исходном MPD, адаптер SIP/HTTP в состоянии послать сообщение 16 SIP 200 OK, включающее в себя SDP, который содержит информацию об уже происходящем в настоящее время сеансе связи AHS этапа 10c. Сообщение SIP 200 OK на этапах 17 и 18 пересылается на UE. Например, в случае, если UE, то есть клиент, должен получить доступ к разным качествам мультимедиа, сообщение SIP 200 OK может содержать обновленный URI MPD, который может содержать одно или больше дополнительных представлений мультимедиа по сравнению с MPD, включенным в ответ 10b. Обновленное MPD может быть либо исходным MPD, либо версией, отредактированной, например, адаптером SIP/HTTP или прокси.

Во время передачи данных CN IM инициирует принудительное установление определенной политики, например QoS, для медиасеанса, факультативно включающее в себя обновление однонаправленного канала. Резервирование QoS и принудительное установление политики могут использовать механизмы стандарта 3GPP, определенные в 3GPP TS 23.203 под названием "Policy and charging control architecture" (Политика и структура управления взиманием оплаты). Например, используя информацию из MPD и IP-адрес клиента, порты и т.д., могут быть созданы соответствующие правила политики и управления взиманием оплаты (PCC). Правила PCC позволяют точкам принудительного установления политики, таким как шлюзы, идентифицировать и располагать по приоритетам пакеты, принадлежащие сеансу связи потоковой передачи данных HTTP. Пакеты, превышающие соглашения о ширине полосы пропускания, могут быть отмечены, чтобы указывать на перегрузку, или могут быть отброшены. Правила PCC, которые рассматривают элементы, отличающиеся от IP-адресов или портов, например, связанные с услугой, которая может быть идентифицирована углубленной проверкой пакетов в точках принудительного установления политики, также обеспечивают возможность использования описанного механизма в случае, если сервер HTTP заменяется кэш-памятью или CDN, в которой содержимое может быть передано потоком из множества местоположений.

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

После того как UE приняло сообщение 18 200 OK и узнало об установленном QoS, факультативно, оно может проверить сервер HTTP на обновление MPD с помощью запроса HTTP 19a и ответа 19b. Сервер HTTP может обеспечить обновление на основании информации, принятой в сообщении 14, или другого подтверждения ассоциации медиапотока с сеансом связи. В случае если этот ответ 10b не включает в себя высококачественные представления мультимедиа, UE принимает обновленное MPD со всеми представлениями в соответствии с доступным QoS.

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

Для устройств без функции IMS этап 20 выполняется сразу после этапа 10c без обновления качества мультимедиа.

Дополнительно возможны факультативные функциональные средства и варианты осуществления процедур:

• В ответе 10b указание относительно более доступных уровней качества может быть дано, например, через определенный тег или через присутствие большего количества представлений, включающих в себя атрибут ширины полосы пропускания, но без включения элементов <InitialisationSegmentURL> или <sourceURL>, то есть медиаисточников, таких как ссылки на мультимедиа.

• Предложение SDP для сеанса связи может быть сгенерировано UE или адаптером SIP/HTTP. Запрошенная информация обеспечивается через коммуникационный тракт и MPD, например, IP-адрес передатчика и приемника, транспортный формат мультимедиа и порты, и необходимую ширину полосы пропускания.

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

• Индикаторы URI, которые обеспечиваются в MPD, могут быть сгенерированы особым образом, например, персонализированными для пользователя, чтобы затруднить подбор индикаторов URI для уровней более высокого качества таким образом, чтобы к ним нельзя было легко получить доступ без информации в MPD.

• В некоторых случаях простой фильтр в точке принудительного установления политики, основанной на IP-наборах из 5 элементов, то есть фильтр, разрешающий или ограничивающий пакеты на основании, по меньшей мере, одного элемента от группы, содержащей исходный адрес, исходный порт, адрес получателя, порт назначения и идентификацию протокола, не является подходящим для принудительного установления QoS, например, для потоковой передачи содержимого от CDN. В таких случаях правила PCC могут содержать другую информацию. Например, может быть включена определенная для HTTP информация, такая как заголовки, которая может использоваться во время углубленной проверки пакетов в точках принудительного установления QoS, чтобы идентифицировать пакеты из сеанса связи потоковой передачи данных HTTP.

• Сервер HTTP может предоставлять доступ только к определенному качеству мультимедиа, то есть к сегментам потока конкретного представления, после приема указания относительно успешной процедуры INVITE SIP. Для проверки этого может быть дополнительное взаимодействие между сервером HTTP, адаптером SIP/HTTP и/или CN IM. Например, адаптер SIP/HTTP или сервер HTTP могут зарегистрировать IP-адрес оборудования UE во время INVITE SIP и проверять после запроса HTTP GET, как на этапе 10а, 19a, если IP-адрес источника запроса GET принадлежит зарегистрированному UE.

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

• Быстрый запуск потоковой передачи данных, даже в случае задержек установления QoS IMS.

• Обратную совместимость для существующих и стандартизированных механизмов AHS.

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

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

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

Изобретение относится к средствам управления передачей медиапотока. Техническим результатом является исключение колебания качественного уровня при воспроизведении медиапотока. В способе получают (32) описание (100) мультимедиа для медиапотока, где описание (100) мультимедиа указывает начальный элемент (92) из элементов (84) потока, отправляют (34) запрос начального элемента (92) потока, инициируют (36) процедуру управления сеансом связи, ассоциируют (38) после этапа (34) отправки запроса начального элемента (92) потока медиапоток с сеансом связи в процедуре управления сеансом связи и управляют (40) передачей последующего элемента (94) из элементов потока в соответствии с правилом управления сеансом связи. 9 н. и 19 з.п. ф-лы; 11 ил.

1. Способ управления передачей медиапотока, содержащего множество последовательных элементов (84) потока, причем способ содержит этапы, на которых:
получают (32) описание (100) мультимедиа для медиапотока, при этом описание (100) мультимедиа указывает начальный элемент (92) из элементов (84) потока,
отправляют (34) запрос начального элемента (92) потока,
инициируют (36) процедуру управления сеансом связи для сеанса связи,
ассоциируют (38) после этапа (34) отправки запроса начального элемента (92) потока медиапоток с сеансом связи в процедуре управления сеансом связи и
управляют (40) передачей последующего элемента (94) из элементов потока в соответствии с правилом управления сеансом связи.

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

3. Способ по п. 2, в котором указатель ресурсов включается в описание (100) мультимедиа или ассоциируется с описанием (100) мультимедиа.

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

5. Способ по п. 4, в котором процедура управления сеансом связи содержит этапы, на которых:
принимают ответ на управление сеансом связи для процедуры управления сеансом связи клиентом (48) и
отправляют при приеме ответа на управление сеансом связи запрос начального или последующего элемента (94) из элементов потока.

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

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

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

9. Способ по п. 6, в котором параметр, определяющий сеанс связи, включается в запрос последующего элемента (94).

10. Способ по п. 4, в котором описание мультимедиа содержит множество описаний представлений, при этом каждое описание представления указывает отличающееся представление медиапотока и связанный медиаисточник, и в котором, по меньшей мере, один из связанных медиаисточников выбирается на основании описания мультимедиа и включается в запрос начального элемента (92) или в запрос последующего элемента (94).

11. Способ по п. 2, в котором, по меньшей мере, один из медиаисточника и источника для управления сеансом связи является определенным для сеанса связи.

12. Способ по п. 8, в котором, по меньшей мере, один из медиаисточника и источника для управления сеансом связи является определенным для сеанса связи.

13. Способ по п. 10, в котором запрос начального элемента (92) отправляется до или одновременно с инициированием процедуры управления сеансом связи.

14. Способ в медиаклиенте для управления передачей медиапотока, содержащего множество последовательных элементов (84) потока, причем способ содержит этапы, на которых:
получают (32) описание (100) мультимедиа для медиапотока, при этом описание мультимедиа указывает начальный элемент (92) из элементов потока,
отправляют (34) запрос начального элемента (92) потока,
инициируют (36) процедуру управления сеансом связи для передачи медиапотока,
при этом этап (34) отправки запроса начального элемента (92) потока выполняется прежде, чем медиапоток ассоциируется с сеансом связи в процедуре управления сеансом связи.

15. Способ по п. 14, в котором медиаклиент выполнен с возможностью выполнения способа по любому из пп. 1-13.

16. Медиаклиент (48), содержащий контроллер (50), соединенный с передатчиком (52) и приемником (54), причем
контроллер (50) выполнен с возможностью управления передачей медиапотока на приемник (54), при этом медиапоток содержит множество последовательных элементов (60) потока,
контроллер (50) дополнительно выполнен с возможностью получения описания (62) мультимедиа для медиапотока, при этом описание (62) мультимедиа указывает начальный элемент (64) из элементов (60) потока, и
контроллер (50) выполнен с возможностью инициирования отправки запроса (66) начального элемента (64) потока передатчиком (52) и инициирования процедуры управления сеансом связи для передачи медиапотока,
при этом передатчик (52) выполнен с возможностью отправки запроса начального элемента (92) потока прежде, чем медиапоток ассоциируется с сеансом связи в процедуре управления сеансом связи.

17. Медиаклиент по п. 16, причем медиаклиент выполнен с возможностью выполнения способа по любому из пп. 1-13.

18. Медиасервер (80) с контроллером (82) для управления передачей медиапотока, содержащего множество последовательных элементов (84) потока, в ответ на запросы (86) элементов потока от клиента, причем медиасервер содержит
передатчик (88), выполненный с возможностью отправки элементов (84) потока,
приемник (90) для приема запроса (86) начального элемента (92) из элементов (84) потока, при этом запрос указывает начальный элемент (92), для приема результата процедуры управления сеансом связи для передачи медиапотока и для приема дополнительного запроса последующего элемента (94) из элементов (84) потока, в котором приемник (90) дополнительно выполнен с возможностью приема запроса (86) начального элемента (92) потока прежде, чем медиапоток ассоциируется с сеансом связи в процедуре управления сеансом связи,
при этом контроллер (82) соединен с передатчиком (88) и с приемником (90) и выполнен с возможностью управления отправкой последующего элемента (94) на основании результата процедуры управления сеансом связи.

19. Медиасервер по п. 18, в котором передатчик (88) выполнен с возможностью отправки клиенту (48) описания (100) мультимедиа для медиапотока, при этом описание (100) мультимедиа указывает медиаисточник для начального элемента (92) из элементов потока.

20. Медиасервер по п. 19, в котором процессор (102) выполнен с возможностью получения начального описания (254) мультимедиа, содержащего множество описаний представлений, при этом каждое описание представления указывает отличающееся представление медиапотока, и в котором процессор (102) дополнительно выполнен с возможностью удаления или модифицирования, по меньшей мере, одного из описаний представлений и медиаисточника, по меньшей мере, одного описания представления, чтобы генерировать модифицированное описание (264) мультимедиа.

21. Медиасервер по любому из пп. 18-20, причем медиасервер выполнен с возможностью выполнения способа по любому из пп. 1-13.

22. Способ управления передачей медиапотока на медиасервере, содержащего множество последовательных элементов (84) потока, в ответ на запросы (86) элементов потока от клиента, причем способ содержит этапы, на которых:
принимают (110) запрос начального элемента (92) из элементов потока, при этом запрос указывает начальный элемент (92),
отправляют (112) указанный начальный элемент (92) потока,
принимают (114) результат процедуры управления сеансом связи для передачи медиапотока, при этом этап приема (110) запроса начального элемента (92) потока выполняется прежде, чем медиапоток ассоциируется с сеансом связи в процедуре управления сеансом связи,
принимают (116) дополнительный запрос последующего элемента (94) из элементов потока и
управляют (118) отправкой последующего элемента (94) на основании результата процедуры управления сеансом связи.

23. Объект (200) управления для процедуры управления сеансом связи с медиаклиентом для передачи от медиасервера медиапотока, содержащего множество последовательных элементов потока, причем объект (200) управления содержит приемник (202) для приема передачи сигналов процедуры управления сеансом связи для передачи медиапотока,
контроллер (206) для завершения передачи сигналов, при этом контроллер (206) соединен с приемником (202) и выполнен с возможностью ассоциирования (38) медиапотока с сеансом связи в процедуре управления сеансом связи, и
контроллер (206) соединен с передатчиком (218) для управления инициированием команд передачи последующего элемента из элементов потока в соответствии с правилом управления сеансом связи.

24. Объект управления по п. 23, причем объект управления выполнен с возможностью выполнения способа по любому из пп. 1-13.

25. Способ в объекте (200) управления для выполнения процедуры управления сеансом связи с медиаклиентом для передачи от медиасервера медиапотока, содержащего множество последовательных элементов потока, причем способ содержит этапы, на которых:
принимают (240) передачу сигналов процедуры управления сеансом связи для передачи медиапотока,
завершают (242) передачу сигналов и ассоциирование медиапотока с сеансом связи в процедуре управления сеансом связи, и
отправляют (244) команду, инициирующую управление передачей последующего элемента из элементов потока в соответствии с правилом управления сеансом связи.

26. Медиа прокси (250) для пересылки описания мультимедиа от сервера клиенту, причем медиа прокси содержит
приемник (252) для приема от сервера описания (254) мультимедиа, содержащего множество описаний представлений, при этом каждое описание представления указывает отличающееся представление медиапотока,
процессор (256), выполненный с возможностью модифицирования описания (254) мультимедиа посредством удаления или модифицирования, по меньшей мере, одного из описаний представлений и медиаисточника, по меньшей мере, одного описания представления из описания мультимедиа, и
передатчик (262) для отправки клиенту модифицированного описания (264) мультимедиа.

27. Медиапрокси по п. 26, причем медиапрокси выполнен с возможностью выполнения способа по любому из пп. 1-13.

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