RU2658860C2

RU2658860C2 - Устройство прокси-сервера, способ обработки информации, программа, оконечное устройство и система предоставления контента

Info

Publication number: RU2658860C2
Application number: RU2016105847A
Authority: RU
Inventors: Ясуаки ЯМАГИСИ
Original assignee: Сони Корпорейшн
Priority date: 2013-08-26
Filing date: 2014-08-12
Publication date: 2018-06-25
Also published as: EP3041243A4; CN105474649B; WO2015029767A1; EP3041243A1; JP2015043486A; CN105474649A; US20160219121A1; RU2016105847A

Abstract

Изобретение относится к прокси-серверу для эффективной потоковой доставки контента по протоколу динамической адаптивной потоковой HTTP-передачи - группы экспертов по движущимся изображениям (DASH MPEG). Технический результат заключается в улучшении характеристики ответной реакции в отношении запросов от стороны приема посредством оптимизации кэширования прокси-сервером. Предложено устройство прокси-сервера, содержащее: блок контроля для контроля запроса на получение метафайла, содержащего информацию о том, что оконечному устройству требуется поток контента, причем запрос передается оконечным устройством устройству предоставления контента, выполненному с возможностью доставки контента по сети в соответствии с технологией адаптивной потоковой передачи; блок анализа для анализа контролируемого запроса получения метафайла и блок базы данных для накопления результатов анализа, полученных блоком анализа. 6 н. и 2 з.п. ф-лы, 9 ил.

Description

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

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

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

В качестве глобально стандартизированного протокола доставки движущегося изображения, который может использоваться для доставки движущегося изображения по Интернету, существует известный протокол DASH MPEG (Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP, динамическая адаптивная потоковая HTTP-передача - группа экспертов по движущимся изображениям, здесь дополнительно упоминаемый как DASH), который использует одноадресную HTTP-передачу, подобную просмотру веб-сайтов и т.п.(например, обратитесь к непатентной литературе 1).

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

Таким образом, в DASH метаданные, называемые MPD (Media Presentation Description, описание медиапрезентации), предоставляются стороной предоставления стороне приема, так чтобы сторона приема могла адаптивно выбрать и принять поток.

Адрес (информация URL) веб-сервера, который является источником предоставления сегментных потоков разделенного на блоки контента (медиаданные, такие как Audio/Video/Subtitle, аудио/видео/подзаголовок), описывается в MPD. Сторона приема, основываясь на информации URL, передает запрос HTTP на веб-сервер, являющийся источником предоставления контента, и принимает и воспроизводит поток сегментов, который веб-сервер передает посредством одноадресной передачи в соответствии с этим HTTP-запросом.

На фиг. 1 показан пример построения системы предоставления контента, которая передает сегментные потоки контента, основываясь на DASH.

Эта система 10 предоставления контента построена из множества устройств 20-1 -20-К предоставления контента на стороне, предоставляющей контент, и множества DASH-клиентов 30-1 - 30-N на стороне, принимающей контент. Здесь ниже, когда нет необходимости различать устройства 20-1 - 20-K предоставления контента, они будут просто называться устройством 20 предоставления контента. То же самое относится к DASH-клиентам 30-1 - 30-N.

Каждое из устройств 20 предоставления контента и DASH-клиента 30 соединяется с Интернетом 11. CDN (сеть доставки контента) 12 создается в Интернете 11.

Устройство 20 предоставления контента является устройством, которое доставляет множество сегментных потоков одного и того же контента, но с различными битовыми скоростями передачи, и имеет канальный стример 21, сегментный DASH-стример 22 и DASH-сервер 23 MPD.

Канальный стример 21 управляет исходными данными контента для доставки DASH-клиенту 30 и формирует множество потоковых данных с разными битовыми скоростями передачи из исходных данных контента и выводит их на сегментный DASH-стример 22.

Сегментный DASH-стример 22 временно делит (разбивает на части) данные каждой потоковой передачи на сегменты, чтобы сформировать сегментный поток. Кроме того, сегментный DASH-стример 22 формирует файлы и хранит сегментный поток и, как веб-сервер, в соответствии с запросом (HTTP-запрос) от DASH-клиента 30, через CDN 12 доставляет посредством одноадресной HTTP-передачи файл сегментного потока DASH-клиенту 30, который является источником запроса. Кроме того, сегментный DASH-стример 22 уведомляет DASH-сервер 23 MPD об адресе источника предоставления файла сегментного потока.

DASH-сервер 23 MPD формирует MPD, содержащий адреса и т.п., указывающие источник предоставления файла сегментного потока, который запрашивает DASH-клиент 30, чтобы получить файл сегментного потока. Кроме того, DASH-сервер 23 MPD, в качестве веб-сервера, в соответствии с запросом (HTTP-запрос) от DASH-клиента 30, через CDN 12 доставляет посредством одноадресной HTTP-передачи сгенерированный MPD DASH-клиенту 30, который является источником запроса.

DASH-клиент 30 запрашивает MPD от DASH-сервера 23 MPD и в ответ принимает MPD, доставленный посредством одноадресной HTTP-передачи. Кроме того, DASH-клиент 30, основываясь на принятом MPD, запрашивает потоковый файл от сегментного DASH-стримера 22 и в ответ принимает и воспроизводит файл сегментного потока, доставляемый посредством одноадресной HTTP-передачи.

Заметим, что прокси-сервер 13, который кэширует MPD и файл сегментного потока, переданный посредством одноадресной HTTP-передачи через CND 12, обеспечивается в CDN 12. Прокси-сервер 13 вместо DASH-сервера 23 MPD или сегментного DASH-стримера 22 в качестве веб-серверов доставляет посредством одноадресной HTTP-передачи источнику запроса кэшированный MPD или файл сегментного потока.

Литература

Непатентная литература

Непатентная литература 1: Hirabayashi, Mitsuhiro "Realizing Moving Image Delivery With No Drop-outs in an Existing Web Server", Nikkei Electronics, March 19, 2012

Раскрытие изобретения Техническая проблема

Как упомянуто выше, обеспечивая в CDN 12 прокси-сервер 13, можно улучшить характеристики ответной реакции на запросы от DASH-клиента 30.

Однако, прокси-сервер 13, способный доставлять MPD или сегментный поток вместо DASH-сервера 23 MPD или сегментного DASH-стримера 22 в качестве вебсерверов, ограничивается случаем, когда их уже кэшировали. То есть, в то время, как он способен к быстрому ответу в случае другого DASH-клиента 30, делающего запрос и которому доставка уже была сделана соответственно кэшированной, в случае, когда запрашивается что-то, что не каптировано, он был неспособен ответить.

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

Решение проблемы

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

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

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

Блок кэширования может регистрировать или отменять регистрацию политики кэширования в соответствии с запросом от оконечного устройства.

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

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

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

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

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

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

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

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

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

Предпочтительные результаты изобретения

В соответствии с первым вариантом настоящего раскрытия, возможна оптимизация кэширования и улучшение характеристик ответной реакции на запросы со стороны приема.

В соответствии со вторым вариантом настоящего раскрытия, возможна оптимизация кэширования прокси-сервером.

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

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

Фиг. 1 - блок-схема примера конфигурации традиционной системы предоставления контента.

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

Фиг. 3 - блок-схема примера конфигурации оптимизируемого прокси-сервера.

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

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

Фиг. 6 - блок-схема последовательности выполнения операций процесса многоадресного предварительного кэширования, выполняемого устройством предоставления контента.

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

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

Фиг. 9 - блок-схема примера конфигурации компьютера.

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

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

Пример конфигурации системы предоставления контента

На фиг. 6 показан пример конфигурации системы предоставления контента, являющейся вариантом осуществления настоящего раскрытия.

Эта система 50 предоставления контента состоит из множества устройств 60-1 - 60-K предоставления контента, CDN 72, выполненной в сети 71, и множества оконечных устройств 80-1 - 80-N. Устройства 60-1 - 60-K предоставления контента и оконечные устройства 80-1 - 80-N соединяются с сетью 71.

Здесь далее, когда нет необходимости различать устройства 60-1 - 60-K предоставления контента, их просто называют устройством 60 предоставления контента. То же самое относится к оконечным устройствам 80-1 - 80-N.

Устройство 60 предоставления контента содержит канальный стример 61, DASH-сегментатор 62, FLUTE-стример 63, генератор 64 MPD, веб-сервер 65 и многоадресный сервер 66.

Заметим, что канальный стример 61 и многоадресный сервер 66, которые имеет устройство 60 предоставления контента, могут быть интегрированы в одном устройстве или могут быть распределены по Интернету или аналогичным образом.

Канальный стример 61 управляет данными источника контента для подачи оконечному устройству 80 и формирует множество потоковых данных, отличающихся по битовой скорости передачи от данных источника одного и того же контента. Кроме того, канальный стример 61 выводит сформированные потоковые данные на DASH-сегментатор 62.

DASH-сегментатор 62 посредством временного разделения потоковых данных на периоды и последующего разделения их на сегменты, генерирует сегментный поток, такой как фрагментированный МР4, и выводит его на веб-сервер 65 и FLUTE-стример 63. Кроме того, DASH-сегментатор 62 уведомляет генератор 64 MPD метаданных, содержащих адресную информацию веб-сервера 65, что он становится источником предоставления файла, сгенерированного сегментного потока.

Генератор 64 MPD генерирует MPD, требующийся для оконечного устройства 80, чтобы принять сегментный поток, и выводит его на FLUTE-стример 63 и на веб-сервер 65.

FLUTE-стример 63, сохраняя в пакетах FLUTE сегментный поток, введенный от DASH-сегментатора 62, генерирует FLUTE-поток и выводит его на многоадресный сервер 66. Кроме того, FLUTE-стример 63 выводит MPD, введенный от генератора 64 MPD, на многоадресный сервер 66.

Веб-сервер 65, в соответствии с запросом получения MPD (запрос HTTP) от оконечного устройства 80, передает посредством одноадресной передачи HTTP MPD, введенный от генератора 64 MPD, через CDN 72 оконечному устройству 80, являющемуся источником запроса. Кроме того, веб-сервер 65, в соответствии с запросом получения сегментного потока (запросом HTTP) от оконечного устройства 80, доставляет посредством одноадресной передачи HTTP файл сегментного потока, введенный от DASH-сегментатора 62, через CDN 72 оконечному устройству 80, которое является источником запроса.

Многоадресный сервер 66 передает MPD посредством многоадресной FLUTE-передачи от FLUTE-стримера 63 через CDN 72. Кроме того, многоадресный сервер 66 передает FLUTE-поток посредством многоадресной FLUTE-передачи от FLUTE-стримера 63 через CDN 72. Кроме того, например, USD для (e)MBMS, OMA-ESG и т.п., используются для распространения портальных каналов многоадресной FLUTE-передачи.

Сеть 71 содержит сеть двусторонней связи, представленную Интернетом, сеть односторонней связи, такую как наземная широковещательная сеть или сеть спутникового вещания, и сеть связи мобильных телефонов, такую как e-MBMS, имеющую канал взаимодействия, осуществляющий двустороннюю связь, и канал широковещательной передачи/многоадресной передачи, осуществляющий одностороннюю связь.

CDN 72 создается в сети 71. В CDN 72 обеспечивается множество оптимизируемых прокси-серверов 73, портальные серверы MPD 74 и серверы 75 сценария. Кроме того, хотя его графический дисплей отсутствует, в CDN 72 может существовать традиционный прокси-сервер 13.

Оптимизируемый прокси-сервер 73, посредством контроля и анализа запросов получения MPD и запросов получения сегментного потока от оконечного устройства 80, делает вывод о возможности приема, возможности декодирования, предпочтениях пользователя, состоянии и т.п.оконечного устройства 80, соединенного с ним, и возвращает их в базу данных в качестве статистической информации (упоминается ниже как процесс анализа запроса).

Кроме того, оптимизируемый прокси-сервер 73 посредством контроля метаданных (таких как OMA-ESG и т.п.), в которых контент MPD и FLUTE-поток, передаваемые посредством многоадресной передачи через CDN 72, описываются и сопоставляются с его собственной базой данных, принимает решение, является ли их приоритет высоким (вероятность получения впредь запроса, передаваемого от оконечного устройства 80, которое соединяется с ним, является высокой). Затем он кэширует MPD или FLUTE-поток с высоким приоритетом (упоминается ниже как многоадресный процесс предварительного кэширования).

Кроме того, оптимизируемый прокси-сервер 73, посредством контроля MPD и сегментного потока, передаваемых путем одноадресной передачи через CDN 72, и сопоставления их с его собственной базой данных, определяет, обладают ли они высоким приоритетом. Затем, он кэширует MPD и сегментный поток с высоким приоритетом (упоминается ниже как процесс одноадресного кэширования).

Кроме того, оптимизируемый прокси-сервер 73 может искать и определять MPD и сегментные потоки с высоким приоритетом от портального сервера 74 MPD, запрашивать от устройства 60 предоставления контента указанные MPD и сегментные потоки и кэшировать те, которые передаются в ответ посредством одноадресной HTTP-передачи.

Также, дополнительно, оптимизируемый прокси-сервер 73, основываясь на управлении от оконечного устройства 80, регистрирует и отменяет регистрацию политики процесса многоадресного предварительного кэширования и политики процесс одноадресного предварительного кэширования (упоминаемых ниже как процесс регистрации политики предварительного кэширования).

Портальный сервер 74 MPD получает доступ к устройствам 60 предоставления контента, существующим во множестве, и ищет MPD и сегментные потоки, удовлетворяющие заданным условиям.

Сервер 75 сценария, в соответствии с запросом от оконечного устройства 80, обеспечивает сценарий предпочтительного соединения с оптимизируемым сервером 73, который оптимален для оконечного устройства 80 (например, оконечное устройство 80 может располагаться в непосредственной близости и оконечное устройство 80 может, в случае неспособности принимать многоадресную передачу, быть способно к приему, не имея его) (процесс предоставления сценария).

Оконечное устройство 80 имеет блок 81 приема/воспроизведения, блок 82 регистрации 82 и блок 83 запроса сценария. Блок 81 приема/воспроизведения принимает MPD и, основываясь на MPD, принимает и воспроизводит сегментный поток и FLUTE-поток. Блок 82 регистрации выполняет процесс регистрации или отмены регистрации политики процесса предварительного кэширования на оптимизируемом прокси-сервере 73 Блок 83 запроса сценария запрашивает у сервера 75 сценария сценарий автоматического соединения с оптимизируемым прокси-сервером 73, который оптимален для него самого (например, тот, который располагается в непосредственной близости, тот, который может принимать передачи широковещательной сети, которые он сам не может принимать).

Пример подробной конфигурации оптимизируемого прокси-сервера 73

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

Оптимизируемый прокси-сервер снабжен блоком 91 контроля, действующим в качестве посредника, блоком 92 хранения, блоком 93 анализа, базой 94 данных результатов анализа и блоком 95 тюнера.

Блок 91 контроля в качестве посредника контролирует запросы получения MPD и запросы получения сегментных потоков от оконечного устройства 80 и в случае, когда запрошенный MPD или сегментный поток кэширован в блоке 92 хранения, считывает их из блока 92 хранения и передает посредством одноадресной передачи источнику запроса. Кроме того, блок 91 контроля в качестве посредника выводит на блок 93 анализа проконтролированные запросы получения MPD и запросы получения сегментного потока. Кроме того, блок 91 контроля в качестве посредника выполняет контроль MPD и сегментных потоков, которые передаются посредством одноадресной передачи HTTP, и выводит их на блок 93 анализа.

В блоке 92 хранения хранятся (кэшируются) MPD и сегментные потоки, введенные из блока 93 анализа и оцениваемые как обладающие высоким приоритетом. Кроме того, блок 92 хранения содержит MPD и FLUTE-потоки, оцениваемые как обладающие высоким приоритетом, которые вводятся из блока 95 предварительного кэширования.

Блок 93 анализа анализирует контролируемые запросы получения MPD и запросы получения сегментного потока. Конкретно, URL MPD, информация о профиле, описанная в MPD/@profile, максимальное значение размера сегмента (значение @duration или значение @maxSegmentDuration, @maxSubSegmentDuration), контент метаданных, описывающий контент, который ищет Programlnformation (в частности, получение и анализ заголовка, краткое содержание, жанр и т.п. контента как процесс загрузки, разрешает и накапливает их как информацию о предпочтениях), контент схемы, которая ищет Role, и контент схемы доступности, которая ищет Accessibility (например, в случае присутствия запроса получения сегментов для потока, содержащего речевое контролируемое руководство, можно вывести предпочтение пользователя для речевого потока, степени неспособности и т.п.), тип языка, описанный в @lang, информация о рейтинге, которую ищет Rating, распределение @bandwidth, информация о количестве пикселей по вертикали и по горизонтали, выраженная комбинацией @width и @height, информация о частоте выборки, описанная в @audioSamplingRate, тип кодека, описанный в @codec, информация о конфигурации звукового канала, которую ищет audioChannelConfiguration, считывая тип DRM, который ищет contentProtection, и заставляет эти контенты храниться в качестве статистической информации, связанной с частотой запросов получения в базе 94 данных результатов анализа.

Кроме того, блок 93 анализа дает оценку приоритета MPD и сегментного потока, вводимых от блока 91 контроля в качестве посредника и контролируемых по одноадресной HTTP-передаче, и заставляет тех из них, которые имеют высокий приоритет, храниться в блоке 92 хранения. Кроме того, блок 93 анализа дает оценку приоритета MPD и FLUTE-потока, введенных от блока 95 тюнера и переданных посредством многоадресной FLUTE-передачи, и заставляет тех из них, которые имеют высокий приоритет, сохраняться в блоке 92 хранения.

База 94 данных результатов анализа содержит информацию о тактовом сигнале результатов анализа, вводимую от блока 93 анализа.

Блок 95 тюнера принимает MPD и FLUTE-потоки, переданные посредством многоадресной FLUTE-передачи, и их метаданные и выводит их на блок 93 анализа.

Порядок действия системы 50 предоставления контента

Далее будет описан порядок действия системы 50 предоставления контента.

Описание процесса передачи контента

На фиг. 4 представлена блок-схема последовательности выполнения операций процесса передачи контента устройством 60 предоставления контента.

На этапе S1 канальный стример 61 генерирует множество данных потоковой передачи с различными битовыми скоростями передачи из данных исходного контента и выводит их в DASH-сегмент и на веб-сервер 65.

На этапе S2 DASH-сегментатор 62 генерирует сегментный поток, такой как фрагментированный МР4, из данных потоковой передачи и выводит его на FLUTE-стример 63 и на веб-сервер 65. Кроме того, DASH-сегментатор 62 уведомляет генератор 64 MPD об URL источника предоставления сгенерированного сегментного потока.

На этапе S3 FLUTE-стример 63 генерирует FLUTE-поток, сохраняя сегментный поток в FLUTE-пакете, и выводит его на многоадресный сервер 66. На этапе S4 генератор 64 MPD генерирует MPD и выводит его на FLUTE-стример 63 и на веб-сервер 65.

На этапе S5 FLUTE-стример 63 выводит MPD на многоадресный сервер 66. Многоадресный сервер 66 распространяет MPD посредством многоадресной FLUTE-передачи через CDN 72.

На этапе S6 веб-сервер 65, в случае, когда существует запрос получения MPD (HTTP-запрос) от оконечного устройства 80, в ответ передает MPD посредством однонаправленной HTTP-передачи через CDN 72.

На этапе S7 многоадресный сервер 66 передает FLUTE-поток посредством многоадресной FLUTE-передачи через CDN 72. На этапе S8 веб-сервер 65, в случае, когда существует запрос получения сегментного потока (HTTP-запрос) от оконечного устройства 80, передает сегментный поток посредством одноадресной HTTP-передачи источнику запроса через CDN 72. Этим завершается описание процесса передачи контента устройством 60 предоставления контента.

Описание процесса анализа запроса,

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

Когда оконечное устройство 80 в качестве этапа S11 передает запрос получения MPD на веб-сервер 65 через CDN 82, на этапе S21 блок 91 контроля в качестве посредника оптимизируемого прокси-сервера 73 контролирует запрос получения MPD и выводит его на блок 93 анализа. На этапе S22 блок 93 анализа анализирует запрос получения MPD и записывает результат в базу 94 данных результатов анализа.

Заметим, что в случае MPD, соответствующего запросу получения MPD, контролируемому на этапе S21, уже кэшированного в блоке 92 хранения, блок 91 контроля в качестве посредника считывает MPD из блока 92 хранения и передает его посредством одноадресной HTTP-передачи источнику запроса. На фиг. 5 показан пример случая MPD, который не был кэширован, и в этом случае, как на этапе S6 процесса предоставления контента, описанном выше, веб-сервер 65 передает посредством одноадресной HTTP-передачи источнику запроса MPD соответствующий запрос получения MPD через CDN 72.

MPD, который передается посредством одноадресной HTTP-передачи, принимается оконечным устройством 80 на этапе S12. Когда оконечное устройство 80, как на этапе S13, передает веб-серверу 65 через CDN 82 запрос получения сегментного потока, основываясь на MPD, на этапе S23 блок 91 контроля в качестве посредника контролирует запрос получения сегментного потока и выводит его на блок 93 анализа. На этапе S24 блок 93 анализа анализирует запрос получения сегментного потока и записывает результат в базу 94 данных результатов анализа.

Заметим, что в случае, когда блок 92 хранения уже кэшировал сегментный поток, соответствующий запросу получения сегментного потока, контролируемого на этапе S23, блок 91 контроля в качестве посредника считывает сегментный поток из блока 92 хранения и передает его посредством одноадресной HTTP-передачи источнику запроса. На фиг. 5 представлен пример случая сегментного потока, который не был кэширован, и в этом случае, как на этапе S8 процесса предоставления контента, описанном выше, вебсервер 65 передает посредством одноадресной HTTP-передачи источнику запроса через CDN 72 сегментный поток, соответствующий запросу получения сегментного потока.

Сегментный поток, переданный посредством одноадресной HTTP-передачи, принимается и воспроизводится оконечным устройством 80, как на этапе S14. Этим завершается процесс анализа запроса.

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

Описание многоадресного процесса предварительного кэширования

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

Когда многоадресный сервер 66 устройства 60 предоставления контента на этапе S31 передает MPD посредством многоадресной FLUTE-передачи, как на этапе S5 процесса предоставления контента, описанном выше, блок 95 тюнера оптимизируемого прокси-сервера 73 принимает MPD и выводит его на блок 93 анализа. Блок 93 анализа обращается к базе 94 данных результатов анализа и в случае, когда MPD обладает высоким приоритетом, заставляет его кэшироваться в блоке 92 хранения.

Аналогично, когда многоадресный сервер 66 устройства 60 предоставления контента передает посредством многоадресной FLUTE-передачи FLUTE-поток, как на этапе S7 процесса предоставления контента, описанном выше, на этапе S32 блок 95 тюнера принимает FLUTE-поток и выводит его на блок 93 анализа. Блок 93 анализа обращается к базе 94 данных результатов анализа и в случае, когда FLUTE-поток обладает высоким приоритетом, заставляет его кэшироваться в блоке 92 хранения. Этим завершается многоадресный процесс предварительного кэширования.

С помощью многоадресного процесса, предварительного кэширования, можно кэшировать MPD и FLUTE-поток с высоким приоритетом в блоке 92 хранения. Заметим, что предоставление кэшированного MPD или FLUTE-потока оконечному устройству 80, делается так, чтобы они передавались посредством одноадресной передачи. Соответственно, например, даже в случае оконечного устройства 80, не обладающего возможностью приема FLUTE-потока, можно предоставить их оконечному устройству 80.

Описание одноадресного процесса предварительного кэширования

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

Когда оконечное устройство 80 передает запрос получения MPD, как на этапе S41, веб-сервер 65 передает посредством одноадресной HTTP-передачи MPD, соответствующий запросу получения MPD, как на этапе S6 процесса предоставления контента, описанном выше, и оконечное устройство 80 на этапе S42 принимает MPD, переданный посредством одноадресной HTTP-передачи.

На этапе S51 блок 91 контроля в качестве посредника оптимизируемого прокси-сервера 73 контролирует этот MPD, переданный посредством одноадресной HTTP-передачи, и выводит его на блок 93 анализа. Блок 93 анализа оценивает приоритет MPD, переданных посредством одноадресной HTTP-передачи, и заставляет тех, которые обладают высоким приоритетом, сохраняться в блоке 92 хранения. Заметим, что в отношении запроса получения MPD, которые передало оконечное устройство 80, он контролируется и анализируется и результат процесса анализа запроса накапливается в базе 94 данных результатов анализа, как описано выше.

Когда оконечное устройство 80 на этапе S43 передает запрос получения сегментного потока, основываясь на принятом MPD, веб-сервер 65 передает посредством одноадресной HTTP-передачи сегментный поток, соответствующий запросу получения сегментному потоку, как этап S8 процесса предоставления контента, описанный выше, и оконечное устройство 80 в качестве этапа S42 принимает и воспроизводит сегментный поток, передаваемый посредством одноадресной HTTP-передачи,

На этапе S52 блок 91 контроля в качестве посредника оптимизируемого прокси-сервера 73 контролирует этот сегментный поток, передаваемый посредством одноадресной HTTP-передачи, и выводит его на блок 93 анализа. Блок 93 анализа оценивает приоритет сегментных потоков, передаваемых посредством одноадресной HTTP-передачи, и заставляет тех, которые обладают высоким приоритетом, сохраняться в блоке 92 хранения. Заметим, что в отношении запроса получения сегментного потока, который передало оконечное устройство 80, он контролируется и анализируется и результат накапливается в базе 94 данных результатов анализа, как описано выше, в качестве процесса анализа запроса.

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

Описание процесса предоставления сценария

Далее, на фиг. 8 представлена блок-схема последовательности выполнения операций процесса предоставления сценария.

На этапе S61, когда блок 83 запроса сценария оконечного устройства 80, используя WPAD (Web Proxy Auto-Discover Protocol, веб-протокол прокси-автообнаружения) и т.п., передает CDN 72 запрос РАС (Proxy Auto-Config, прокси-автоконфигурация) сценария, который выполняет настройку, чтобы иметь возможность соединяться с оптимизируемым прокси-сервером 72, который оптимален для себя самого, этот запрос принимается сервером 75 сценария.,

На этапе S71 сервер 75 сценария определяет оптимизируемый прокси-сервер 73, * оптимальный для оконечного устройства 80, которое передало запрос сценария РАС, и предоставляет источнику запроса сценарий, который выполняет настройку для соединения оконечного устройства 80 с оптимизируемым прокси-сервером 73.

На этапе S72 сервер 75 сценария, блок 83 запроса сценария оконечного устройства 80 выполняет предоставленный сценарий. Таким образом, выполняется настройка, которая должна быть способна предпочтительно произвести соединение с оптимизируемым прокси-сервером 73, оптимальным для оконечного устройства 80. Этим завершается процесс предоставления сценария.

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

Описание процесса регистрации политики предварительного кэширования

Далее будет описан процесс регистрации или отмены регистрации политики предварительного кэширования путем управления со стороны оконечного устройства 80.

В случае регистрации политики предварительного кэширования, блок 82 регистрации оконечного устройства 80, используя API (Application Program Interface, прикладной программный интерфейс), который обеспечивает оптимизируемый прокси-сервер 73, определяет, например, такой API, как указано ниже, в сценарии на стороне сервера, который управляет регистрацией политики предварительного кэширования посредством оптимизируемого прокси-сервера 73.

http://dashProxy.a.com/precacheManager/subscribe?codec=ʺurn:b.com:codecType:avcʺ&rating=ʺurn:с.сom:ratingLevel:PG-13ʺ&priority=1

http://dashProxy.a.com/precacheManager/subscribe в упомянутом выше API указывает адрес для адреса сценария на стороне сервера в оптимизируемом прокси-сервере 73. Последующие "urn:b.com:codecType:avcʺ&rating=ʺura:c.com:ratingLevel:PG-13ʺ&priority=1" являются параметрами API, которые переходят в сценарий на стороне сервера.

Упомянутый выше пример с параметрами API, в котором тип кодека, установленный в MPD, который является целью предварительного кэширования (или описывается в метаданных потока, на который делается ссылка в MPD), является кодеком, указанным в ʺurn:a.com:codecType:avcʺ, который является позицией uri словаря кодека, и тип рейтинга является уровнем рейтинга, указанным "urn: c.com:ratingLevel:PG-13ʺ, который является позицией uri словаря рейтинга, то есть, является позицией, которая назначает приоритет предварительного кодирования MPD, описывая поток, удовлетворяющий этим двум условиям приоритета, равным 1 (чем меньше число, тем выше приоритет).

Ниже представлен другой пример API, назначенного для сценария на стороне сервера, который управляет добавлением статистической информации оптимизируемого прокси-сервера 73.

http://dashProxy.a.com/precacheManager/subscribe?genre="urn:b.com:genre:sportsʺ&priority=2

Параметр API в приведенном выше API, в котором тип жанра, установленный в MPD, который является целью предварительного кэширования (или описан в метаданных потока, на который делается ссылка в MPD) определяется как "urn:b.com:genre:sports", который является позицией uri элемента словаря жанра, той, которая назначает приоритет предварительного кэширования равным 2.

В случае отмены регистрации политики предварительного кэширования, используя API, которую обеспечивает оптимизируемый прокси-сервер 73, блок 82 регистрации оконечного устройства 80 назначает, например, API, таким, как указано далее в сценарии на стороне сервера, который управляет удалением политики предварительного кэширования оптимизируемым прокси-сервером 73.

http://dashProxy.a.com/precacheManager/unsubscribe?genre=ʺurn:b.com:genre:sportsʺ

Параметр API в указанном выше API является параметром, который отменяет регистрацию из числа кандидатов на предварительное кэширование MPD, в котором описывается жанр, тип жанра назначается посредством "urn:b.com:genre:sports", который является uri-позицией словаря жанра.

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

Таким образом, в варианте осуществления, обеспечивая прокси-сервер 73 оптимизации в CDN 72, можно улучшать характеристики ответной реакции в отношении запросов от оконечного устройства 80.

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

На фиг. 9 приведена блок-схема примера конфигурации аппаратурного обеспечения вышеупомянутого компьютера.

В компьютере 200 CPU (центральный процессор) 201, ROM (постоянная память) 202 и RAM (оперативная память) 203 соединяются друг с другом шиной 204.

Интерфейс 205 ввода-вывода также соединяется с шиной 204. Устройство 206 ввода, устройство 207 вывода, запоминающее устройство 208, блок 209 связи и привод 210 соединяются с интерфейсом 205 ввода-вывода.

Устройство 206 ввода содержит клавиатуру, мышь, микрофон и т.п. Устройство 207 вывода содержит устройство отображения, громкоговоритель и т.п. Запоминающее устройство 208 содержит жесткий диск, энергонезависимую память и т.п. Блок 209 связи содержит сетевой интерфейс и т.п. Привод 210 приводит в движение съемный носитель 211, такой как магнитный диск, оптический диск, магнитно-оптический диск или полупроводниковая память.

В компьютере 200, который построен упомянутым выше способом, CPU 201 загружает и исполняет программу, хранящуюся запоминающем устройстве 208, через интерфейс 205 ввода-вывода и шину 204, посредством чего выполняется упомянутый выше ряд процессов.

Программа, выполняемая компьютером 200 (CPU 201), может обеспечиваться посредством записи, например, на съемных носителях 211, таких как пакет носителей. Альтернативно, программа может быть предоставлена через проводную или беспроводную среду передачи, такую как локальная сеть, Интернет и цифровая спутниковая широковещательная передача.

Программа может быть установлена в запоминающем устройстве 208 через интерфейс 205 ввода-вывода, загружая съемные носители 211 на привод 210. Кроме того, программа может быть принята блоком 209 связи через проводную или беспроводную среду передачи и установлена в блоке 208 запоминающего устройства. Кроме того, программа может также быть установлена заранее в ROM 202 или в запоминающее устройство 208.

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

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

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

(1) Устройство прокси-сервера, содержащее:

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

блок анализа для анализа контролируемого запроса получения метафайла; и

блок базы данных для накопления результатов анализа, полученных блоком анализа.

(2) Устройство прокси-сервера по (1), в котором

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

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

(3) Устройство прокси-сервера по (1) или (2), дополнительно содержащее:

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

(4) Устройство прокси-сервера по (3), в котором

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

Перечень ссылочных позиций

50 Система предоставления контента

60 Устройство предоставления контента

61 Канальный стример

62 DASH-сегментатор

63 FLUTE-стример

64 Генератор MPD

65 Веб-сервер

66 Многоадресный сервер

71 Сеть

72 CDN

73 Оптимизируемый прокси-сервер

74 Мобильный сервер MPD

75 Сервер сценария

80 Оконечное устройство

81 Блок приема/воспроизведения

82 Блок регистрации

83 Блок запроса сценария

200 Компьютер

201 Центральный процессор, CPU

Claims

1. Устройство прокси-сервера, содержащее:

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

блок анализа для анализа контролируемого запроса получения метафайла и запроса на получение потока контента;

блок базы данных для накопления результатов анализа, полученных блоком анализа; и

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

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

2. Способ обработки информации устройства прокси-сервера, содержащий:

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

этап анализа, на котором анализируют, с помощью устройства прокси-сервера, контролируемый запрос на получение метафайла и запрос на получение потока контента и накапливают результаты анализа; и

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

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

4. Оконечное устройство, содержащее:

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

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

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

5. Оконечное устройство по п. 4, дополнительно содержащее:

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

6. Способ приема контента, содержащий этапы, на которых:

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

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

принимают метафайл и/или поток, кэшированные в соответствии с приоритетом, на основе накопленных результатов анализа и зарегистрированной политики кэширования.

7. Способ по п. 6, дополнительно содержащий этапы, на которых:

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

8. Система предоставления контента, содержащая:

устройство предоставления контента для доставки контента по сети в соответствии с технологией адаптивной потоковой передачи;

оконечное устройство по п. 4 или 5 и

устройство прокси-сервера по п. 1.