ES2630279T3 - Soporte para diversidad de transportes y memorias intermedias desplazadas en el tiempo para la transmisión continua de medios sobre una red - Google Patents

Soporte para diversidad de transportes y memorias intermedias desplazadas en el tiempo para la transmisión continua de medios sobre una red Download PDF

Info

Publication number
ES2630279T3
ES2630279T3 ES14703972.1T ES14703972T ES2630279T3 ES 2630279 T3 ES2630279 T3 ES 2630279T3 ES 14703972 T ES14703972 T ES 14703972T ES 2630279 T3 ES2630279 T3 ES 2630279T3
Authority
ES
Spain
Prior art keywords
media data
request
service
proxy
media
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES14703972.1T
Other languages
English (en)
Inventor
Kevin Roland Fall
Nagaraju Naik
Thomas Stockhammer
Fatih Ulupinar
Carlos Marcelo Dias Pazos
Charles N. Lo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2630279T3 publication Critical patent/ES2630279T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un procedimiento de recuperación de datos de medios, comprendiendo el procedimiento: mediante una unidad de proxy (818, 1218): la obtención de información de asignación que asigna un identificador para datos de medios a una ubicación de recursos basándose en un servicio para recuperar los datos de medios, caracterizado porque el servicio define al menos uno de una pluralidad de tipos de transportes para transportar los datos de medios; la recepción de una petición para los datos de medios desde un cliente de servicios de aplicaciones (802, 1202); la determinación de si el servicio está disponible; y si el servicio está disponible, hacer que el cliente de servicios de aplicaciones reciba los datos de medios de una unidad (808, 1208) que recibe los datos de medios utilizando el servicio de la ubicación de recursos, basándose en la información de asignación.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Soporte para diversidad de transportes y memorias intermedias desplazadas en el tiempo para la transmision oontlnua de medios sobre una red
CAMPO TECNICO
La presente divulgaoion se refiere a sistemas de oomunioaoion y, mas oonoretamente, a la entrega de oontenido a traves de una red.
ANTECEDENTES
Las oapaoidades multimedia digitales (inoluyendo audio y video y otros medios) pueden inoorporarse en una amplia gama de dispositivos, inoluyendo televisores digitales, sistemas de difusion direota digital, sistemas de difusion inalambrioa, asistentes digitales personales (PDA), ordenadores portatiles o de esoritorio, oamaras digitales, dispositivos de grabaoion digitales, reproduotores de medios digitales, dispositivos de videojuegos, oonsolas de videojuegos, telefonos oelulares o de radio por satelite, dispositivos de videooonferenoia, y similares. Los dispositivos multimedia digitales implementan video, audio y/u otras teonioas de oompresion de medios, tales oomo las desoritas en las normas definidas por MPEG-2, MPEG-4, ITU-T H.263 o ITU-T H.264/MPEG-4 , parte 10, Codifioaoion avanzada de video (AVC), y extensiones de diohas normas, para transmitir y reoibir informaoion multimedia digital de manera mas efioiente.
Las teonioas de oompresion multimedia llevan a oabo una prediooion espaoial y/o una prediooion temporal para reduoir o eliminar la redundanoia presente en las seouenoias de video. Para la oodifioaoion de video basada en bloques, una trama o un fragmento de video pueden dividirse en bloques. Cada bloque se puede dividir adioionalmente. Los bloques de una trama o fragmento intra-oodifioado (I) se oodifioan usando prediooion espaoial oon respeoto a bloques veoinos. Los bloques de una trama o fragmento inter-oodifioado (P o B) pueden usar prediooion espaoial oon respeoto a bloques veoinos de la misma trama o fragmento, o prediooion temporal oon respeoto a otras tramas de referenda.
Despues que los datos multimedia han sido oodifioados (por ejemplo, oomprimidos), los datos pueden empaquetarse para su transmision o almaoenamiento. Los datos pueden montarse en un arohivo oonforme a oualquiera de una variedad de normas, tales oomo el formato de arohivos de medios basado en la Organizaoion Internaoional de Normalizaoion (ISO) y extensiones del mismo, tales oomo AVC.
Las redes de oomunioaoion inalambrioa estan ampliamente implantadas para proporoionar diversos servioios de oomunioaoion, tales oomo voz, video, datos por paquetes, mensajeria, difusion eto. Estas redes inalambrioas pueden ser redes de aooeso multiple que pueden dar soporte a multiples usuarios oompartiendo los reoursos de red disponibles. Ejemplos de tales redes de aooeso multiple inoluyen redes de aooeso multiple por division de oodigo (CDMA), redes de aooeso multiple por division del tiempo (TDMA), redes de aooeso multiple por division de freouenoia (FDMA), redes de aooeso multiple por division de freouenoia ortogonal (OFDMA) y redes de FDMA de portadora unioa (SC-FDMA).
La Evoluoion a Largo Plazo (LTE) del Proyeoto de Colaboraoion de Teroera Generaoion (3GPP) representa un avanoe importante en la teonologia oelular oomo una evoluoion natural del Sistema Global de Comunioaoiones Moviles (GSM) y el Sistema Universal de Teleoomunioaoiones Moviles (UMTS). La oapa fisioa (PHY) de LTE proporoiona una forma altamente efioiente de transmitir tanto datos oomo informaoion de control entre las estaoiones base, tales oomo nodos B evoluoionados (eNB), y los dispositivos moviles, tales oomo los UE. En aplioaoiones anteriores, un prooedimiento para faoilitar la oomunioaoion de alto anoho de banda para multimedia ha sido el funoionamiento de una red de freouenoia unioa (SFN). Las SFN utilizan transmisores de radio, tales oomo, por ejemplo, eNB, para oomunioarse oon los UE de abonado. En el funoionamiento de unidifusion, oada eNB se oontrola oon el fin de transmitir senales que llevan informaoion dirigida a uno o mas UE de abonado partioulares. La espeoifioidad de la senalizaoion de unidifusion permite servioios de persona a persona tales oomo, por ejemplo, las llamadas de voz, los mensajes de texto o las llamadas de video.
El dooumento EP 1322094 divulga un prooeso para seleooionar, en una red de entrega de oontenido que tiene al menos dos servidores sustitutos que entregan oontenido sobre una red, un servidor sustituto adaptado para entregar el oontenido solioitado por un usuario. El dooumento WO 2012/167106 divulga el movimiento de un nodo movil de una primera red de aooeso a una segunda red de aooeso mientras esta en oomunioaoion oon un servidor.
RESUMEN
En general, la presente divulgaoion describe teonioas para la transmision oontinua de datos de medios sobre una red. Por ejemplo, la presente divulgaoion describe teonioas para reoibir datos de medios a traves de diversos tipos de transportes, por ejemplo, oualquiera de unidifusion, difusion y/o multidifuoion. Por ejemplo, una unidad de redireotor/proxy puede haoer que un oliente de servioios de aplioaoiones reoupere datos de medios de Internet
5
10
15
20
25
30
35
40
45
50
55
60
65
direotamente a traves de la unidifusion, o cuando esta disponible un servicio de difusion o mulfidifusion, de una unidad de soporfe intermedio de difusion o mulfidifusion. Alternativamente, la unidad de redireotor/proxy puede reouperar los datos de medios en nombre del oliente de servicios de aplioaoiones cuando no esta disponible el servicio de difusion o mulfidifusion. Cuando hay varios tipos de transporfes disponibles y/o utilizados para transportar datos de medios, se puede utilizar el termino "diversidad de transporfes" a continuacion. Cuando el proveedor (origen de medios) y/o el transporte o transporfes utilizados para transmitir los medios oambian (por ejemplo, mediante una unidad de redireotor/proxy), se puede utilizar el termino "redireccionamiento" o "redireooionado" a continuacion.
La presente divulgacion tambien describe teonioas relaoionadas con el almacenamiento intermedio de los datos de medios recuperados. Por ejemplo, los datos de medios recuperados pueden almaoenarse en una memoria intermedia desplazada en el tiempo (TSB). La presente divulgacion describe teonioas para senalizar un tamano de la TSB, por ejemplo, en terminos del tiempo de reproduccion para el oontenido de medios, de tal manera que se pueda asignar una oapaoidad de memoria apropiada para la TSB. De esta manera, los datos de medios se pueden reproducir posteriormente y/o se pueden reproducir utilizando un modo avanzado de reproduccion, por ejemplo, el avanoe rapido o el rebobinado.
En un modo de realizacion de la invenoion, un procedimiento de aouerdo con la reivindicacion 1 de reouperaoion de datos de medios inoluye, mediante el uso de una unidad de proxy: la obtencion de informacion de asignacion que asigna un identificador para los datos de medios a una ubicacion de recursos basandose en un servicio para reouperar los datos de medios, en el que el servicio define al menos uno de una pluralidad de tipos de transporfes para transportar los datos de medios, la recepcion de una peticion para los datos de medios de un oliente de servicios de aplioaoiones, la determinacion de si el servicio esta disponible, y, si el servicio esta disponible, haoer que el oliente de servicios de aplioaoiones reoiba los datos de medios de una unidad que reoibe los datos de medios utilizando el servicio de la ubicacion de recursos, basandose en la informacion de asignacion.
En otro modo de realizacion de la invenoion, un dispositivo de aouerdo con la reivindicacion 16 para reouperar datos de medios inoluye una unidad de proxy configurada para obtener informacion de asignacion que asigna un identificador para los datos de medios a una ubicacion de recursos basandose en un servicio para reouperar los datos de medios, en el que el servicio define al menos uno de una pluralidad de tipos de transporfes para transportar los datos de medios, reoibir una peticion de datos de medios de un oliente de servicios de aplioaoiones, determinar si el servicio esta disponible, y, si el servicio esta disponible, haoer que el oliente de servicios de aplioaoiones reoiba los datos de medios de una unidad que reoibe los datos de los medios utilizando el servicio de la ubicacion de recursos, basandose en la informacion de asignacion.
En otro ejemplo, un dispositivo para reouperar datos de medios inoluye medios para obtener informacion de asignacion que asigna un identificador para los datos de medios a una ubicacion de recursos basandose en un servicio para reouperar los datos de medios, en el que el servicio define al menos uno de una pluralidad de tipos de transporfes para transportar los datos de medios, medios para reoibir una peticion para datos de medios de un oliente de servicios de aplioaoiones, medios para determinar si el servicio esta disponible, y medios para haoer, si el servicio esta disponible, que el oliente de servicios de aplioaoiones reoiba los datos de medios de una unidad que reoibe los datos de medios utilizando el servicio de la ubicacion de recursos, basandose en la informacion de asignacion.
En otro ejemplo, un medio de almacenamiento legible por ordenador tiene almaoenadas en el mismo instrucciones que, cuando se ejeoutan, haoen que un procesador obtenga informacion de asignacion que asigna un identificador para datos de medios a una ubicacion de recursos basandose en un servicio para reouperar los datos de medios, en el que el servicio define al menos uno de una pluralidad de tipos de medios para transportar los datos de medios, reoiba una peticion para los datos de los medios de un oliente de servicios de aplioaoiones, determine si el servicio esta disponible, y haga, si el servicio esta disponible, que el oliente de servicios de aplioaoiones reoiba los datos de medios de una unidad que reoibe los datos de medios utilizando el servicio de la ubicacion de recursos, basandose en la informacion de asignacion.
En otro ejemplo, un procedimiento de procesamiento de datos de medios inoluye la recepcion de un mensaje del protocolo de descripcion de sesion (SDP) que inoluye un atributo que define una profundidad de la memoria intermedia desplazada en el tiempo (TSB), la determinacion de una oantidad de memoria para la TSB basandose en un valor del atributo, la asignacion de la oantidad de memoria determinada para formar la TSB, y el almacenamiento de al menos una parte de los datos de medios asociados con el mensaje SDP en la TSB.
En otro ejemplo, un dispositivo para el procesamiento de datos de medios inoluye uno o mas procesadores configurados para reoibir un mensaje del protocolo de descripcion de sesion (SDP) que inoluye un atributo que define una profundidad de la memoria intermedia desplazada en el tiempo (TSB), determinar una oantidad de memoria para la TSB basandose en un valor del atributo, asignar la oantidad de memoria determinada para formar la TSB, y almaoenar al menos una parte de los datos de medios asociados con el mensaje SDP en la TSB.
En otro ejemplo, un dispositivo para el procesamiento de datos de medios inoluye medios para reoibir un mensaje
5
10
15
20
25
30
35
40
45
50
55
60
65
del protocolo de descripcion de sesion (SDP) que incluye un atributo que define una profundidad de la memoria Intermedia desplazada en el tiempo (TSB), medios para determinar una cantidad de memoria para la TSB basandose en un valor del atributo, medios para asignar la cantidad de memoria determinada para formar la TSB, y medios para almacenar al menos una parte de los datos de medios asociados con el mensaje SDP en la TSB.
En otro ejemplo, un medio de almacenamiento legible por ordenador tiene almacenado en el mismo instrucciones que, cuando se ejecutan, hacen que un procesador reciba un mensaje del protocolo de descripcion de sesion (SDP) que incluye un atributo que define una profundidad de la memoria intermedia desplazada en el tiempo (TSB), determine una cantidad de memoria para la TSB basandose en un valor del atributo, asigne la cantidad de memoria determinada para formar la TSB, y almacene al menos una parte de los datos de medios asociados con el mensaje SDP en la TSB.
BREVE DESCRIPCION DE LOS DIBUJOS
La FIG. 1 ilustra un sistema de ejemplo para soportar a la diversidad de transportes.
Las FIG. 2A-2B ilustran ejemplos alternativos de aparatos que incluyen un redirector/proxy para soportar la diversidad de transportes.
La FIG. 3 ilustra aspectos de un flujo del proceso de ejemplo utilizando un redirector/proxy configurado para la operacion de redireccionamiento.
La FIG. 4 ilustra aspectos de un procedimiento que utiliza un redirector/proxy configurado para la operacion de proxy.
La FIG. 5 ilustra ejemplos de una metodologia para soportar la diversidad de transportes.
La FIG. 6 ilustra un aparato de ejemplo para implementar la metodologia de la FIG. 5.
Las FIG. 7 y 8 ilustran aspectos adicionales para soportar la diversidad de transportes.
Las FIG. 9 y 10 son diagramas de bloques que ilustran arquitecturas de clientes de dispositivos de servicios de multidifusion (MSDC) de ejemplo para soportar la transmision continua del Protocolo de transporte en tiempo real (RTP)/Protocolo de transmision continua en tiempo real (RTSP).
La FIG. 11 es un diagrama conceptual que ilustra un ejemplo de un fragmento del esquema de descripcion de servicios de usuario (USD) de MbMs evolucionado (eMBMS).
Las FIG. 12 y 13 son diagramas de bloques que ilustran componentes de ejemplo para soportar la diversidad de transportes para un cliente RT-SP/RTP.
Las FIG. 14A y 14B son diagramas conceptuales que ilustran un modelo de contenido del Lenguaje de marcas extensible (XML) de ejemplo para extender una USD para llevar la informacion de transporte de la Transmision continua dinamica adaptativa sobre HTTP (DASH).
La FIG. 15 es un diagrama conceptual que ilustra una arquitectura de ejemplo para soportar DASH sobre MBMS.
La FIG. 16 es un diagrama de flujo que ilustra un flujo de llamada asociado con la arquitectura de red de la FIG. 15 para la entrega de contenido DASH sobre un transporte de difusion y unidifusion.
La FIG. 17 es un diagrama conceptual que ilustra otra arquitectura de ejemplo para soportar DASH sobre MBMS.
Las FIG. 18-23 son diagramas de flujo que ilustran diversos ejemplos de flujos de llamada asociados con la arquitectura de red de la FIG. 17 para la entrega de contenido DASH sobre un transporte de difusion y unidifusion.
La FIG. 24 es un diagrama de flujo que ilustra un procedimiento de ejemplo para senalizar datos relacionados con una profundidad de la memoriza intermedia desplazada en el tiempo (TSB) de acuerdo con las tecnicas de la presente divulgacion.
DESCRIPCION DETALLADA
En general, la presente divulgacion describe tecnicas para soportar varios tipos de mecanismos de transporte para la transmision continua de datos de medios, tales como datos de audio y/o video, a traves de una red. Por ejemplo, un cliente de servicios de aplicaciones (que tambien se puede denominar como un cliente de transmision continua) puede estar configurado para interactuar con una unidad de proxy con el fin de recuperar datos de medios de
5
10
15
20
25
30
35
40
45
50
55
60
65
acuerdo con un protocolo de unidifusion o un protooolo de difusion (o mulfidifusion). En algunos ejemplos, la unidad de proxy puede determinar si los datos de medios se pueden recuperar utilizando el protocolo de difusion, por ejemplo, basandose en si un dispositivo de cliente esta dentro de un area de cobertura de un proveedor de servicios para entregar datos multimedia utilizando el protocolo de difusion, y seleccionar el protocolo de unidifusion o el protocolo de difusion basandose en si el dispositivo de cliente esta dentro del area de cobertura. El dispositivo de cliente puede ejecutar el cliente de servicios de aplicaciones y/o incluir la unidad de proxy. En algunos ejemplos, el dispositivo de cliente puede ejecutar el cliente de servicios de aplicaciones, y la unidad de proxy puede estar incluida en un dispositivo independiente del dispositivo de cliente.
Las tecnicas de la presente divulgacion se pueden utilizar junto con varios protocolos de la capa de aplicacion para la transmision continua de datos de medios. Por ejemplo, las tecnicas de la presente divulgacion se pueden utilizar junto con la Transmision continua dinamica adaptativa sobre HTTP (DASH), que utiliza HTTP para la transmision continua de los datos de medios. Como otro ejemplo, las tecnicas de la presente divulgacion se pueden utilizar junto con el Protocolo de transporte en tiempo real (RTP) o el Protocolo de transmision continua en tiempo real (RTSP). En estos y otros casos, un cliente de servicios de aplicaciones (por ejemplo, un cliente RTP, un cliente RTSP o un cliente DASH) puede no tener preferencias en cuanto al transporte, en el sentido de que el cliente de servicios de aplicaciones no necesita conocer un mecanismo de transporte utilizado para recuperar los datos de medios. Por ejemplo, el cliente de servicios de aplicaciones no necesita saber si un mecanismo de transporte subyacente corresponde a un protocolo de unidifusion o a un protocolo de difusion o mulfidifusion.
Como se analiza en mayor detalle a continuacion, la unidad de proxy (que tambien se puede denominar como una unidad de redirector/proxy) puede estar configurada para recibir una peticion de un cliente de servicios de aplicaciones, en la que la peticion especifica ciertos datos de medios. La unidad de proxy puede determinar si los datos de medios se pueden recuperar utilizando un mecanismo de transporte particular, por ejemplo, un protocolo de difusion o un protocolo de unidifusion. La unidad de proxy puede hacer entonces que el cliente de servicios de aplicaciones reciba los datos de medios usando uno de los mecanismos de transporte (basandose en la disponibilidad, preferencia, fiabilidad y/u otros factores). Por ejemplo, si el protocolo de difusion es mas preferente que el protocolo de unidifusion, y el protocolo de difusion esta disponible, la unidad de proxy puede hacer que el cliente de servicios de aplicaciones reciba los datos de medios a traves del protocolo de difusion, mientras que si el protocolo de difusion no esta disponible, la unidad de proxy puede hacer que el cliente de servicios de aplicaciones reciba los datos de medios a traves del protocolo de unidifusion.
Como un ejemplo, con respecto a DASH, los datos de medios pueden estar disponibles en uno o mas servidores, por ejemplo, un servidor de difusion y un servidor de unidifusion, como un servicio de difusion y/o unidifusion. Un cliente DASH puede recibir una Descripcion de presentacion de medios (MPD) modificada para los datos de medios que indica que los datos de medios estan disponibles en una unidad de proxy (en lugar del servidor o servidores). Cuando el cliente DASH envia una peticion para datos de medios a la unidad de proxy, la unidad de proxy puede determinar si esta disponible un protocolo de unidifusion o un protocolo de difusion para recuperar los datos de medios solicitados. Si el protocolo de difusion esta disponible, una unidad de recepcion de difusion (por ejemplo, una unidad de soporte intermedio de los Servicios de difusion/multidifusion multimedia (MBMS) o MBMS evolucionado (eMBMS)) puede recibir los datos de medios, y la unidad de proxy puede hacer que el cliente DASH envie una peticion para los datos de medios a la unidad de recepcion de difusion. Por otro lado, si el protocolo de difusion no esta disponible, la unidad de proxy puede hacer que el cliente DASH envie una peticion para los datos de medios a un servidor de unidifusion, para recuperar los datos de medios usando unidifusion. Alternativamente, la unidad de proxy puede recuperar los datos de medios del servidor de unidifusion, y a continuacion proporcionar los datos de medios recuperados al cliente DASH. En algunos ejemplos, el servidor de unidifusion y el servidor de difusion pueden corresponder al mismo servidor.
Como otro ejemplo, con respecto a RTP o RTSP, un cliente RTP (que, alternativamente, puede corresponder a un cliente RTSP) puede enviar comandos DESCRlBlR, ESTABLECeR y REPRODUCIR a una unidad de proxy. En respuesta al comando DESCRlBlR, la unidad de proxy puede proporcionar un mensaje del Protocolo de descripcion de sesion (SDP) modificado al cliente RTP. El mensaje SDP modificado puede especificar una direccion de la unidad de proxy como la direccion en la que estan disponibles los datos de medios. Este mensaje SDP modificado puede hacer que el cliente RTP envie comandos ESTABLECER y REPRODUCIR a la unidad de proxy. Cuando la unidad de proxy determina que el protocolo de difusion esta disponible, la unidad de proxy puede enviar comandos ESTABLECER y REPRODUCIR a una unidad de recepcion de difusion (por ejemplo, una unidad de soporfe intermedio MBMS o eMBMS), que puede recibir los datos de medios y reenviar los datos de medios al cliente RTP. Por otro lado, cuando la unidad de proxy determina que el protocolo de difusion no esta disponible, la unidad de proxy puede recuperar los datos de medios de un servidor de unidifusion y, a continuacion, proporcionar los datos de medios recuperados al cliente RTP.
En algunos ejemplos, los componentes para llevar a cabo las tecnicas de la presente divulgacion pueden incluir un cliente de servicios de aplicaciones, una unidad de proxy y una unidad de recepcion de difusion. En varios ejemplos, un dispositivo de cliente puede incluir algunos o todos estos componentes, solos o en cualquier combinacion. Alternativamente, el dispositivo de cliente puede incluir el cliente de servicios de aplicaciones, y la unidad de proxy y/o la unidad de recepcion de difusion pueden estar incluidas en uno o mas dispositivos que son independientes del
5
10
15
20
25
30
35
40
45
50
55
60
65
dispositivo de oliente.
Ademas, la presente divulgaoion tambien describe las teonioas relaoionadas oon la senalizaoion de datos para una memoria intermedia desplazada en el tiempo (TSB). Un dispositivo de oliente (tambien denominado aqui oomo "equipo de usuario") puede asignar memoria para formar una TSB a utilizar para el almaoenamiento de datos de medios oomo apoyo a diversos modos avanzados de reproduooion, tales oomo el avanoe rapido, el rebobinado, la repetioion o similares. En general, un modo avanzado de reproduooion se puede referir a un modo de reproduooion en el que los datos de medios se reproduoen en un orden o a una velooidad distinta al orden de salida definido. Por ejemplo, en el avanoe rapido, se pueden omitir determinados datos de medios. Como otro ejemplo, en el rebobinado, se puede invertir un orden de salida para los datos de medios, y tambien se pueden omitir determinados datos de medios. Para omitir datos de medios, por ejemplo, oon respeoto a los datos de video, solo se podrian mostrar imagenes oodifioadas utilizando un modo de intra-oodifioaoion, omitiendo las imagenes inter-oodifioadas.
De aouerdo oon las teonioas de la presente divulgaoion, los datos se pueden senalizar en, por ejemplo, un mensaje SDP, para instanoiar una TSB. Por ejemplo, se puede senalizar un atributo de una TSB, oon un valor que define, en segundos, una oantidad de datos de medios que se pueden almaoenar en la TSB. Un dispositivo de oliente puede oaloular una oantidad de memoria neoesaria para la TSB basandose en el valor del atributo de la TSB. Este oaloulo puede implioar, para datos de video oomo un ejemplo, una velooidad de tramas de los datos de video en los datos de medios. El dispositivo de oliente puede oaloular un tamano de memoria para la TSB basandose en una oantidad media de datos por imagen, un numero de imagenes en un periodo de tiempo (basandose en la velooidad de tramas), y una duraoion temporal definida por el atributo de la TSB. Del mismo modo, el dispositivo de oliente puede determinar ademas una oantidad de memoria neoesaria para datos de audio, datos de texto, u otros datos o medios para el periodo de tiempo. Por lo tanto, el dispositivo de oliente puede asignar estos datos a la TSB para el almaoenamiento de datos de medios oon el fin de llevar a oabo los modos avanzados de reproduooion. Ademas, el dispositivo de oliente puede llevar a oabo modos avanzados de reproduooion para los datos reoibidos a traves de un protooolo de difusion, tal oomo MBMS o eMBMS.
En otras palabras, en algunos ejemplos, las teonioas de la presente divulgaoion inoluyen una arquiteotura de soporte intermedio para soportar las oaraoteristioas de la transmision oontinua del Protooolo de tiempo real/Protooolo de transmision oontinua en tiempo real (RTP/RTSP) sobre la red del Servioio de difusion/multidifusion multimedia evoluoionado (eMBMS). Estas oaraoteristioas inoluyen una memoria intermedia desplazada en el tiempo y la diversidad de transportes (por ejemplo, la oonmutaoion de unidifusion a difusion o vioeversa para la entrega de oontenido). Para la oaraoteristioa de la memoria intermedia desplazada en el tiempo (TSB), la arquiteotura puede soportar extensiones del Protooolo de desoripoion de sesion (SDP) que inoluyan datos que senalioen una profundidad de la memoria intermedia. Como un ejemplo de la oaraoteristioa de la diversidad de transportes, la presente divulgaoion propone una arquiteotura en la que las aplioaoiones que oonsumen el oontenido no neoesitan oonooer los detalles de la oonmutaoion de transporte de unidifusion a difusion o vioeversa, ya que esta oonmutaoion se puede gestionar en el nivel del soporte intermedio.
En la transmision oontinua HTTP, las operaoiones de uso freouente inoluyen OBTENER y OBTENER paroial. La operaoion OBTENER solioita la reouperaoion de un arohivo oompleto asooiado oon un identifioador uniforme de reoursos (URi) determinado (por ejemplo, URL o URN). La operaoion OBTENER paroial solioita la reouperaoion de un intervalo de bytes (suboonjunto) de un reourso. Por lo tanto, se pueden proporoionar fragmentos de pelioulas para la transmision oontinua HTTP, debido a que una operaoion OBTENER u OBTENER paroial puede reouperar uno o mas fragmentos de pelioulas individuales. En un fragmento de pelioula, puede haber varios fragmentos de pista de diferentes pistas. En la transmision oontinua HTTP, una presentaoion de medios puede ser una reoopilaoion de datos estruoturada que esta aooesible para el oliente. El oliente puede solioitar y desoargar la informaoion de datos de medios para presentar un servioio de transmision oontinua a un usuario.
En el ejemplo de la transmision oontinua de datos DASH utilizando HTTP, puede haber multiples representaoiones de los datos de video y/o audio del oontenido multimedia. El manifiesto de diohas representaoiones se puede definir en una estruotura de datos de Desoripoion de presentaoion de medios (MPD). Una presentaoion de medios puede oorresponder a una reoopilaoion de datos estruoturada que es aooesible para un dispositivo de oliente de transmision oontinua HTTP. El dispositivo de oliente de transmision oontinua HTTP puede solioitar y desoargar la informaoion de datos de medios para presentar un servioio de transmision oontinua a un usuario del dispositivo de oliente. Una presentaoion de medios se puede desoribir en la estruotura de datos MPD, que puede inoluir aotualizaoiones dinamioas de la MPD.
Una representaoion de medios puede oontener una seouenoia de uno o mas periodos. Los periodos se pueden definir mediante un elemento de periodo en la MPD. Cada periodo puede tener un atributo de inioio en la MPD. La MPD puede inoluir un atributo de inioio y un atributo InstantelnicioDisponibilidad para oada periodo. Para servioios direotos, la suma del atributo inicio del periodo y el atributo InstantelnicioDisponibilidad puede espeoifioar el tiempo de disponibilidad del periodo en formato UTC, en particular, el primer segmento de medios de oada representaoion en el periodo oorrespondiente. Para servioios bajo demanda, el atributo de inioio del primer periodo puede ser 0. Para oualquier otro periodo, el atributo de inioio puede espeoifioar un desplazamiento temporal entre el instante de inioio del periodo oorrespondiente oon respeoto al instante de inioio del primer periodo. Cada periodo puede
5
10
15
20
25
30
35
40
45
50
55
60
65
extenderse hasta el inicio del slgulente periodo, o hasta el final de la presentacion de medlos en el caso del ultimo periodo. Los instantes de inicio del periodo pueden ser precisos. Pueden reflejar la temporizacion real resultante de la reproduccion de los medios de todos los periodos anteriores.
Cada periodo puede contener una o mas representaciones para el mismo contenido de medios. Una representacion puede ser una de varias versiones codificadas alternativas de audio, video u otros datos. Las representaciones pueden variar segun el tipo de codificacion, por ejemplo, segun la tasa de bits, la resolucion y/o el codec para los datos de video y la tasa de bits, el lenguaje y/o el codec para los datos de audio. El termino representacion se puede utilizar para referirse a una seccion de datos de audio o video codificados u otros medios o datos correspondientes a un periodo particular del contenido multimedia y codificados de una manera particular.
Las representaciones de un periodo particular se pueden asignar a un grupo indicado por un atributo grupo en la MPD. Las representaciones en el mismo grupo en general se consideran alternativas entre si. Por ejemplo, cada representacion de los datos de video para un periodo determinado se puede asignar a un mismo grupo, de tal manera que se puede seleccionar cualquiera de las representaciones para la descodificacion con el fin de visualizar datos de video del contenido multimedia para el periodo correspondiente. El contenido de medios dentro de un periodo se puede representar mediante una representacion del grupo 0, si esta presente, o la combinacion de al menos una representacion de cada grupo distinto de cero, en algunos ejemplos. Los datos de temporizacion para cada representacion de un periodo pueden expresarse con respecto al instante de inicio del periodo.
Una representacion puede incluir uno o mas segmentos. Cada representacion puede incluir un segmento de inicializacion, o cada segmento de una representacion puede ser auto-inicializable. Cuando esta presente, el segmento de inicializacion puede contener informacion de inicializacion para acceder a la representacion. En general, el segmento de inicializacion no contiene datos de medios. Un segmento puede ser referenciado de forma unica utilizando un identificador, tal como un Identificador uniforme de recursos (URI) (por ejemplo, un Localizador uniforme de recursos (URL) o un Nombre uniforme de recursos (URN)). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD tambien puede proporcionar intervalos de bytes en forma de un atributo de intervalo, que puede corresponder a los datos para un intervalo continuo de bytes de un segmento dentro de un recurso (por ejemplo, un archivo) accesible referenciando el URI correspondiente.
Cada representacion tambien puede incluir uno o mas componentes de medios, donde cada componente de medios puede corresponder a una version codificada de un tipo de medios individual, tal como audio, video o texto temporizado (por ejemplo, para los subtitulos). Los componentes de medios pueden tener una continuidad temporal a traves de los limites de segmentos de medios consecutivos dentro de una representacion.
Las tecnicas descritas en el presente documento pueden usarse para las redes inalambricas y tecnologias de radio que se han mencionado anteriormente, asi como otras redes inalambricas y tecnologias de radio. Para mayor claridad, determinados aspectos de las tecnicas se describen a continuacion para LTE, utilizandose la terminologia de LTE en gran parte de la siguiente descripcion.
La transmision continua RTP/RTSP es un protocolo comun para soportar la transmision continua en tiempo real. La especificacion del 3GPP para los servicios eMBMS describe la arquitectura de la transmision continua RTP sobre redes de Evolucion a largo plazo (LTE). Sin embargo, la presente divulgacion, reconoce dos problemas con RTP/RTSP, y analiza tecnicas que se pueden utilizar para superar estos problemas.
La memoria intermedia desplazada en tiempo (TSB) es una caracteristica que se puede usar para almacenar una parte del contenido de medios en el Equipo de usuario (UE). La memoria intermedia permite a los usuarios mover el punto de reproduccion del contenido de medios hacia adelante o hacia atras. En este proceso, el UE necesita haber sido informado de la profundidad de la memoria intermedia, que proporciona una indicacion de cuanto tiempo se debe acumular el contenido del UE en el dispositivo para permitir la reproduccion en un modo avanzado de reproduccion, por ejemplo, el avance rapido y el rebobinado de la reproduccion. En una implementacion de un reproductor multimedia VLC, la caracteristica de la TSB se activa proporcionando la profundidad de la memoria intermedia como un argumento para el reproductor VLC en el establecimiento. El proceso no es automatico, y en cambio requiere la intervencion de un usuario que proporcione el argumento de profundidad de la memoria intermedia y active la TSB consecuentemente. La presente divulgacion describe tecnicas para soportar una TSB en una capa de soporte intermedio con eMBMS activo, tal como un Cliente de dispositivos de servicios de multidifusion (MSDC).
El Protocolo de descripcion de sesion (SDP) describe la informacion del punto final de un servicio de transmision continua y sus parametros relacionados de (sesion de) flujos de medios, conocidos colectivamente como "perfil de sesion." Por lo tanto, si un servicio de transmision continua esta disponible en diferentes procedimientos de transporte, se necesitan varios perfiles que describen diferentes parametros de transporte/punto final para el servicio. Por ejemplo, un servicio de difusion en tiempo real basado en RTP puede referirse a una direccion IP de multidifusion y un puerto para sus flujos de medios, mientras que la version de unidifusion del servicio puede referirse a una direccion IP de unidifusion y el puerto. Puede haber diferentes representaciones de los flujos de medios para los procedimientos de entrega de difusion y unidifusion. En redes LTE, el MSDC proporciona la entrega
5
10
15
20
25
30
35
40
45
50
55
60
65
de servicios de transmision oontinua a aplioaoiones con eMBMS aotivo. Para soportar la oonmutadon entre la unidifusion y otros (por ejemplo, difusion o multidifusion) prooedimientos de transporte, es neoesario utilizar multiples perfiles de sesion, la eleodon de los ouales se basara prinoipalmente en si un UE esta fuera de oobertura o dentro de la oobertura de difusion. Cada vez que un UE se mueve a un area de oobertura de difusion, el MSDC puede utilizar la version de difusion aotiva del perfil SDP para estableoer una oonexion y oonsumir el oontenido. Sin embargo, en el esoenario inverso, ouando un UE se mueve fuera de la oobertura de difusion, el MSDC puede neoesitar utilizar el SDP de unidifusion y estableoer una oonexion de unidifusion oon el servidor RTSP remoto para oonsumir el oontenido de unidifusion. Para mantener las transioiones entre la unidifusion y la difusion ooultas a los usuarios o aplioaoiones, la presente divulgaoion desoribe un meoanismo de transioion transparente.
La presente divulgaoion desoribe, entre otras teonioas, teonioas relaoionadas oon el soporte de la TSB y teonioas para soportar la oonmutaoion de transportes, que se pueden utilizar solas, en oonjunto y/o en oualquier oombinaoion oon otras teonioas desoritas en la presente divulgaoion. Para habilitar la oaraoteristioa de la TSB en la transmision oontinua basada en RTP sobre eMBMS, la presente divulgaoion desoribe teonioas para usar la extension del meoanismo SDP para senalizar el valor de la profundidad de la memoria intermedia desplazada en el tiempo. Para el problema de la oonmutaoion de transportes, la presente divulgaoion desoribe una soluoion unifioada para una desoripoion SDP que inoluye tanto desoripoiones de unidifusion oomo de difusion. Ademas, oon el fin de haoer que las transioiones entre difusion y unidifusion sean transparentes a las aplioaoiones/usuarios, la presente divulgaoion desoribe una soluoion basada en soporte intermedio donde el soporte intermedio gestiona el redireodonamiento del oontenido utilizando SDP unifioado, ooultando el prooeso a los usuarios.
De aouerdo oon aspeotos de la materia objeto de la presente divulgaoion, se proporoionan prooedimientos, aparatos, y una arquiteotura para el despliegue en un dispositivo de oliente o en un oonjunto de dispositivos, para proporoionar una oapa de abstraodon en la que se pueden emplear varios tipos diferentes de meoanismos/protooolos de transporte (por ejemplo, eMBMS, difusion de video digital (DVB), eto.) para, por ejemplo, entregar metadatos y oontenido digital a las aplioaoiones de un oliente. Las aplioaoiones no tienen que oonooer los detalles de oada transporte individual. La divulgaoion puede inoluir la opoion de un oonjunto oonfigurable de politioas que se pueden utilizar para determinar la eleodon, la ubioaoion o la temporizaoion de disponibilidad de los datos y metadatos que se entregan a las aplioaoiones.
Las aplioaoiones que aooeden a oontenido web en Internet pueden identifioar el oontenido (o sus partes oonstituyentes) usando un Identifioador de reoursos universal (URI), que puede ser un Looalizador de reoursos universal (URL) que utiliza esquemas HTTP o HTTP seguro (HTTPS). Por ejemplo, en el oontexto de MPEG-DASH, las referenoias a URL que oontienen los esquemas HTTP o HTTPS pueden resolverse usando los protooolos HTTP o HTTPS. Ademas, se puede utilizar HTTP para obtener los datos referenoiados por los URL. La norma DASH puede utilizar URL que no sean HTTP, y la divulgaoion puede referirse a oasos en los que petioiones arbitrarias (inoluyendo petioiones basadas en HTTP) de olientes se gestionan de una manera flexible que proporoiona una opoion para haoer que las petioiones se dirijan a una ubioaoion diferente, en un instante diferente, y/o indiquen al oliente solioitante que aooeda a oontenido alternativo.
Las teonioas de la presente divulgaoion pueden implioar la oreadon de instanoias de una funoion de redireotor que gestiona las petioiones de oontenido del oliente. El redireotor (tambien denominado en este dooumento oomo un redireotor/proxy) puede ser oapaz de aplioar el prooesamiento al material identifioado en una petioion de oliente, invooar un prooedimiento o algoritmo para oomparar el resultado de este prooesamiento oon una tabla de oriterios de ooinoidenda, e indioar al oliente una ubioaoion, un prooedimiento de aooeso, una informaoion de temporizaoion, o un oontenido alternativos (por ejemplo, en un arohivo) de tal manera que el oliente pueda saber donde realizar una petioion posterior. En otro aspeoto, el redireotor puede realizar la petioion de oontenido en nombre del oliente y obtener el oontenido solioitado. En este oaso, el redireotor puede aotuar oomo una funoion de proxy o una funoion reoursiva.
La FIG. 1 es un diagrama de bloques que ilustra un sistema de ejemplo 100 para soportar a la diversidad de transportes. El sistema de ejemplo 100 puede inoluir una aplioaoion 101, por ejemplo, de un dispositivo movil. La aplioaoion 101 puede realizar una petioion de oontenido. Por ejemplo, una aplioaoion de reproduooion multimedia DASH prooesa un manifiesto o MPD, y determina los URL que oontienen metadatos y datos, y envia petioiones HTTP. La petioion de oontenido puede utilizar un puerto de protooolo predeterminado, preoonfigurado o determinado dinamioamente (por ejemplo, oon TCP o UDP), tal oomo un protooolo que normalmente se utilizaria para oonfigurar una funoion "proxy" de un navegador web. La determinaoion del puerto de protooolo puede inoluir el uso de un arohivo de oonfiguradon, por ejemplo, estableoido por un usuario o un administrador de la red/sistema tal oomo en un Arohivo de autooonfiguradon de proxy (PAC), o a traves del protooolo tal oomo mediante el Protooolo de deteodon automatioa de proxy web (WPAD).
Un redireotor/proxy 104 puede reoibir la petioion de la aplioaoion 101 a traves de un oliente de servioios de aplioaoiones 102 y prooesar o analizar la petioion para determinar el oontenido solioitado. El redireotor/proxy 104 puede oomparar el resultado oon una tabla (u otro tipo apropiado de estruotura de datos) que oontiene los oriterios de ooinoidenda para determinar si se ha produoido una ooinoidenda. Si se produoe una ooinoidenda, el redireotor/proxy 104 puede determinar un destino del redireodonamiento. El destino se puede entregar a la
5
10
15
20
25
30
35
40
45
50
55
60
65
aplioaoion 101. En otro aspeoto, el redireotor/proxy 104 puede aotuar de una manera recursiva y la aplioaoion 101 puede no neoesitar prooesar el destino del redireooionamiento. Por ejemplo, el redireotor/proxy 104 puede obtener el oontenido basandose en el destino del redireooionamiento en nombre de la aplioaoion 101.
El redireotor/proxy 104 puede estar oo-ubioado oon la aplioaoion 101 en el mismo dispositivo, o el redireotor/proxy 104 puede estar ubioado en un dispositivo independiente. En el oaso de un redireotor/proxy 104 oo-ubioado, la aplioaoion 101 puede oomunioarse oon el redireotor/proxy 104 a traves de HTTP, la Interfaz de programaoion de aplioaoiones (API), la Comunioaoion entre prooesos (IPC), eto. En oaso de que el redireotor/proxy 104 este ubioado en un dispositivo independiente, la aplioaoion 101 puede oomunioarse oon el redireotor (mediante el oliente de servioios de aplioaoiones 102) a traves de HTTP, eto.
Despues de la determinaoion de una "ooinoidenoia" (o no ooinoidenoia), se puede proporoionar un destino del redireooionamiento a la aplioaoion 101. El destino puede indioar objeto(s) de oontenido alternativo(s) para aooeder en lugar de objeto(s) de oontenido solioitado(s) por la aplioaoion 101. Puede haber varios prooedimientos mediante los ouales se puede indioar el destino del redireooionamiento a la aplioaoion 101.
La senalizaoion entre los oomponentes del sistema 100 se puede realizar usando una API o IPC. Este este aspeoto, el meoanismo de la API o la IPC se puede utilizar para proporoionar una oomunioaoion entre el redireotor/proxy 104 y la aplioaoion 101. En oaso de usar la API, el redireotor/proxy 104 puede invooar metodos o prooedimientos implementados en la aplioaoion 101 o la biblioteoa de aplioaoiones para indioar el destino del redireooionamiento.
La senalizaoion entre los oomponentes del sistema 100 se puede realizar a traves de la re-esoritura de metadatos. En este aspeoto, los metadatos (por ejemplo, una MPD DASH) se pueden re-esoribir para indioar referenoias alternativas para los objetos. Por ejemplo, un URI presente en los metadatos originales se puede re-esoribir para formar un URI alternativo para aooeder a oontenido equivalente o sustituto.
La senalizaoion entre los oomponentes del sistema 100 se puede realizar usando las indioaoiones en un protooolo de oomunioaoion. En este aspeoto, se puede utilizar un protooolo de oomunioaoiones de la oapa de aplioaoion (por ejemplo, HTTP) de tal manera que oomunique informaoion de senalizaoion a la aplioaoion 101. En una variante, se puede utilizar la oategoria de oodigos de respuesta HTTP de "re-direooionamiento" (por ejemplo, puede oorresponder a oodigos de la forma 3xx, donde x puede ser un numero del oero al nueve). En un sub-oaso de esta variante, por ejemplo, se puede utilizar el oodigo 300 (que indioa multiples opoiones disponibles), en el que el redireotor/proxy 104 proporoiona un veotor de referenoias (por ejemplo, URI) a partir del oual una aplioaoion 101 puede seleooionar una o mas a utilizar.
La funoion de ooinoidenoia puede obtener el resultado de la oomparaoion de las referenoias a objetos originadas en la aplioaoion 101 (por ejemplo, un URI de petioion) oon referenoias a objetos presentes en una estruotura de datos (por ejemplo, un arohivo, una base de datos, una tabla de ooinoidenoias, eto.).
A modo de ejemplos no limitativos, en un aspeoto, los oriterios de ooinoidenoia se pueden expresar oomo prefijos de URI, y la oourrenoia de una ooinoidenoia preferente unioa se indioa mediante la ooinoidenoia oon el prefijo mas largo (por ejemplo, determinado por el numero de bits o bytes en oomun). En otro aspeoto, a oada ooinoidenoia potenoial se le puede asignar un numero de prioridad oorrespondiente, y se puede seleooionar la entrada oon el mayor (o menor) numero de prioridad.
En otro aspeoto, los oriterios de ooinoidenoia pueden expresarse oomo expresiones regulares, y la ooinoidenoia preferente puede determinarse utilizando el mayor numero de oaraoteres ooinoidentes. En otra variaoion, se pueden utilizar expresiones regulares para expresar los oriterios de ooinoidenoia y se puede seleooionar la ooinoidenoia potenoial oon el mayor (o menor) numero de prioridad.
El algoritmo de ooinoidenoia o los oontenidos de la estruotura de datos analizados anteriormente pueden estar basados en politioas que pueden estar pre-determinadas o pre-oonfiguradas. En otro aspeoto, las politioas se pueden anadir o borrar dinamioamente de una base de datos de politioas logioa. La base de datos de politioas se puede implementar usando diversas estruoturas de datos y no se limita a ningun tipo partioular de estruotura de datos o implementaoion de la base de datos.
Las politioas se pueden usarpara determinar el funoionamiento del algoritmo de ooinoidenoia de varias maneras, inoluyendo, por ejemplo, la priorizaoion o la despriorizaoion de los oriterios de ooinoidenoia de un origen sobre otro(s) (por ejemplo, se puede favoreoer/desfavoreoer un tipo de transporte); la eliminaoion de los oriterios de ooinoidenoia oomo una funoion del origen, el tiempo, el destino del redireooionamiento y/o el valor de los oriterios de ooinoidenoia; la adioion de oriterios de ooinoidenoia oomo una funoion del origen o el tiempo o el destino del redireooionamiento o el valor de los oriterios de ooinoidenoia; y/o la modifioaoion de los oriterios de ooinoidenoia oomo una funoion del origen o el tiempo o el destino del redireooionamiento o el valor de los oriterios de ooinoidenoia.
El sistema de ejemplo 100 puede inoluir un soporte intermedio de transporte 110 para solioitar oontenido basandose en la ubioaoion redireooionada. El soporte intermedio de transporte 110 puede inoluir varios meoanismos/protooolos
5
10
15
20
25
30
35
40
45
50
55
60
65
de transporte tales como un transporte A 110A a un transporte R 110R. Cada mecanismo de transporte (transporte A 110A a transporte R 110R) puede tener un modulo correspondiente capaz de obtener una lista y los detalles de la informacion del archivo y producir, por ejemplo, un URI sintetizado o un prefijo de URI comun. Estos modulos pueden transportar esta informacion a traves de un mecanismo de comunicacion (por ejemplo, IPC, API o protocolo) al controlador 106 que puede aplicar la politica y la resolucion, y que puede a su vez programar el redirector/proxy 104 sujeto a la politica. Los mecanismos de transporte (transporte A 110A a transporte R 110R) pueden incluir, por ejemplo, eMBMS, DVB-T2, DVB-S, otras tecnologias de difusion de la familia DVB, o similares. Cada soporte intermedio de transporte puede incluir una memoria cache para almacenar el contenido u otros datos. Por ejemplo, el soporte intermedio de transporte puede almacenar en cache un segmento de inicio del contenido para que la entrega de contenido a la aplicacion 101 pueda parecer instantanea al usuario. El soporte intermedio de transporte 110 puede solicitar el contenido de un origen tal como un servidor de contenido 120. Adicional o alternativamente, el cliente puede solicitar el contenido a traves de una red, incluyendo Internet 122. Para el redirector/proxy 104 configurado para el funcionamiento de proxy o "recursivo", el redirector/proxy 104 puede solicitar el contenido a traves del soporte intermedio de transporte 110 o a traves de una red o Internet 122. El redirector/proxy 104 puede estar pre-configurado para funcionar en un papel de redireccionamiento o de proxy. El papel del redirector/proxy 104 se puede determinar en tiempo de ejecucion, por ejemplo, basandose en un conjunto de reglas.
Las FIG. 2A-2B ilustran ejemplos alternativos de aparatos que incluyen un redirector/proxy 104 para soportar la diversidad de transportes. Algunos o la totalidad del redirector/proxy 104, el controlador 106 con la base de datos de politicas 108, o el soporte intermedio de transporte 110 pueden estar co-ubicados con la aplicacion 101 y el cliente en un dispositivo o pueden estar ubicados en dispositivo(s) independiente(s). En el ejemplo de la FIG. 2A, el sistema 200A incluye el redirector/proxy 104A que se muestra co-ubicado con el cliente y la aplicacion 101 en un UE 101A. Por ejemplo, el cliente de servicios de aplicaciones 102A puede ser un cliente DASH, un cliente de Transmision continua directa HTTP (HLS), un cliente de Transmision continua directa Apple (ALS), un cliente de Transmision continua HTTP adaptativa (AHS), o cualquier otro cliente adecuado. El cliente de servicios de aplicaciones 102A puede comunicarse con el redirector/proxy 104A a traves de HTTP, API, IPC, o cualquier otro protocolo o manera apropiada. En el ejemplo de la FIG. 2B, el sistema 200B incluye el redirector/proxy 104B que se muestra ubicado en una entidad independiente 110 del cliente de servicios de aplicaciones 102B y la aplicacion 101 que estan ubicadas en un UE 101B. Por ejemplo, el cliente de servicios de aplicaciones 102B puede ser un cliente DASH, un cliente HLS (ALS), un cliente AHS, o cualquier otro cliente adecuado. El cliente de servicios de aplicaciones 102B puede comunicarse con el redirector/proxy 104B a traves de HTTP o cualquier otro protocolo o manera apropiada. El redirector/proxy 104B puede estar ubicado en cualquier entidad de red adecuada, tal como un servidor proxy, una pasarela, un encaminador, etc.
La FIG. 3 es un diagrama de flujo que ilustra aspectos de un flujo del proceso de ejemplo 320 utilizando un redirector/proxy configurado para la operacion de redireccionamiento. Antes del inicio del flujo del proceso 320, la base de datos de politicas 108 (acoplada al controlador 106) puede estar provista o pre-configurada con informacion de la politica para determinar las acciones del controlador 106. La base de datos de politicas 108 puede estar provista de la informacion en el instante de aprovisionamiento.
La aplicacion 101, que puede estar relacionada o no con la aplicacion 101 en la FIG. 1, puede ser una aplicacion de aprovisionamiento. La aplicacion 101 puede estar configurada para activar el soporte intermedio de transporte 110 (321), asi como para determinar el estado del soporte intermedio de transporte 110. La aplicacion 101 puede estar configurada para activar uno o mas mecanismos de transporte del soporte intermedio de transporte 110. La aplicacion 101 puede configurar inicialmente el cliente de servicios de aplicaciones 102 con informacion que identifica un punto final de proxy (por ejemplo, un nombre o direccion de anfitrion, un protocolo, o un numero de puerto del protocolo) en el establecimiento (322).
En este ejemplo, puede estar disponible mas de un transporte y pueden estar disponibles diversos contenidos sobre los distintos transportes en diferentes instantes. En particular, pueden estar disponibles varios servicios, donde cada uno de los diversos servicios pueden definir diferentes tipos de transportes respectivos, tales como la difusion, la multidifusion, la unidifusion, o similares, para el transporte de datos de medios. Por ejemplo, pueden estar disponibles el eMBMS y/o uno o mas de los transportes de la familia DVB. Ademas, el contenido de medios disponible (por ejemplo, archivos) puede expresarse utilizando, por ejemplo, una descripcion de los servicios de aplicaciones. Un ejemplo de una descripcion de los servicios de aplicaciones es un fragmento de metadatos de Descripcion de servicios de usuario (USD) MBMS, tal como un fragmento MPD en el caso de contenido DASH entregado como un servicio de usuario MBMS, en la descripcion de los diversos componentes de medios disponibles. Otro ejemplo de una descripcion de los servicios de aplicaciones es un archivo de manifiesto HLS (Transmision continua directa HTTP) Apple, en el caso de contenido HLS entregado como un servicio de usuario MBMS. Cada mecanismo de transporte puede tener un modulo correspondiente capaz de obtener la lista y los detalles de la informacion del archivo y producir un URI sintetizado o un prefijo de URI comun. Estos modulos pueden transmitir esta informacion a traves de un mecanismo de comunicacion (por ejemplo, IPC, API u otro protocolo) al controlador 106 que puede aplicar la politica y la resolucion, y que a su vez programa el redirector/proxy 104 sujeto a la politica.
El servidor de contenido 310 puede transmitir (por ejemplo, usando RAN LTE, DVB-T, etc.) una lista de servicios (por
5
10
15
20
25
30
35
40
45
50
55
60
65
ejemplo, USD, ESG), que puede ser recibida por el soporte intermedio de transporte 110. Un modulo adecuado (por ejemplo, uno del transporte A 110A al transporte R 110R) analiza la lista de servicios y procesa la informacion en una forma que no es especifica del transporte. El soporte intermedio de transporte 110 puede transmitir los resultados (por ejemplo, un identificador de un servicio y datos que definen una lista de archivos disponibles, tambien denominada como una lista disponibilidad de archivos) al controlador 106 (324). El controlador 106 puede procesar la lista de disponibilidad de archivos junto con la politica de acceso para producir un conjunto de asignaciones (325). Las asignaciones pueden incluir cuales URI (o prefijos de URI) deben re-direccionarse a que servidor (por ejemplo, los archivos disponibles sobre MBMS pueden estar disponibles en el servidor instanciado dentro de o asociado con el soporte intermedio MBMS).
Una vez que se invoca el cliente de servicios de aplicaciones 102, el cliente de servicios de aplicaciones 102 puede emitir una peticion (por ejemplo, una peticion HTTP) a traves de la direccion del proxy configurado para obtener, por ejemplo, los contenidos MPD (326). La peticion puede comunicarse al redirector/proxy 104. El redirector/proxy 104 puede realizar el algoritmo de coincidencia para determinar los criterios de coincidencia o, si no se produce una coincidencia, otro indicador (por ejemplo, un destino del redireccionamiento predeterminado, una indicacion de error, o una copia de la peticion original). El redirector/proxy 104 puede entonces proporcionar un destino del redireccionamiento o un error al cliente de servicios de aplicaciones 102, por ejemplo, usando HTTP (327A). El cliente de servicios de aplicaciones 102, despues de haber observado un codigo (por ejemplo, un codigo HTTP) que indica el redireccionamiento (por ejemplo, un codigo de tipo 3xx) responde en funcion del tipo de codigo. Por ejemplo, los tipos de codigos distintos de 300 incluyen una cabecera HTTP "Ubicacion;" que puede indicar la ubicacion alternativa para un recurso. Tras recibir dicha indicacion, el cliente de servicios de aplicaciones 102 puede volver a intentar su peticion utilizando la ubicacion alternativa indicada. En este ejemplo, el redirector/proxy 104 indica que un URI particular se debe direccionar al servidor integrado en el soporte intermedio MBMS. Consecuentemente, el cliente de servicios de aplicaciones 102 puede enviar una peticion al soporte intermedio de transporte 110 para obtener, por ejemplo, la MPD (327B) en respuesta a dicho codigo de redireccionamiento.
Una vez que el cliente de servicios de aplicaciones 102 ha obtenido la informacion MPD, el cliente de servicios de aplicaciones 102 puede determinar a que segmentos de medios debe acceder (por ejemplo, a que "representacion" en el caso de MPEG-DASH) y enviar una peticion basada en HTTP (328) al redirector/proxy 104. Utilizando el mecanismo descrito anteriormente (por ejemplo, el tipo de transporte asociado con el servicio identificado por el ID del servicio), el redirector/proxy 104 puede proporcionar un destino del redireccionamiento (329) al cliente de servicios de aplicaciones 102. El destino puede ser un valor predeterminado, una copia de la peticion (que indica que el cliente de servicios de aplicaciones 102 debe gestionar la peticion), o una referenda a un servidor diferente. De este modo, los destinos sirven como las ubicaciones utilizadas por el cliente de servicios de aplicaciones 102 para obtener segmentos de medios. Es decir, suponiendo que el contenido esta disponible utilizando el servicio, el cliente de servicios de aplicaciones 102 puede enviar una peticion de contenido al soporte intermedio de transporte 110 (330A) y, en respuesta, el soporte intermedio de transporte 110 puede entregar el contenido al cliente de servicios de aplicaciones 102 (331A). Para el contenido disponible a traves de otros origenes (por ejemplo, cuando el servicio no esta disponible), el cliente de servicios de aplicaciones 102 puede obtener el contenido a traves de otros procedimientos (por ejemplo, de otros servidores, almacenamiento/cache o Internet). Por ejemplo, el cliente de servicios de aplicaciones 102 puede enviar una peticion de contenido al servidor de contenido 310 (330B) y, en respuesta, el servidor de contenido 310 puede entregar el contenido solicitado al cliente de servicios de aplicaciones 102 (331B).
En algunos casos, los URI solicitados desde el cliente de servicios de aplicaciones 102, en la etapa 326 o la etapa 328, pueden ser desconocidos para el redirector/proxy 104. En tales casos, se pueden generar errores (por ejemplo, el codigo HTTP 404) para indicar al cliente de servicios de aplicaciones 102 que puede intentar solicitar un segmento diferente o dejar de usar el redirector/proxy 104 (por ejemplo, utilizar una peticion de acceso directo a Internet en su lugar). Alternativamente, el redirector 104 puede utilizar una cabecera de ubicacion equivalente a la peticion entrante para sugerir un funcionamiento distinto de proxy. Otro aspecto puede implicar que el redirector/proxy 104 actue como un proxy o un proxy web, en cuyo caso se puede acceder a Internet o a otra red o memoria cache en nombre del cliente de servicios de aplicaciones 102, por ejemplo, como se ilustra a continuacion en el flujo del proceso de ejemplo 400 de la FIG. 4.
Para los codigos de error HTTP de tipo 300, el cliente de servicios de aplicaciones 102 se puede presentar con un vector de opciones que puede no estar presente en la cabecera "Ubicacion;". En este caso, el cliente de servicios de aplicaciones 102 puede elegir entre las multiples opciones proporcionadas y, dependiendo de las particularidades del formato de codificacion de medios, reinicializar su estado de descodificacion. El escenario puede surgir, por ejemplo, si se produce un redireccionamiento en medio de un escenario de reproduccion a una representacion codificada de una manera distinta de la que el cliente de servicios de aplicaciones 102 ha estado procesando hasta el momento.
Cualquiera que sea el proceso que utiliza el cliente de servicios de aplicaciones 102 para seleccionar su(s) proxima(s) peticion(es)/acceso(s) de medios, el cliente de servicios de aplicaciones 102 puede iniciar la(s) peticion(es)/acceso(s) basandose en la informacion de redireccionamiento. La(s) peticion(es)/acceso(s) posterior(es) pueden pasar a traves del redirector inicialmente, proporcionando la oportunidad para que el redirector intervenga y
5
10
15
20
25
30
35
40
45
50
55
60
65
modifique efioazmente la ubioaoion (y otras oaraoteristioas) a partir de la que se recuperan Ios segmentos (por ejemplo, metadatos y/o segmentos de medios almaoenados oomo arohivos).
La FIG. 4 es un diagrama de flujo que ilustra aspeotos de un flujo del prooeso de ejemplo 400 utilizando un redireotor/proxy oonfigurado para la operaoion de proxy. Antes del inioio del flujo del prooeso 400, la base de datos de politioas 108 (aooplada al oontrolador 106) puede estar provista o pre-oonfigurada oon informaoion de la politioa para determinar las aooiones del oontrolador 106. La base de datos de politioas 108 puede estar provista de la informaoion en el instante de aprovisionamiento.
La aplioaoion 101 puede ser una aplioaoion de aprovisionamiento. Aunque se ha desorito oon respeoto a la aplioaoion 101 de la FIG. 1, debe entenderse que la aplioaoion no neoesita ser la misma que la desorita oon respeoto a la FIG. 1. La aplioaoion 101 puede estar oonfigurada para aotivar el soporte intermedio de transporte 110 (401). La aplioaoion 101 puede estar oonfigurada para aotivar uno o mas meoanismos de transporte del soporte intermedio de transporte 110. El oliente de servioios de aplioaoiones 102 puede oonfigurarse inioialmente oon informaoion que identifioa un punto final del proxy (por ejemplo, un nombre o direooion de un anfitrion, un protooolo, o un numero de puerto de protooolo) en el estableoimiento mediante la aplioaoion 101 (402).
En este ejemplo, puede estar disponible mas de un meoanismo de transporte y pueden estar disponibles diversos medios sobre los distintos transportes en diferentes instantes. Los diversos tipos de transportes pueden definirse mediante los servioios respeotivos. Por ejemplo, pueden estar disponibles el eMBMS y/o uno o mas de los transportes de la familia DVB. Ademas, los arohivos de medios disponibles pueden expresarse utilizando, por ejemplo, el fragmento MPD de la USD eMBMS, y a traves de la Guia eleotronioa de servioios (ESG) DVB para el transporte DVB. Cada meoanismo de transporte, representado por el soporte intermedio de transporte 110, puede tener un modulo oorrespondiente oapaz de obtener una lista de servioios disponibles y detalles de la informaoion de los arohivos para produoir un URI sintetizado o un prefijo de URI oomun. Estos modulos pueden transmitir esta informaoion a traves de un meoanismo de oomunioaoion (por ejemplo, IPC, API u otro protooolo) al oontrolador 106 que puede aplioar la politioa y la resoluoion, y que a su vez programa el redireotor/proxy 104 sujeto a la politioa.
El servidor de oontenido 310 puede transmitir una lista de servioios (por ejemplo, USD, ESG) reoibida por el soporte intermedio de transporte 110 (403). Un modulo adeouado (por ejemplo, uno del transporte A 110A al transporte R 110R) analiza la lista de servioios y prooesa la informaoion en una forma que no es espeoifioa del transporte. El soporte intermedio de transporte 110 puede transmitir los resultados al oontrolador 106 (404). El oontrolador 106 puede prooesar la lista de disponibilidad de arohivos junto oon la politioa de aooeso para produoir un oonjunto de asignaoiones (405). Las asignaoiones pueden inoluir ouales URI (o prefijos de URI) deben re-direooionarse a que servidor instanoiado (por ejemplo, los arohivos o medios disponibles sobre MBMS pueden estar disponibles en el servidor instanoiado dentro de o asooiado oon el soporte intermedio MBMS).
Una vez que se invooa el oliente de servioios de aplioaoiones 102, el oliente de servioios de aplioaoiones 102 puede emitir una petioion (por ejemplo, una petioion HTTP) a traves de la direooion del proxy oonfigurado para obtener, por ejemplo, los oontenidos MPD (406). La petioion puede oomunioarse al redireotor/proxy 104. El redireotor/proxy 104 puede realizar el algoritmo de ooinoidenoia para determinar los oriterios de ooinoidenoia o, si no se produoe una ooinoidenoia, otro indioador (por ejemplo, un destino del redireooionamiento predeterminado, una indioaoion de error, o una oopia de la petioion original). En oaso de un error, el error se puede proporoionar al oliente de servioios de aplioaoiones 102. Si se produoe una ooinoidenoia, el redireotor/proxy 104 puede aotuar oomo un proxy y reouperar el oontenido en nombre del oliente de servioios de aplioaoiones 102. De este modo, los destinos sirven oomo las ubioaoiones utilizadas por el redireotor/proxy 104, que aotua oomo un proxy, para obtener segmentos de medios. Es deoir, el redireotor/proxy 104 puede enviar una petioion de oontenido al soporte intermedio de transporte 110 (407A), y el soporte intermedio de transporte puede entregar el oontenido al redireotor/proxy 104 (408A). Para el oontenido disponible a traves de otros origenes, el redireotor/proxy 104, que aotua oomo un proxy, puede obtener el oontenido a traves de otros servidores, a partir de almaoenamiento/arohivos o Internet. Es deoir, el redireotor/proxy 104 puede enviar una petioion de oontenido al servidor de oontenido 310 (407B), y el servidor de oontenido puede entregar el oontenido solioitado al redireotor/proxy 104 (408B).
La FIG. 5 es un diagrama de flujo que ilustra un prooedimiento de ejemplo para soportar la diversidad de transportes asooiada oon el oontenido multimedia para un oliente multimedia de una red de oomunioaoiones inalambrioa (WCN). El oliente multimedia puede ser, o puede inoluir, una entidad movil. El prooedimiento 500 puede inoluir la reoepoion de una petioion de oontenido, en 502. El prooedimiento 500 puede inoluir la determinaoion de si existe una ooinoidenoia para la petioion basandose en un oonjunto de reglas, en 504. El prooedimiento 500 puede inoluir, en respuesta a la determinaoion de si existe una ooinoidenoia, el envio de un redireooionamiento al oliente multimedia, en 506.
La FIG. 6 es un diagrama de bloques que ilustra un aparato de ejemplo 600 que se puede oonfigurar oomo un UE, una entidad de red, u otra entidad adeouada, o oomo un prooesador, un oomponente o un dispositivo similar para utilizarse en el UE, la entidad de red, u otra entidad adeouada, para soportar la diversidad de transportes asooiada oon el oontenido multimedia para un oliente multimedia de una red de oomunioaoiones inalambrioas (WCN). El aparato 600 puede inoluir bloques funoionales que pueden representar funoiones implementadas por un prooesador,
5
10
15
20
25
30
35
40
45
50
55
60
65
software, o una oombinaoion de Ios mismos (por ejemplo, firmware).
Como se ilustra, en un ejemplo, el aparato 600 puede inoluir un oomponente o modulo eleotrioo 602 que reoibe una petioion de oontenido. El aparato 600 puede inoluir un oomponente o modulo eleotrioo 604 para determinar si existe una ooinoidenoia para la petioion basandose en un oonjunto de reglas. El aparato 600 puede inoluir un oomponente o modulo eleotrioo 606 para enviar un redireooionamiento al oliente multimedia en respuesta a la determinaoion de si existe una ooinoidenoia.
En aspeotos relaoionados, el aparato 600 puede inoluir opoionalmente un oomponente de prooesador 610 que tiene al menos un prooesador, en oaso de que el aparato 600 este oonfigurado oomo una entidad de red. En tal oaso, el prooesador 610 puede oomunioarse operativamente oon los oomponentes 602-606 o oomponentes similares a traves de un bus 612 o un aooplamiento de oomunioaoion similar. El prooesador 610 puede efeotuar el inioio y la programaoion de los prooesos o funoiones realizadas por los oomponentes o modulos eleotrioos 602-606.
En otros aspeotos relaoionados, el aparato 600 puede inoluir un oomponente de interfaz de red 614 para la oomunioaoion oon otras entidades de red. El aparato 600 puede inoluir opoionalmente un oomponente para el almaoenamiento de informaoion, tal oomo, por ejemplo, un dispositivo/oomponente de memoria 616. El medio legible por ordenador o el oomponente de memoria 616 pueden estar aooplados operativamente a los otros oomponentes del aparato 600 a traves del bus 612 o similares. El oomponente de memoria 616 puede estar adaptado para almaoenar instruooiones y datos legibles por ordenador para realizar la aotividad de los oomponentes 602-606, y los suboomponentes de los mismos, o el prooesador 610. El oomponente de memoria 616 puede guardar instruooiones para ejeoutar funoiones asooiadas oon los oomponentes 602-606. Aunque se muestran de manera externa a la memoria 616, debe entenderse que los oomponentes 602-606 pueden existir en la memoria 616.
Las FIG. 7 y 8 son diagramas de bloques que ilustran aspeotos adioionales para soportar la diversidad de transportes. Los oomponentes de las FIG. 7 y/u 8 pueden oorresponder sustanoialmente a los oomponentes de la FIG. 1 desorita anteriormente. La FIG. 7, por ejemplo, ilustra la red 700, el oliente de servioios de aplioaoiones 702, la aplioaoion de medios 704, el redireotor/proxy HTTP 706, el oontrolador 708, el soporte intermedio 712 y el gestor de politioas 716. La aplioaoion de medios 704 generalmente es responsable de la seleooion del oontenido de medios (por ejemplo, en respuesta a una seleooion del usuario), y el oliente de servioios de aplioaoiones 702 esta oonfigurado para reouperar el oontenido de medios seleooionado y proporoionar el oontenido de medios reouperado a la aplioaoion de medios 704 para su reproduooion. El oliente de servioios de aplioaoiones 702 puede oomprender, por ejemplo, un oliente DASH oonfigurado para utilizar HTTP para la transmision oontinua de datos de medios.
Como se ha analizado anteriormente, oon respeoto a la FIG. 1, el oliente de servioios de aplioaoiones 702 puede reouperar datos de medios, direotamente de la red 700 o del soporte intermedio 712. Por ejemplo, ouando un servioio que soporta la difusion o la multidifusion esta disponible (por ejemplo, segun lo determinado por el oontrolador 708 y definido por las politioas almaoenadas por el gestor de politioas 716), el soporte intermedio 712 puede reoibir datos de medios y almaoenar los datos de medios reoibidos en la memoria cache 714. El oliente de servioios de aplioaoiones 702 puede enviar petioiones de datos de medios al redireotor/proxy HTTP 706. Cuando los datos de medios solioitados han sido reoibidos por el soporte intermedio 712, el redireotor/proxy HTTP 706 puede redirigir una petioion de datos de medios al soporte intermedio 712. De este modo, el oliente de servioios de aplioaoiones 702 puede enviar una petioion HTTP al soporte intermedio 712, que puede proporoionar los datos de medios al oliente de servioios de aplioaoiones 702. Por otro lado, si el soporte intermedio 712 no ha reoibido los datos de medios, el redireotor/proxy HTTP 706 puede redireooionar el oliente de servioios de aplioaoiones 702 a una ubioaoion de red de un servidor en el que los datos de medios estan disponibles, donde el servidor puede estar disponible a traves de la red 700.
La FIG. 8, oomo otro ejemplo, ilustra el oliente DASH 802, la aplioaoion de reproduooion 804, el redireotor/proxy HTTP 818, el oontrolador 814, el MSDC 808, la unidad de transmision MBMS 820 y la base de datos de politioas 816. Estos oomponentes pueden oorresponder sustanoialmente a los oomponentes de nombre similar en las FIG. 1 y/o 7. En general, las teonioas de la FIG. 8 se analizan utilizando DASH (que a su vez utiliza HTTP), pero se debe entender que tambien se pueden utilizar otros protooolos de transmision oontinua. A oontinuaoion se analizan ejemplos alternativos oon respeoto a RTP/RTSP, por ejemplo.
Inioialmente, se puede proporoionar la informaoion de politioas al sistema que inoluye un oliente DASH 802, una aplioaoion de reproduooion 804, un redireotor/proxy HTTP 818, un oontrolador 814 y un MSDC 808. Dioha informaoion de politioas se puede almaoenar en la base de datos de politioas 816 (830). Esta informaoion de politioas puede influir en la aooion de oontrolador 814. El oontrolador 814 puede implementarse en hardware, software, firmware o oualquier oombinaoion de los mismos. Se asume que, ouando se implementa en software y/o firmware, tambien se proporoiona el hardware requerido, tal oomo una o mas unidades de prooesamiento basadas en hardware para ejeoutar las instruooiones de software oorrespondientes al oontrolador 814.
Inioialmente, la aplioaoion de reproduooion 804 puede proporoionar informaoion de identifioaoion, tal oomo informaoion de identifioaoion de un punto final del proxy (por ejemplo, el nombre o la direooion del anfitrion, el protooolo y el numero de puerto de protooolo) (832). Esta informaoion se puede proporoionar mediante una
5
10
15
20
25
30
35
40
45
50
55
60
65
aplicacion de aprovisionamiento opcional. El oliente DASH 802 puede estar configurado con la informacion de Identlfloaclon (834).
En el ejemplo de la FIG. 8, puede estar disponible mas de un transporte y pueden estar disponibles diversos medios (por ejemplo, en archivos) sobre los distintos transportes en diferentes instantes. Se considera, por ejemplo, que estan disponibles los transportes eMBMS y DVB. Se considera ademas que los archivos de medios disponibles se expresan utilizando una descripci6n de servicios de aplicaciones. Cada transporte puede tener un modulo correspondiente capaz de obtener la lista y los detalles de la informacion de medios y producir un URI sintetizado o un prefijo de URI comun, tal como se muestra mediante los modulos de transporte 110A-110R de la FIG. 1. Solo se muestra el MSDC 808 en el ejemplo de la FIG. 8, pero se debe entender que el MSDC 808 puede incluir varios modulos de transporte respectivos. Estos modulos transmiten la informacion del archivo a traves de un mecanismo de comunicacion (por ejemplo, IPC, API o protocolo) al controlador 814 que puede aplicar la politica y la resolucion, y que a su vez programa el redirector sujeto a la politica. La FIG. 8 representa solo las partes para MBMS (para limitar los ecos parasitos). El MBMS rX 820 puede recibir la USD (836), y analizar/entregar la USD al MSDC 808 (838).
El MSDC 808 procesa la informacion especifica de la USD en una forma que no es especifica del transporte y transmite los resultados al controlador 814 (840). El controlador 814 puede procesar entonces la lista de disponibilidad de archivos junto con la politica de acceso para producir un conjunto de asignaciones (842). Las asignaciones indican cuales URI (o prefijos de URI) deben re-direccionarse a que servidor instanciado (por ejemplo, los archivos disponibles sobre MBMS pueden estar disponibles en el servidor 812 instanciado dentro de o asociado con el MSDC 808). En otras palabras, el redirector/proxy HTTP 818 puede obtener informacion de asignacion que asigna un identificador para datos de medios a una ubicacion de recursos basandose en un servicio para recuperar los datos de medios, en el que el servicio define al menos uno de una pluralidad de tipos de transportes (por ejemplo, difusion, unidifusion o multidifusion) para transportar los datos de medios. Por ejemplo, el servicio puede definir tipos de transporte de difusion o multidifusion para transportar los datos de medios, en cuyo caso el MSDC 808 puede recibir los datos. El MSDC 808 puede almacenar los datos de medios recibidos en la memoria cache 810, para su posterior recuperacion mediante, por ejemplo, el cliente DASH 802, como se analiza a continuacion.
Una vez invocado, el cliente DASH 802 puede enviar una peticion HTTP a traves de la direccion del proxy configurado (al redirector/proxy HTTP 818) para obtener los contenidos MPD (844). Del mismo modo, el redirector/proxy HTTP 818 puede recibir la peticion HTTP del cliente DASH 802. La peticion HTTP puede ser una peticion de datos de medios. El redirector/proxy HTTP 818 puede realizar el algoritmo de coincidencia para determinar los criterios de coincidencia o, si no se produce una coincidencia, otro indicador (por ejemplo, un destino del redireccionamiento predeterminado, una indicacion de error, o una copia de la peticion original). Por lo tanto, utilizando los criterios de coincidencia en la informacion de asignacion, el redirector/proxy HTTP 818 puede determinar si un determinado servicio esta disponible, por ejemplo, la definicion de un servicio de difusion o multidifusion para el transporte de los datos de medios solicitados. El redirector/proxy HTTP 818 puede entonces proporcionar un destino del redireccionamiento o un error al cliente DASH 820 utilizando HTTP (846), basandose en el algoritmo de coincidencia.
El cliente DASH 802, despues de haber observado un codigo HTTP que indica un redireccionamiento (por ejemplo, un codigo HTTP de tipo 3xx) puede responder en funcion del tipo de codigo. Para tipos distintos de 300, una cabecera HTTP "Ubicacion:" puede indicar la ubicacion alternativa para un recurso. Tras recibir dicha indicacion, el cliente DASH 802 puede volver a intentar su peticion utilizando la ubicacion alternativa indicada. En este ejemplo, el redirector/proxy HTTP 818 puede indicar que un URI particular se debe dirigir al servidor integrado en el MSDC 808, a partir del cual el cliente DASH 802 puede obtener la MPD (848).
Una vez que el cliente DASH 802 ha obtenido la informacion MPD, el cliente DASH 802 puede determinar a que archivos de medios debe acceder (por ejemplo, a que "representacion" en el caso de MPEG-DASH) y enviar una o mas peticiones basadas en HTTP para recuperar los archivos de medios determinados (852). Utilizando el mecanismo descrito anteriormente, el redirector/proxy HTTP 818 proporciona un destino del redireccionamiento al cliente DASH 802 (854). El destino puede ser un valor por defecto, una copia de la peticion (que indica que el cliente debe gestionar la peticion), o una referenda a un servidor diferente. Los destinos sirven entonces como las ubicaciones utilizadas por el cliente DASH 802 para obtener segmentos de medios, por ejemplo, del MSDC 808 (856). De esta manera, cuando un servicio que define, por ejemplo, difusion o multidifusion para el transporte de medios, esta disponible, el redirector/proxy HTTP 818 puede hacer que el cliente DASH 802 reciba los datos de medios solicitados de una unidad (por ejemplo, el MSDC 808) que recibe los datos de medios utilizando el servicio de la ubicacion de recursos indicada en la informacion de asignacion. Alternativamente, el destino del redireccionamiento puede corresponder a una ubicacion de red disponible a traves de alguna red, incluyendo Internet 806.
En algunos casos, los URI solicitados desde el cliente (pasos 844/852) pueden ser desconocidos para el redirector/proxy HTTP 818. En tales casos, podrian generarse errores (por ejemplo, el codigo HTTP 404) para indicar al cliente DASH 802 que el cliente DASH 802 deberia intentar solicitar un segmento diferente o cambiar a no utilizar el redirector/proxy HTTP 818 (es dedr, utilizar una peticion de acceso a red directa o a Internet en su lugar).
5
10
15
20
25
30
35
40
45
50
55
60
65
Alternativamente, el redirector/proxy HTTP 818 puede utilizar una oabeoera "Ubicacion;" equivalente a la peticion entrante para sugerir un funcionamiento distinto de proxy. Una variante adicional implicaria que el redirector/proxy HTTP 818 actuase como un proxy web convencional, en cuyo caso el redirector/proxy HTTP 818 puede acceder a Internet 806 en nombre del cliente DASH 802.
De esta manera, las tecnicas de la FIG. 8 representan un ejemplo de un procedimiento que incluye, mediante una unidad de proxy (por ejemplo, un redirector/proxy HTTP 818), la obtencion de informacion de asignacion que asigna un identificador para datos de medios a una ubicacion de recursos basandose en un servicio para recuperar los datos de medios, en el que el servicio define al menos uno de una pluralidad de tipos de transportes (por ejemplo, difusion, multidifusion o unidifusion) para transportar los datos de medios, la recepcion de una peticion para datos de medios de un cliente de servicios de aplicaciones (por ejemplo, el cliente DASH 802), la determinacion de si el servicio esta disponible, y, si el servicio esta disponible, hacer que el cliente de servicios de aplicaciones reciba los datos de medios de una unidad que recibe los datos de medios utilizando el servicio de la ubicacion de recursos, basandose en la informacion de asignacion. La unidad que recibe los datos de medios, en este ejemplo, corresponde al MSDC 808.
Ademas, si la ubicacion de recursos corresponde a una ubicacion de red (por ejemplo, una ubicacion en o accesible a traves de Internet 806), el redirector/proxy HTTP 818 puede configurarse para determinar si los datos de medios especificados en una peticion coinciden con datos de medios en la informacion de asignacion, y si los datos de medios especificados en la peticion coinciden con los datos de medios en la informacion de asignacion, enviar un mensaje de redireccionamiento al cliente de servicios de aplicaciones especificando la ubicacion de red a la que esta asignado el identificador para los datos de medios en la informacion de asignacion para hacer que el cliente de servicios de aplicaciones recupere los datos de medios a partir de la ubicacion de red.
Del mismo modo, el redirector/proxy HTTP 818 representa un ejemplo de una unidad de proxy configurada para obtener informacion de asignacion que asigna un identificador para datos de medios a una ubicacion de recursos basandose en un servicio para recuperar los datos de medios, en la que el servicio define al menos uno de una pluralidad de tipos de transportes (por ejemplo, difusion, multidifusion o unidifusion) para transportar los datos de medios, recibir una peticion para los datos de los medios de un cliente de servicios de aplicaciones, determinar si el servicio esta disponible, y, si el servicio esta disponible, hacer que el cliente de servicios de aplicaciones reciba los datos de medios de una unidad que recibe los datos de medios utilizando el servicio de la ubicacion de recursos, basandose en la informacion de asignacion.
Las FIG. 9 y 10 son diagramas de bloques que ilustran arquitecturas del MSDC de ejemplo para soportar la transmision continua RTP/RTSP. La FIG. 9 muestra la arquitectura sin la caracteristica de la TSB y la FIG. 10 muestra la arquitectura que soporta una TSB. En estos ejemplos, la TSB se mantendra en el soporte intermedio. Las flechas numeradas indican el flujo de datos desde una capa de red al soporte intermedio y eventualmente al cliente RTSP/RTP. En particular, los datos recibidos por el modem LTE se proporcionan a la pila IP, que soporta la multidifusion (o la difusion). La pila IP proporciona los datos recibidos a una funcion de Protocolo de transporte en tiempo real (RTP) del soporte intermedio MSDC (901), que realiza el procesamiento de correccion de errores hacia adelante (FEC) sobre los datos. A continuacion, los datos se vuelven a proporcionar a la pila IP (902). A continuacion, la pila IP proporciona los datos al cliente RTP (903).
En el ejemplo de la FIG. 10, el MSDC 1010 puede soportar la TSB 1012. De este modo, en el ejemplo de la FIG. 10, los datos recibidos por el modem LTE se proporcionan a la pila IP, que soporta la multidifusion (o la difusion). La pila IP proporciona los datos recibidos a una funcion de Protocolo de transporte en tiempo real (RTP) del MSDC 1010 (1001), que realiza el procesamiento de correccion de errores hacia adelante (FEC) sobre los datos. A continuacion, los datos se almacenan en una memoria intermedia desplazada en el tiempo (TSB) 1012 (1002). La pila IP puede entonces recibir los datos de la TSB 1012 (1003) en un instante apropiado y proporcionar los datos al cliente RTP (1004).
Ademas, como se describe en mayor detalle a continuacion, el MSDC 1010 puede recibir un mensaje SDP que incluye un atributo que define una profundidad de la memoria intermedia desplazada en el tiempo (TSB) para la TSB 1012 de la FIG. 10. El MSDC 1010 puede determinar una cantidad de memoria para la TSB 1012 basandose en un valor del atributo senalizado en el mensaje SDP. Por ejemplo, el valor del atributo puede definir una duracion de la TSB, por ejemplo, en terminos de segundos de reproduccion para los datos de medios a almacenar en la TSB 1012. Por lo tanto, el MSDC 1010 puede determinar la cantidad de memoria a asignar para formar la TSB 1012 basandose, por ejemplo, en una velocidad de tramas para recibir los datos de video de los datos de medios y en el numero de segundos de reproduccion que se almacenaran potencialmente en la TSB 1012 . El MSDC 1010 puede entonces asignar una cantidad determinada de memoria para la TSB 1012 y almacenar al menos una parte de los datos de medios recibidos, asociados con el mensaje SDP, en la TSB 1012.
Con el fin de senalizar la profundidad de la TSB, las tecnicas de esta descripcion se pueden usar para aprovechar el mecanismo de extension del SDP. Las lineas del SDP "a=" (atributo) se pueden usar para proporcionar extensiones a la descripcion de sesion general. Se puede utilizar la siguiente semantica para senalizar datos relacionados con la TSB, como un ejemplo;
5
10
15
20
25
30
35
40
45
50
• Atributo-TSB = "a=duraci6n-tsb:" Valor
• Valor=testigo
o El valor tendra una unidad de segundos
Como un ejemplo, el siguiente fragmento del SDP mencionado en la Tabla 1 describe los datos para la TSB. La profundidad de la memoria intermedia en este ejemplo es de 60 segundos, o 1 minuto. Esto implica que el MSDC (por ejemplo, la TSB del MSDC ilustrada en la FIG. 10) mantendra 1 minuto el contenido de medios en su memoria intermedia desplazada en el tiempo. El texto subrayado representa un atributo de ejemplo en forma de una linea "a=", de acuerdo con las tecnicas de la presente divulgacion, relacionadas con la TSB.
TABLA 1
v=0
s=Sesi6n PTSP c=IN IP4127.0.0.1/1 a=3GPP-QoE-
Metricas:metricas=[Pecurso_de_red\Perdida_de_objetos};velocidad=Fin;resoluci6n=60 t=0 0
a= rtsp://anfitri6nLocal: 554/concierto a= longitud-tsb: 60 a=control: IDpista= 1 m= audio 5676 PTP/AVP 0
a=control: IDpista=2 m= video 5677 PTP/AVP 31
Cuando los datos para la TSB se proporcionan en el SDP, el MSDC puede asignar una cantidad equivalente de memoria intermedia del tamano mencionado en el SDP, y puede permitir que el cliente RTSP/RTP realice una reproduccion de avance rapido o un rebobinado, con respecto a la duracion de la memoria intermedia.
Una tecnica de ejemplo para lograr la diversidad de transportes esta basada en la solucion propuesta por la solicitud provisional de Estados Unidos con n.2 de serie 61/752.456, "ARCHITECTURE SUpPoRtING TRANSPORT DIVERSITY", de Fall y col., presentada el 15 de enero de 2013, expediente judicial n.2 131286P1 (en lo sucesivo en el presente documento, "Solicitud provisional de Fall"). La solicitud provisional de Fall propone una arquitectura de cliente comun para soportar diversos protocolos de transporte. Las tecnicas de la presente divulgacion para soportar la diversidad de transportes en RTP se pueden utilizar para extender las tecnicas descritas en la solicitud provisional de Fall, que se refiere a la entrega de contenidos basada en DASH.
A diferencia del protocolo DASH, en el que las representaciones de medios en la Descripcion de presentacion de medios (MPD) pueden cambiar en funcion de los procedimientos de entrega de transporte, el protocolo RTP convencionalmente no tiene ninguna manera de diferenciar la diversidad de transportes a traves de un unico perfil SDP directamente. La presente divulgacion describe tecnicas de ejemplo para lograr la diversidad de transportes.
Como un ejemplo, las definiciones de difusion de eMBMS de los servicios permiten a los mecanismos seleccionar entre mecanismos de transporte de unidifusion y difusion. Por ejemplo, un elemento MetodoEntrega en un esquema de definicion de servicios eMBMS puede contener un perfil SDP que describe las sesiones de entrega de difusion, mientras que un elemento EntregaAccesoAlternativo puede contener referencias a un URL RTSP para el acceso de unidifusion o a un fichero SDP PSS que denota la informacion de sesion SDP de unidifusion. Cuando un UE esta bajo la cobertura de la red de difusion, el soporte intermedio de eMBMS puede consumir contenido de difusion utilizando la informacion de sesion SDP emitida. De lo contrario, el soporte intermedio puede pasar el contenido conectandose al UPIAccesoUnidifusi6n en EntregaAccesoAlternativo. Un fragmento de ejemplo del esquema de Descripcion de servicios de usuario (USD) de eMBMS se muestra en la FIG. 11.
Un ejemplo alternativo al procedimiento de entrega que transporta URI de acceso SDP de difusion y unidifusion es tener un unico SDP unificado que contenga descripciones de las sesiones de unidifusion y difusion en diferentes flujos de medios. Dado que cualquier descripcion de sesion en SDP puede contener varias definiciones de flujos de medios (por ejemplo, uno para una pista de audio y otro para una pista de video), se puede utilizar un mecanismo para agrupar los flujos de medios de difusion y unidifusion en diferentes conjuntos para proporcionar un perfil SDP unificado . Esto se puede conseguir mediante un procedimiento de agrupamiento en SDP. Un ejemplo del mecanismo de agrupamiento se describe como sigue:
5
10
15
20
25
30
35
40
45
• identifioaoion de Ios flujos de medios
o identifioa Ios flujos de medios en Ios grupos o Atributo-Medios = "a=mid;" Etiqueta-identifioaoion o Etiqueta-identifioation = testigo
• Atributo de grupo
o identifioa Ios flujos de medios de unidifusion/difusion o Atributo-Grupo = "a=grupo;" Semantioa (identifioaoion-etiqueta)* o Semantioa = "DiFUSiON" |"UNiDiFUSi6N"
El siguiente fragmento en la Tabla 2 proporoiona un ejemplo en el que se proporoionan valores para Ios atributos del identifioador de grupo y de flujos de medios. En el siguiente ejemplo, las lineas "a=grupo;" denotan ouales flujos de medios se utilizan para la difusion y ouales flujos de medios se utilizan para la unidifusion. En este ejemplo, Ios flujos de medios de difusion se denotan mediante "a=mid;" valores 1 y 2 y la unidifusion se designa mediante "a=mid;" valores 3 y 4, respeotivamente. Por Io tanto, el soporte intermedio puede ooneotarse a la direooion iP 224.1.1.2 y a Ios puertos 30000 y 30002 para el oontenido de difusion, y a la direooion iP 131.10.1.2 y a Ios puertos 26890 y 26892 para Ios flujos de unidifusion.
TABLA 2
v=0 t=0 0
c=INIP4 224.2.17.12/127 a=arupo: DIFUSION 1 2 a=aruDo:UNIDIFUSl6N 3 4 m=audio 30000 RTP/AVP 0 c=INIP4 224.1.1.2/127 a=mid:1
m=vfdeo 30002 RTP/AVP 31 c=INIP4 224.1.1.2/127 a=mid:2
m= audio 26890 RTP/AVP 31 c=IN IP4 131.10.1.2/127 a=mid:3
m= video 26892 RTP/AVP 31 c=IN IP4 131.10.1.2/127 a=mid:4
De esta manera, la FiG. 10 ilustra un ejemplo de un dispositivo que inoluye uno o mas prooesadores oonfigurados para reoibir un mensaje de un Protocolo de desoripoion de sesion (SDP) que inoluye un atributo que define una profundidad de una memoria intermedia desplazada en el tiempo (TSB), determinar una oantidad de memoria para la TSB basandose en un valor del atributo, asignar la oantidad de memoria determinada a la TSB, y almaoenar al menos una parte de Ios datos de medios asooiados oon el mensaje SDP en la TSB.
Las FiG. 12 y 13 son diagramas de bloques que ilustran oomponentes de ejemplo para soportar la diversidad de transportes para un oliente RTSP/RTP. Si se utiliza MetodoEntrega en un USD eMBMS para diferenoiar entre el transporte de difusion y de unidifusion, o se utiliza el meoanismo SDP unioo unifioado, las teonioas de la presente divulgaoion pueden proporoionar la obtenoion de oontenido transparente mediante el oliente RTSP/RTP. Con el fin de lograrlo, oomo se propone en la solioitud provisional de Fall, se pueden mantener un gestor de politioas, un oontrolador, y un redireotor/proxy RTSP en el UE, posiblemente fuera del soporte intermedio eMBMS (tambien denominado oomo un Cliente de dispositivod de servioios de multidifusion (MSDC)). Cuando un oliente RTSP solioita un SDP, un redireotor/proxy RTSP siempre proporoiona perfiles SDP que llevan anfitrionLooal (por ejemplo, la direooion 127.0.0.1 de iP version 4) oomo la direooion del punto final de la oonexion. La idea es que si el redireotor/proxy RTSP reoibe oontenido a traves del soporte intermedio eMBMS (para difusion) o de un servidor RTSP de unidifusion (para unidifusion), siempre sirva el oontenido al oliente RTSP/RTP desde el anfitrionLooal. Por Io tanto, el oliente no tiene oonooimiento de la diversidad en el meoanismo de transporte. A oontinuaoion se proporoiona una breve desoripoion de Ios oomponentes prinoipales de la arquiteotura y se ofreoe un ejemplo de oomo se entrega el oontenido al oliente.
En Ios ejemplos de las FiG. 12 y 13, Aplioaoion de Reproduooion es la aplioaoion que esta intentando oonsumir el
5
10
15
20
25
30
35
40
45
50
55
60
65
oontenido de transmision oontinua; Cliente RTSP/RTP es el oliente que implementa el protocolo RTP para el comportamlento del oliente; soporte intermedio eMBMS es la arquiteotura de soporte intermedio que implementa la deteccion de servioios de difusion eMBMS (o MBMS) (para la transmision oontinua o la desoarga de arohivos) y oonsume el oontenido de la transmision oontinua o la entrega de arohivos a traves de la red de difusion de LTE; Gestor de Politicas mantiene una base de datos de politicas oomo se analizo anteriormente; Controlador es un oomponente que obtiene informacion de politicas del gestor de politicas y la indicacion de la oobertura de difusion eMBMS del soporte intermedio eMBMS y proporoiona una asignacion al redirector/proxy RTSP, indioando que perfil SDP elegir (unidifusion o difusion); y Redirector/Proxy RTSP es una unidad de proxy que reoibe informacion de asignacion desde el controlador y, dependiendo de la asignacion, reoopila el oontenido RTP del soporte intermedio eMBMS (en oaso de que el UE este en la oobertura de difusion) o se ooneota al URI RTSP de unidifusion y reoibe oontenido a traves del transporte de unidifusion, que puede pasar entonoes a Cliente RTSP/RTP.
La FIG. 12 representa un prooedimiento de ejemplo para la entrega de difusion de oontenido RTP. La FIG. 12 inoluye el oliente RTSP/RTP 1202, la aplicacion de reproduccion 1204, el redirector/proxy RTSP 1218, el controlador 1214, el soporte intermedio eMBMS (tambien denominado oomo MSDC) 1208, el gestor de politicas 1216 y la unidad de transmision de difusion (tambien denominada oomo eMBMS rX) 1220. La FIG. 12 tambien representa la red de aooeso radio (RAN) 1206 de la Evolucion a largo plazo (LTE). La RAN LTE 1206 proporoiona un servicio MBMS, que define al menos uno de una pluralidad de tipos de transportes (por ejemplo, difusion, multidifusion o unidifusion) para los datos de medios. Por lo tanto, ouando el MSDC 1208 esta en un area de servicio de oobertura proporoionada por RAN LTE 1206, el MSDC 1208 puede reoibir datos de medios a traves de RAN LTE 1206 utilizando un transporte de difusion o multidifusion. Ademas, el MSDC 1208 implementa el servidor 1212, que inoluye la memoria cache 1210. De esta manera, el MSDC 1208 puede aotuar oomo un oliente que reoibe datos de medios y oomo un servidor que proporoiona datos a, por ejemplo, el oliente RTSP/RTP 1202. Ademas, el oliente RTSP/RTP 1202 puede reouperar los datos de medios desde, por ejemplo, el MSDC 1208 o el redirector/proxy RTSP 1218 y, a continuacion, proporoionar los datos de medios a la aplicacion de reproduccion 1204.
La aplicacion de reproduccion 1204 puede oorresponder sustanoialmente a la aplicacion 101 (FIG. 1), mientras que el oliente RTSP/RTP 1202 puede oorresponder sustanoialmente al oliente de servioios de aplioaoiones 102 (FIG. 1). Del mismo modo, el MSDC 1208 puede oorresponder sustanoialmente a uno del soporte intermedio de transporte 110A-110R (FIG. 10). El controlador 1214 puede oorresponder sustanoialmente al controlador 106 (FIG. 1). El redirector/proxy RTSP 1218 puede oorresponder sustanoialmente al redirector/proxy 104 (FIG. 1).
En este ejemplo, el gestor de politicas esta provisto de politicas (1230). El soporte intermedio eMBMS (o MSDC) 1208 reoibe desoripoiones USD (1232, 1234) de la lista de servioios eMBMS. A continuacion, el MSDC 1208 pasa la informacion del perfil SDP al servicio de transmision oontinua RTP y la notificacion de oobertura de difusion al controlador 1214 (1236), que a su vez oompara la informacion SDP con la lista de politicas y proporoiona la informacion de asignacion al redirector/proxy RTSP 1218 (1238). La informacion de asignacion oontiene datos que indioan, para oada esoenario (oobertura de difusion o unidifusion), que puntos finales de la conexion del perfil SDP se deben utilizar. De esta manera, el redirector RTSP puede obtener la informacion de asignacion que asigna un identifioador para los datos de medios a una ubicacion de reoursos basandose en un servicio para reouperar los datos de medios. La ubicacion de reoursos puede oorresponder a una direccion de red, por ejemplo, una direccion disponible a traves de RAN LTE 1206. El servicio puede definir al menos uno de una pluralidad de tipos de transportes para transportar los datos de medios, por ejemplo, difusion o multidifusion.
Mientras tanto, el MSDC 1208 pasa una lista de servioios a la aplicacion de reproduccion 1204 (1240). La aplicacion de reproduccion 1204 puede oorresponder a la aplicacion 101 (FIG. 1). A continuacion, la aplicacion de reproduccion de 1204 pasa el URI RTSP (proporoionado con la lista de servioios del MSDC) y la direccion del proxy al oliente RTSP/RTP 1202 (1242). Cuando el oliente RTSP/RTP 1202 llama al oomando dEScRIBIR (un oomando definido de RTSP) (1244), el redirector/proxy RTSP 1218 proporoiona un mensaje SDP modifioado redireooionado al servidor local (1246). El oliente RTSP/RTP 1202 analiza la informacion del sDp (1248) y llama al oomando ESTABLECER (oomando RTSP) para estableoer una sesion RTP con el servidor local. El oliente RTSP/RTP 1202 tambien pasa el oomando REPRODUCIR ouando el estableoimiento con el servidor es oorreoto (1250). El redirector/proxy RTSP 1218 proporoiona un mensaje de exito a la peticion ESTABLECER y REPRODUCIR (1252) al oliente RTSP/RTP 1202. Los oomandos ESTABLECER y REpRODUCIR reoibidos por el redirector/proxy RTSP 1218 del oliente RTSP/RTP 1202 representan un ejemplo de una peticion de datos de medios. Ademas, el redirector/proxy RTSP 1218 envia oomandos ESTABLECER y REPRODUCIR al MSDC 1208 (1251).
El redirector/proxy RTSP 1218 puede determinar si el servicio para reouperar los datos de medios esta disponible, por ejemplo, si esta disponible un servicio que define la difusion o la multidifusion oomo un transporte. El redirector/proxy RTSP 1218 puede determinar si el servicio esta disponible basandose al menos en parte en si el redirector/proxy RTSP 1218 o el MSDC 1208 estan dentro de un area de oobertura del servicio. Las tecnicas de la FIG. 12 asumen que el servicio esta disponible. La FIG. 13, oomo se disoute en mayor detalle a continuacion, describe tecnicas adioionales que pueden emplearse ouando el servicio no esta disponible. Mientras tanto, durante la sesion de difusion aotiva del servicio de transmision oontinua, un operador de red envia el oontenido RTP sobre RAN LTE 1206 (1254). El MSDC reoopila el oontenido RTP para el servicio desde el punto final de la conexion de difusion (con la etiqueta eMBMS rX 1220 en la FIG. 12) (1256), prooesa el oontenido (si es neoesario), y pasa el
5
10
15
20
25
30
35
40
45
50
55
60
65
oontenido al oliente RTSP/RTP 1202 en un punto final espeoifioado por el oliente durante el comando ESTABLECER con el redireotor/proxy RTSP (1258). De esta manera, ouando el servioio esta disponible (por ejemplo, un servioio que define un transporte de difusion o multidifusion), el redireotor/proxy RTSP 1218 haoe que el oliente RTSP/RTP 1202 reoiba los datos de medios del MSDC 1208 (es deoir, una unidad que reoibe los datos de medios utilizando el servioio de una ubioaoion de reoursos, por ejemplo, a traves de RAN LTE 1206). En partioular, en este ejemplo, el MSDC 1208 reoibe datos de medios desde una ubioaoion de red a traves de RAN LTE 1206, basandose en la informaoion de asignaoion (por ejemplo, los datos USD desoritos anteriormente) que asigna el servioio a esta ubioaoion.
De esta manera, las teonioas de la FIG. 12 representan un ejemplo de un prooedimiento que inoluye, mediante una unidad de proxy (por ejemplo, un redireotor/proxy RTSP 1218), la obtenoion de informaoion de asignaoion que asigna un identifioador para datos de medios a una ubioaoion de reoursos basandose en un servioio para reouperar los datos de medios, en el que el servioio define al menos uno de una pluralidad de tipos de transportes (por ejemplo, difusion, multidifusion o unidifusion) para transportar los datos de medios, la reoepoion de una petioion para datos de medios de un oliente de servioios de aplioaoiones (por ejemplo, el oliente RTSP/RTP 1202), la determinaoion de si el servioio esta disponible, y, si el servioio esta disponible, haoer que el oliente de servioios de aplioaoiones reoiba los datos de medios de una unidad que reoibe los datos de los medios utilizando el servioio de la ubioaoion de reoursos, basandose en la informaoion de asignaoion. La unidad que reoibe los datos de medios, en este ejemplo, oorresponde al MSDC 1208.
La FIG. 13 representa un prooedimiento de ejemplo para la entrega de unidifusion de oontenido RTP. En este ejemplo, las etapas 1232-1248 son sustanoialmente similares a la entrega de oontenido de difusion tal oomo se desoribio oon respeoto a la FIG. 12. Sin embargo, en este oaso, ouando el oliente RTSP/RTP llama a los oomandos ESTABLECER y REPRODUCIR (1310), el redireotor/proxy RTSP 1218 oontaota oon un servidor RTSP de unidifusion a traves de la RAN/Internet 1302 a partir de la informaoion de asignaoion (1312), reoupera los oontenidos del servidor RTSP de unidifusion (1314), y pasa el oontenido al punto final menoionado mediante el oliente RTSP/RTP 1202 durante el oomando EsTaBlECER o los anunoiados en el SDP en la etapa 1246 (1316). Por lo tanto, en este oaso, el redireotor/proxy RTSP 1218 (que puede estar presente en el equipo de usuario que tambien inoluye el oliente RTSP/RTP 1202) aotua oomo oliente para el servidor RTSP remoto y reoupera el oontenido en nombre del oliente RTSP/RTP.
De esta manera, las teonioas de esta divulgaoion pueden usar un meoanismo de extension del SDP (atributo) para proporoionar una indioaoion de la TSB para la entrega de difusion eMBMS del oontenido RTP. La presente divulgaoion tambien define una arquiteotura ejemplo para soportar la transioion transparente entre el transporte de difusion y unidifusion, y para proporoionar meoanismos de entrega de oontenido de medios RTP en un UE. Ademas, la presente divulgaoion desoribe teonioas para agrupar multiples flujos de medios basados en RTP para la entrega de unidifusion y difusion de oontenido de un mensaje SDP.
El redireotor/proxy RTSP 1218 representa un ejemplo de una unidad de proxy que se puede oonfigurar para obtener informaoion de asignaoion que asigna un identifioador para datos de medios a una ubioaoion de reoursos basandose en un servioio para reouperar los datos de medios, en la que el servioio define al menos uno de una pluralidad de tipos de transporte (por ejemplo, difusion, multidifusion o unidifusion) para transportar los datos de medios, reoibir una petioion para los datos de los medios de un oliente de servioios de aplioaoiones, determinar si el servioio esta disponible, y, si el servioio esta disponible, haoer que el oliente de servioios de aplioaoiones reoiba los datos de medios de una unidad que reoibe los datos de medios utilizando el servioio de la ubioaoion de reoursos, basandose en la informaoion de asignaoion.
Las FIG. 14A y 14B son diagramas oonoeptuales que ilustran un modelo de oontenido XML de ejemplo para extender una USD para llevar la informaoion de transporte DASH. La A rodeada por un oiroulo representa un punto en el que se unen las oonexiones entre las FIG. 14A y 14B. El modelo de oontenido XML puede utilizarse solo o en oombinaoion oon oualquiera de las teonioas desoritas anteriormente. Por ejemplo, los oomponentes de las FIG. 1, 2A, 2B, 6, 7 y/u 8 pueden oonfigurarse para utilizar el modelo de oontenido XML desorito oon respeoto a las FIG. 14A y 14B. Como se analizo anteriormente, las teonioas de la presente divulgaoion inoluyen teonioas para seleooionar entre los modos de transporte de unidifusion y difusion. La FIG. 14B ilustra datos que definen tanto una representaoion de difusion (elemento difusion en la USD) y una representaoion de unidifusion (elemento unidifusion en la USD).
De aouerdo oon oiertas teonioas de la presente divulgaoion, un oliente de servioios de aplioaoiones, tal oomo un oliente DASH (por ejemplo, el oliente DASH de las FIG. 1, 2A, 2B, 6, 7 y/u 8), puede realizar una seleooion inioial de una representaoion a partir de la oual reoupera un segmento. En partioular, el oliente DASH puede haoer dioha seleooion inioial sin dejar de tener preferenoias en ouanto al modo de transporte (difusion y/o unidifusion) de la representaoion a la que perteneoe el segmento solioitado. Se asume, oon fines de ejemplo, que el oliente DASH utiliza HTTP para solioitar segmentos de una representaoion seleooionada, y se usa la USD extendida mostrada en la figura 14B para transportar la informaoion de transporte DASH. Cada una de la una o mas representaoiones de difusion se identifioan en la USD mediante un atributo URLbase unioo del elemento de difusion.
5
10
15
20
25
30
35
40
45
50
55
60
65
Cada instanoia de la difusion se asigna a una representaoion unioa entregada sobre la portadora MBMS. Su URLbase se oomparara con una parte del URL del segmento utilizado por el oliente DASH para solioitar segmentos; espeoifioamente, la parte inioial del URL del segmento que oomienza en el esquema del URI y se extiende hasta e inoluye el identifioador de la representaoion a la que perteneoe el segmento, para determinar si se esta solioitando dioha representaoion.
Por ejemplo, se asume que el URL del segmento enviado por el oliente DASH es "
http://ejemplo.oom/per-3/rep- 512/seg-99.3gp", que oorresponde a una petioion para el segmento 99 de la representaoion 512
(Representacion@id = '512'} en el periodo 3 (Periodo@id = '3'}. La parte de este URL de interes para el proposito de la ooinoidenoia oon el URLbase en el USD es "
http://ejemplo.oom/per-3/rep-512. En el oaso de que esta representaoion tambien este disponible sobre difusion, estara presente una instanoia de
Descripci6nPresentaci6nMedios2.difusi6n en la USD oon URLbase dado por "
http://ejemplo.oom/per-3/rep-512", identioo a la parte de interes en el URL de petioion. Por ejemplo, una ooinoidenoia en la parte de interes para el URL de petioion oon el atributo URLbase del elemento difusion de la USD denota el transporte de difusion de la representaoion a la que perteneoe el segmento solioitado.
De igual forma, oada una de las oero o mas representaoiones de unidifusion, en este ejemplo, se identifioa en la USD mediante un unioo elemento atributo URLbase de Descripci6nPresentacionMedios2.unidifusi6n. Un patron ooinoidente en la misma parte del URL de petioion analizado anteriormente para el URLbase de unidifusion implioa que esta representaoion esta disponible sobre una entrega de unidifusion. La misma representaoion puede estar disponible sobre ambos, solo uno, o ninguno de los modos de transporte.
La entidad a la que el oliente DASH envia la la petioion de segmento puede ser una unidad de proxy (o a un oliente MBMS o eMBMS}. Para los fines del ejemplo, la unidad de proxy se desoribe a oontinuaoion oomo realizando estas teonioas, pero se debe entender que el MBMS o eMBMS de, por ejemplo, las FIG. 1, 2A, 2B, 6, 7 y/u 8 puede estar oonfigurado para realizar las teonioas atribuidas a la unidad de proxy, tal oomo se desoribe a oontinuaoion. Mediante el uso de la ooinoidenoia de patrones entre la parte de interes para el URL de petioion oon el valor de URLbase en los elementos difusion y unidifusion en la USD, la unidad de proxy podra determinar si el modo de transporte seleooionado esta disponible y/o es preferente sobre otro modo de transporte.
La unidad de proxy puede reouperar una politioa que indioa las preferenoias entre los tipos de transportes. Por ejemplo, la politioa puede indioar que si la petioion es para una representaoion entregada sobre unidifusion, siempre que el dispositivo se enouentre en un area de oobertura de difusion, solo una representaoion oon entrega de difusion deberia estar aooesible para el oliente DASH. Dioha representaoion de difusion puede ser la misma representaoion que la solioitada inioialmente, si el URLbase apareoe en el elemento Contenidoldentico de la USD, y puede ser sustituido por la representaoion solioitada, aunque se entregue sobre un modo de transporte diferente.
Por otra parte, la representaoion de difusion puede ser una representaoion alternativa oonooida para entregar sobre difusion, y se oonsidera una representaoion oonmutable, ya que el URLbase para la representaoion alternativa apareoe en la lista de entradas del elemento de la USD ContenidoConmutable. En este oaso, la unidad de proxy puede volver a enviar un mensaje al oliente DASH para haoer que el oliente DASH solioite el mismo segmento que perteneoe a una representaoion alternativa que se entrega sobre difusion. Por ejemplo, la unidad de proxy puede enviar un mensaje de respuesta HTTP de tipo 300 al oliente DASH, que oorresponde a un mensaje de redireooionamiento, y el mensaje de redireooionamiento puede espeoifioar un URL de reoursos que oorresponde a la representaoion alternativa de la lista inoluida en ContenidoConmutable.
Como otro ejemplo, si el oliente DASH solioito un segmento oonooido a la unidad de proxy para su entrega sobre difusion, pero la reoepoion de difusion no esta disponible (por ejemplo, debido a que un dispositivo de oliente esta fuera de un area de oobertura para el transporte de difusion}, la unidad de proxy puede enviar un mensaje de respuesta HTTP de tipo 300 que inoluye un URL de un segmento oorrespondiente a un transporte de unidifusion del mismo, o una representaoion diferente si esa misma representaoion no esta disponible sobre el transporte de unidifusion, pero apareoe oomo una entrada en ContenidoConmutable.
Como otro ejemplo, si el oliente DASH solioito un segmento oonooido a la unidad de proxy para su entrega sobre difusion y la reoepoion de difusion esta disponible, la unidad de proxy delegara la petioion en la memoria oaohe de oontenido looal, y volvera a entregar el segmento reouperado al oliente DASH .
Alternativamente, la unidad de proxy puede responder oon un mensaje de error de tipo 400, lo que puede haoer que el oliente DASH vuelva a enviar una petioion utilizando un URL de segmento diferente. La unidad de proxy tambien puede oomunioar un protooolo de transporte diferente de otras formas, por ejemplo, a traves de una interfaz de programaoion de aplioaoiones (API}, la oomunioaoion entre prooesos (IPC), el el envio de una MPD modifioada que omite el URL base seleooionado, o similares.
El mensaje de redireooionamiento o error de la unidad de proxy puede haoer que el oliente DASH seleooione un modo de transporte distinto. En algunos ejemplos, puede estar disponible mas de una representaoion en el modo de transporte redirigido, en ouyo oaso el oliente DASH puede seleooionar de entre una de esas representaoiones
5
10
15
20
25
30
35
40
45
50
55
60
65
disponibles. Como un ejemplo, si el oliente DASH habia intentado seleccionar una representacion de difusion (como se indica mediante una instancia del elemento difusion de las FIG. 14A y 14B), pero la unidad de proxy determino que la recepcion de difusion no esta disponible, la unidad de proxy puede enviar un mensaje (por ejemplo, un mensaje de redireccionamiento de tipo 300, un mensaje de error de tipo 400, una llamada API, mediante comunicaciones IPC, o similares) al cliente DASH para hacer que el cliente DASH seleccione en su lugar la representacion de unidifusion de las FIG. 14A y 14B.
En algunos casos, un cliente de servicios de aplicaciones, tal como el cliente DASH, puede encargarse de la gestion de las transiciones unidifusion-difusion. La presente divulgacion describe, con respecto a las FIG. 14A y 14B como un ejemplo, una estructura para extender la USD con parametros adicionales que pueden, en el caso de la entrega de descarga DASH sobre MBMS, permitir a un cliente MBMS determinar si las peticiones de segmento desde un cliente DASH se pueden servir tal cual, o solo a partir de una o mas representaciones alternativas. La USD puede indicar el modo de transporte (solo difusion, solo unidifusion, o tanto difusion como unidifusion) de cada representacion especificada en la Descripcion de presentacion de medios (MPD). A continuacion se describen escenarios de ejemplo para las reglas y mecanismos para determinar la disponibilidad de la representacion.
En un ejemplo, el equipo de usuario (UE) puede estar ubicado dentro de un area de cobertura de MBMS, y el cliente DASH puede solicitar una representacion particular que la USD indica que no esta disponible a traves de la entrega de difusion. La politica del proveedor de servicios puede indicar que cada vez que el UE esta en la cobertura de MBMS, solamente se puede acceder a representaciones con entrega de difusion del mismo programa. En esta situacion, el cliente DASH puede estar limitado a seleccionar (o redireccionado o indicado para seleccionar) de entre la(s) representacion(es) alternativa(s) disponible(s) sobre la entrega de difusion.
En otro ejemplo, el UE puede estar ubicado dentro de la cobertura de MBMS, y el cliente DASH puede solicitar una representacion que se sabe que esta disponible sobre la entrega de difusion. En esta situacion, el UE puede acceder directamente a la representacion deseada.
En otro ejemplo, el UE puede estar fuera de la zona de recepcion de MBMS, y el cliente DASH puede solicitar una representacion que se sabe que solo esta disponible sobre la entrega de difusion. En esta situacion, el cliente DASH puede estar limitado a seleccionar (o redireccionado o indicado para seleccionar) de entre la(s) representacion(es) alternativa(s) disponible(s) sobre la entrega de unidifusion, en forma de contenido(s) conmutable(s).
En otro ejemplo, el UE puede estar fuera de la zona de recepcion de MBMS, y el cliente DASH puede solicitar una representacion que se sabe que tambien esta disponible sobre la entrega de difusion. En esta situacion, el cliente DASH puede ser capaz de recibir la misma representacion sobre unidifusion, en forma de contenido identico.
Informacion adicional que puede llevarse en la USD incluye la indicacion de la(s) zona(s) de servicio sobre la(s) cual(es) se entrega cada representacion, y/o la identificacion del SDP que describe la sesion FLUTE que lleva dicha representacion.
La presente divulgacion describe tecnicas mediante las cuales se puede anadir un elemento hijo Descripci6nPresentaci6nMedios2 en DescripcionServicioUsuario para llevar parametros de transporte adicionales. Anteriormente, se propuso que los parametros especificos de la MPD, tales como el ID del periodo, el ID del conjunto de adaptacion, y el ID de la representacion estuviesen incluidos en Descripci6nPresentacionMedios2, que puede identificar a aquellas representaciones disponibles sobre la entrega de unidifusion. Estos mismos parametros, junto con la referenda URI a un fragmento de descripcion de sesion, pueden identificar cada representacion que se puede entregar sobre difusion, asi como la asignacion a la sesion FLUTE que lleva los segmentos de dicha representacion.
Un problema que las tecnicas de la presente divulgacion pueden superar se refiere a permitir el uso de HTTP/1.1 como interfaz de protocolos entre el cliente DASH y el cliente MBMS para la peticion/respuesta de segmento, mientras se mantiene una separacion de capas limpia en el procesamiento de protocolos. Por ejemplo, en las tecnicas anteriores, el cliente MBMS tiene que procesar la informacion especifica de la MPD para poder correlacionar la peticion del cliente DASH para segmentos de una representacion particular con segmentos de una representacion disponible y permitida realmente (por ejemplo, de acuerdo con la politica del proveedor de servicios) mediante el modo de transporte (difusion o unidifusion). En caso de que no se pueda proporcionar una representacion solicitada, para que el cliente MBMS utilice el redireccionamiento HTTP (a traves de codigos de respuesta 3xx como los definidos en Fielding y col., "Protocolo de transferencia de hipertexto - HTTP/1.1", Grupo de Trabajo de Redes, RFC 2616 , junio de 1999, disponible en
http://www.ietf.org/rfc/rfc2616.txt) para informar al cliente DASH de una o mas representaciones alternativas, el cliente MBMS tendra que componer un URI de segmento completo para cada recurso alternativo. Dicha violacion de las capas en la parte del cliente MBMS se puede eliminar mediante el uso de las tecnicas de la presente divulgacion.
Las tecnicas de la presente divulgacion eliminan la necesidad de que el cliente MBMS (o unidad de proxy) conozca o tenga que procesar la informacion MPD (especifica de DASH). El cliente MBMS simplemente realiza la correspondencia datos/patron, basandose en la presencia de nuevos metadatos en la USD, con los URI de peticion
5
10
15
20
25
30
35
40
45
50
55
60
65
de segmento generados por el oliente DASH, para determinar si el segmento solloltado esta dlsponlble sobre difusion, unidifusion, ninguno de los dos o ambos modos de transporte, o de alguna otra manera (por ejemplo, la memoria cache). Esto es posible porque la parte del URI de petioion que identifioa de forma exolusiva la representaoion a la que perteneoe el segmento solioitado tambien se transporta en la USD. Ademas, el oliente MBMS puede determinar si la representaoion solioitada por el oliente DASH (que no tiene preferenoia en ouanto al modo de transporte) esta disponible sobre difusion, unidifusion, ninguno de los dos o ambos modos de transporte, o de alguna otra manera (por ejemplo, la memoria oaohe), mediante la ubioaoion del patron de datos ooinoidente en la USD. En oombinaoion oon otras reglas y oondioiones pertinentes, tal oomo el estado de la oobertura (si el UE esta en el area de servioio de unidifusion y/o difusion), la politioa del proveedor de servioios, eto., y suponiendo que el prooedimiento de sustituoion para devolver el URI del reourso alternativo basandose en el atributo de la USD SustitucionPermitida = "verdadero". El oliente MBMS puede utilizar meoanismos HTTP/1.1 para asignar las petioiones de segmento al reourso apropiado, por ejemplo, una memoria oaohe de oontenido looal en el UE, o un servidor HTTP externo, sin violar las oapas de protooolos.
Como se puede ver en los ejemplos de las FIG. 14A y 14B, oada una de la una o mas representaoiones de difusion se identifioa en la USD mediante un atributo URLbase unioo del elemento de difusion. El valor URLbase puede ser identioo a una parte del URI de segmento utilizado por el oliente DASH para solioitar un segmento de dioha representaoion; espeoifioamente, la parte inioial del URI del segmento que oomienza a partir del prooedimiento y se extiende hasta e inoluye el IDRepresentaoion. Por ejemplo, si el URI del segmento es el URL "
http://ejemplo.oom/per-3/rep-512/seg-99.3gp", oorrespondiente a una petioion para el segmento 99 de la representaoion 512 (IDRepresentacion = 512) en el periodo 3, el URLbase se puede definir oomo "
http://ejemplo.oom/per-3/rep-512".
En este ejemplo, oada una de la una o mas representaoiones de difusion se identifioa en la USD mediante un atributo URLbase unioo del elemento de difusion. Cada instanoia de la difusion se asigna a una representaoion unioa entregada sobre la portadora MBMS. Su URLbase se oomparara oon una parte del URI del segmento utilizado por el oliente DASH para solioitar segmentos; espeoifioamente, la parte inioial del URI del segmento que oomienza en el esquema del URI y se extiende hasta e inoluye el ID de la representaoion (valor de Representaoion@id en la MPD). Por ejemplo, se asume que el URI del segmento enviado por el oliente DASH es el URL "
http://ejemplo.oom/per- 3/rep-512/seg-99.3gp", que oorresponde a una petioion para el segmento 99 de la representaoion 512 (Representaoion@id = '512') en el periodo 3 (Periodo@id = '3'). La parte de este URL de interes para el proposito de la ooinoidenoia oon los datos de la USD es "
http://ejemplo.oom/per-3/rep-512. En el oaso de que esta representaoion tambien este disponible sobre difusion, estara presente una instanoia de Descripci6nPresentacionMedios2.difusi6n en la USD oon URLbase dado por "
http://ejemplo.oom/per-3/rep-512", identioo a la parte de interes en el URI de petioion.
En oaso de que el oliente MBMS determine que solo se puede aooeder a representaoion(es) alternativa(s) a lo solioitado por el oliente DASH, el atributo SustitucionPermitida de DescripcionPresentacionMedios2 puede indioar al oliente MBMS si debe proporoionar dioha notifioaoion al oliente DASH a traves del prooedimiento de redireooionamiento HTTP (oodigo de estado 3xx) y oomo haoerlo, por ejemplo, tal oomo se define en RFC 2616.
Por ejemplo, si SustitucionPermitida = "verdadero", se puede suponer que el oontenido DASH y la MPD se han produoido de tal manera que permiten al oliente MBMS proporoionar, al oliente DASH, URI de reoursos alternativos a traves del redireooionamiento '303 Ver Otros', independientemente del modo de transporte de la representaoion alternativa. Espeoifioamente, oada URI alternativo se puede formar mediante la sustituoion de la parte de interes en el URI del segmento oomo se ha desorito anteriormente por el URLbase en la USD oorrespondiente a la representaoion alternativa, al tiempo que oonserva el numero de segmento en la petioion original.
Por otro lado, si SustitucionPermitida = 'falso', entonoes puede no estar permitido dioho prooedimiento de sustituoion para generar un URI del reourso alternativo y proporoionarselo al oliente DASH. La teonioa resultante para haoer que se solioite y se entregue una representaoion alternativa puede depender de la implementaoion (por ejemplo, el oliente MBMs puede devolver un oodigo de error 4xx aoompanado de la representaoion alternativa indioada por el valor URLbase, y oonfiar en el oliente DASH para formular una petioion alternativa). Un ejemplo de un flujo de llamada que muestra las interaooiones entre el oliente MBMS y el oliente DASH, basado en el redireooionamiento HTTP '303', se desoribe a oontinuaoion oon respeoto a las FIG. 15 y 16.
De igual forma, oada una de las oero o mas representaoiones de unidifusion se pueden identifioar en la USD mediante un unioo elemento atributo URLbase de Descripci6nPresentacionMedios2.unidifusi6n. Un patron ooinoidente en la misma parte del URI de petioion analizado anteriormente para el URLbase de unidifusion implioa que esta representaoion esta disponible sobre una entrega de unidifusion. Se debe observar que la misma representaoion puede estar disponible sobre ambos, solo uno, o ninguno de los modos de transporte.
De lo oontrario, a traves del elemento DescripcionSesion, oada representaoion de difusion puede estar vinoulada a un fragmento de desoripoion de sesion o dooumento del SDP oorrespondiente a la sesion FLUTE que transporta dioha representaoion. Ademas, el ElementoAreaServicio, si esta presente, puede denotar la(s) zona(s) de servioio MBMS sobre las que esta(n) disponible(s) la(s) representaoion(es) de difusion.
5
10
15
20
25
30
35
40
45
50
55
60
La FIG. 15 es un diagrama conceptual que Hustra una arqultectura para soportar DASH sobre un MBMS. El ejemplo de la FIG. 15 representa una arquitectura de red de extremo a extremo para la entrega de contenido DASH sobre una portadora MBMS con retorno de unidifusion. La entrega de descarga basada en FLUTE representa la interfaz definida conforme a TS 26.346 entre el BM-SC y el cliente MBMS. La interfaz asumida entre el cliente DASH y el cliente MBMS (aqui se supone que es una entidad compuesta que incluye el receptor MBMS, el servidor HTTP basado en dispositivo, la politica, las funciones de redireccionamiento y proxy) es HTTP/1.1.
La FIG. 16 es un diagrama de flujo que ilustra un flujo de llamada asociado con la arquitectura de red de la FIG. 15 para la entrega de contenido DASH sobre un transporte de difusion y unidifusion. Las tecnicas descritas con respecto a la FIG. 16 estan basadas en la extension de la USD mostrada en las FIG. 14A y 14B para llevar la informacion de transporte DASH. Aunque se describen como correspondientes a la arquitectura de red de la FIG. 15, se debe entender que las tecnicas de la FIG. 16 pueden ser realizadas por otros dispositivos, por ejemplo, los dispositivos de las arquitecturas de las FIG. 1, 2A, 2B, 6, 7, 8 y/o 17. En el ejemplo de la FIG. 16, se asume que la USD contiene la informacion mostrada en la Tabla 3, que incluye valores del atributo URLbase en Descripci6nPresentaci6nMedios2.difusi6n y Descripci6nPresentaci6nMedios2. unidifusion, y se asume que el valor del atributo SustitucionPermitida en la USD es "verdadero".
TABLA 3
DescripcionPresentacionMedios2.difusion (URLbase)
DescripcionPresentacionMedios2.unidifusion (URLbase)

http://eiemplo.com/per-3/rep-512

http://eiemplo.com/per-3/rep-256
http://eiemplo.com/per-3/rep-128
Ademas, en este ejemplo, se supone que la MPD incluye los siguientes contenidos:
• MPD@tipo = ’dinamica’
• Periodo@id =’3’
• Periodo.PlantillaSegmento@medios = ’
http://ejemplo.com/per-3/rep-$IDRepresentacion$/seg-$Numero$.3gp’
o Representacion@id = ’512’ ... o Representacion@id = ’256’ ... o Representacion@id = ’128’ ...
Teniendo en cuenta estos valores de parametros MPD de ejemplo, el cliente DASH que intenta solicitar el segmento n2 99 de la representacion 512 en el periodo 3 puede emitir el siguiente URI de peticion:
http://ejemplo.com/per- 3/rep-512/seg-99.3gp. El flujo de llamada de la FIG. 16 describe la entrega de contenido DASH para dos situaciones diferentes: 1) El UE se encuentra en cobertura MBMS, y solicita segmentos de la representacion 512 del periodo 3, que esta disponible sobre la entrega de difusion, y, posteriormente, 2) el UE se mueve fuera de la cobertura MBMS, y continua solicitando la misma representacion (es decir, la representacion 512) , que no esta disponible sobre la entrega de unidifusion, pero las representaciones 256 y 128 estan disponibles sobre unidifusion.
En otras palabras, la presente divulgacion describe ciertas tecnicas para usar la senalizacion basada en USD del transporte DASH para soportar la diversidad de transportes. Puede proporcionar una o mas mejoras sobre una propuesta anterior descrita en Tdoc S4-130051, "Fundamentos de la indicacion USD del modo de entrega DASH e implementacion ilustrativa" de Qualcomm Inc. Por ejemplo, una violacion de las capas se puede evitar completamente en este procedimiento, porque el cliente MBMS no tiene que entender o procesar la informacion MPD. En su lugar, el cliente MBMS puede realizar una correspondencia del patron de datos de semantica de transporte conocida con los URI de los segmentos solicitados por el cliente DASH para determinar si se solicita que los segmentos solicitados se entreguen sobre difusion y/o unidifusion, y si dicha peticion se puede cumplir tal cual, o debe redireccionarse a una representacion similar o alternativa disponible utilizando otro modo de transporte.
Dicha determinacion puede basarse en factores tales como si el UE se encuentra dentro o fuera de la cobertura MBMS, la politica del proveedor de servicios, si existe, que regula la accesibilidad de las representaciones mediante el modo de transporte, y posiblemente depende de otras condiciones o reglas. Se proporcionaron ejemplos de la arquitectura de red y el diagrama del flujo de llamada para la entrega de contenido DASH a traves de MBMS con retorno de unidifusion para ilustrar la entrega de contenido de extremo a extremo con el uso de la interfaz de protocolos HTTP entre el cliente DASH y el cliente MBMS. La adhesion a las capas de protocolos deberia proporcionar ventajas de arquitectura en cuanto a la extensibilidad y la simplicidad de la implementacion del UE para soportar los servicios DASH en MBMS.
El uso del redireccionamiento HTTP a traves del codigo de estado 3xx por el cliente MBMS para restringir el acceso del cliente DASH a un recurso (representacion) alternativo se basa en que el atributo SustitucionPermitida de Descripci6nPresentaci6nMedios2 tenga el valor "verdadero". En tal caso, se supone que el contenido DASH y la
5
10
15
20
25
30
35
40
45
50
55
MPD se han producido de tal manera que permiten al oliente MBMS proporcionar al oliente DASH URI de recursos alternatives a traves del redireccionamiento '303 Ver Otros', independientemente del modo de transporte de la representacion alternativa. Especificamente, cada URI alternativo se forma mediante la sustitucion de la parte de interes en el URL del segmento como se ha descrito anteriormente por el URLbase en la USD correspondiente a la representacion alternativa, al tiempo que conserva el numero de segmento en la peticion original. Si el valor de SustitucionPermitida = 'falso', entonces no esta permitido dicho procedimiento de sustitucion para generar un URI del recurso alternativo URI y proporcionarselo al cliente DASH.
Las tecnicas resultantes para hacer que se solicite y se entregue una representacion alternativa pueden depender de la implementacion. Por ejemplo, el cliente MBMS puede devolver un codigo de error 4xx acompanado o no de una representacion alternativa como se indica mediante el valor URLbase en el cuerpo de la entidad de la respuesta HTTP, y confiar en el cliente DASH para formar una peticion alternativa. En este caso, la presencia del URLbase que identifica una representacion alternativa disponible en la respuesta se puede utilizar como una pista para que el cliente DASH con la inteligencia solicite directamente dicha representacion como seguimiento. Alternativamente, la "pista" del URLbase puede no proporcionarse en la respuesta 4xx, o el cliente DASH puede carecer de la inteligencia para utilizar dicha pista para generar una nueva peticion de otra representacion que puede corresponder o no a la representacion permitida desde la perspectiva del cliente MBMS.
La FIG. 17 es un diagrama conceptual que ilustra otra arquitectura de ejemplo para soportar DASH sobre MBMS. Puede ser importante especificar la interfaz entre el BM-SC y el cliente eMBMS y la interfaz entre el cliente eMBMS y el cliente DASH en una norma apropiada. Por ejemplo, la norma puede especificar que la interfaz entre el BM-SC y el cliente eMBMS debera cumplir TS 26.346. La norma tambien puede especificar que la interfaz entre el cliente eMBMS y el cliente DASH deberia seguir TS 26.247 si el cliente DASH y el cliente eMBMS son de diferentes proveedores. Contrastado con el ejemplo de la FIG. 16, la FIG. 17 ilustra un ejemplo en el que una interfaz entre un cliente DASH y un cliente eMBMS puede cumplir TS 26.247 (que puede ser, por ejemplo, HTTP/1.1). La FIG. 17 ilustra una arquitectura de alto nivel para permitir que DASH sobre MBMS realice un retorno a DASH sobre unidifusion.
Las FIG. 18-23 son diagramas de flujo que ilustran diversos ejemplos de flujos de llamada asociados con la arquitectura de red de la FIG. 17 para la entrega de contenido DASH sobre un transporte de difusion y unidifusion. Aunque se describen como correspondientes a la arquitectura de red de la FIG. 17, se debe entender que las tecnicas de las FIG. 18-23 pueden ser realizadas por otros dispositivos, por ejemplo, los dispositivos de las arquitecturas de las FIG. 1,2A, 2B, 6, 7, 8 y/o 15.
Con respecto al ejemplo de la FIG. 18, la senalizacion USD puede incluir los datos que se muestran en la Tabla 4 a continuacion para el cliente eMBMS:
TABLA 4
Difusion@URLbase
Unidifusion@URLbase

http://www.cnn.com/512/seg$Numero$.3pg

http://www.cnn.com/256/seg$Numero$.3pg
http://www.cnn.com/128/seg$Numero$.3pg
La MPD en este ejemplo puede especificar los siguientes datos, en la que URLbase corresponden a las partes de base de los URL para acceder a los segmentos:
URLbase1=
http://www.cnn.com/512/, IdRepresentacion = "512";
Plantilla=seg$Numero$.3gp,
URLbase2=
http://www.cnn.com/256/, IdRepresentacion="256";
Plantilla=seg$Numero$.3gp,
URLbase3=
http://www.cnn.com/128/, IdRepresentacion="128";
Plantilla=seg$Numero$.3gp.
En el ejemplo de la FIG. 18, se supone que el cliente eMBMS no tiene funciones de proxy HTTP, sino que solo tiene funciones de redirector HTTP.
Con respecto al ejemplo de la FIG. 19, la senalizacion USD puede incluir los datos que se muestran en la Tabla 5 a continuacion para el cliente eMBMS:
TABLA 5
Difusion@URLbase
Unidifusion@URLbase

http://www.cnn.com/512/seg$Numero$.3pg

http://www.cnn.com/256/seg$Numero$.3pg
5
10
15
20
25
30
35
40
45
50

http://www.cnn.com/128/seq$Numero$.3pq
La MPD en este ejemplo puede especificar los siquientes datos, en la que URLbase corresponden a las partes de base de los URL para acceder a los seqmentos:
URLbase1=
http://www.cnn.com/512/, IdRepresentacion = "512";
Plantilla=seq$Numero$.3qp,
URLbase2=
http://www.cnn.com/256/, IdRepresentacion= "256";
Plantilla=seq$Numero$.3qp,
URLbase3=
http://www.cnn.com/128/, IdRepresentacion="128";
Plantilla=seq$Numero$.3qp.
En el ejemplo de la FIG. 19, se supone que el cliente tiene eMBMS tiene tanto la funcion de proxy HTTP como la funcion de redirector HTTP.
Con respecto al ejemplo de la FIG. 20, la senalizacion USD puede incluir los datos que se muestran en la Tabla 6 a continuacion para el cliente eMBMS:
TABLA 6
Difusion@URLbase
Unidifusion@URLbase

http://www.cnn.com/512/seq$Numero$.3pq

http://www.cnn.com/512/seq$Numero$.3pq
http://www.cnn.com/256/seq$Numero$.3pq
http://www.cnn.com/128/seq$Numero$.3pq
La MPD en este ejemplo puede especificar los siquientes datos, en la que URLbase corresponden a las partes de base de los URL para acceder a los seqmentos:
URLbase1.1=
http://www.cnn.com/512/,
URLbase1.2=
http://anfitri6nlocal/512/,IdRepresentacion = "512";
Plantilla=seq$Numero$.3qp,
URLbase2=
http://www.cnn.com/256/, IdRepresentacion="256"; Plantilla=seq$Numero$.3qp, URLbase3=
http://www.cnn.com/128/, IdRepresentacion="128"; Plantilla=seq$Numero$.3qp.
En el ejemplo de la FIG. 20, se supone que el cliente eMBMS no tiene la funcion de proxy HTTP, sino que solo tiene la funcion de redirector HTTP.
Con respecto al ejemplo de la FIG. 21, la senalizacion USD puede incluir los datos que se muestran en la Tabla 7 a continuacion para el cliente eMBMS:
TABLA 7
Difusion@URLbase
Unidifusion@URLbase

http://www.cnn.com/512/seq$Numero$.3pq

http://www.cnn.com/512/seq$Numero$.3pq
http://www.cnn.com/256/seq$Numero$.3pq
http://www.cnn.com/128/seq$Numero$.3pq
La MPD en este ejemplo puede especificar los siquientes datos, en la que URLbase corresponden a las partes de base de los URL para acceder a los seqmentos:
URLbase1 =
http://www.cnn.com/;
IdRepresentacion = "512"; Plantilla=$IdRepresentacion$/seq$Numero$.3qp,
IdRepresentacion="256"; Plantilla=$IdRepresentacion$/seq$Numero$.3qp,
IdRepresentacion= "128"; Plantilla=$Representacion$/seq$Numero$.3qp.
En el ejemplo de la FIG. 21, se supone que el cliente eMBMS no tiene la funcion de proxy HTTP, sino que solo tiene la funcion de redirector HTTP.
Con respecto al ejemplo de la FIG. 22, la senalizacion USD puede incluir los datos que se muestran en la Tabla 8 a continuacion para el cliente eMBMS:
5
10
15
20
25
30
35
40
45
50
55
TABLA 8
Difusion@URLbase
Unidifusion@URLbase

http://www.onn.oom/512/seg$Numero$.3pg

http://www.onn.oom/512/seg$Numero$.3pg
http://www.onn.oom/256/seg$Numero$.3pg
http://www.onn.oom/128/seg$Numero$.3pg
La MPD en este ejemplo puede espeoifioar Ios siguientes datos, en la que URLbase corresponden a las partes de base de los URL para aooeder a los segmentos:
URLbase1=
http://anfitrionlooal/512/, IdRepresentaoion = "512";
Plantilla=seg$Numero$.3gp,
URLbase2=
http://www.onn.oom/256/, IdRepresentaoion= "256";
Plantilla=seg$Numero$.3gp,
URLbase3=
http://www.onn.oom/128/, IdRepresentaoion=""128";
Plantilla=seg$Numero$.3gp.
En el ejemplo de la FIG. 22, se supone que el oliente eMBMS no tiene la funoion de proxy HTTP, sino que solo tiene la funoion de redireotor HTTP.
Con respeoto al ejemplo de la FIG. 23, la senalizaoion USD puede inoluir los datos que se muestran en la Tabla 9 a oontinuaoion para el oliente eMBMS:
TABLA 9
Difusion@URLbase
Unidifusion@URLbase

http://www.onn.oom/1024/seg$Numero$.3pg
http://www.onn.oom/512/seg$Numero$.3pg

http://www.onn.oom/256/seg$Numero$.3pg
http://www.onn.oom/128/seg$Numero$.3pg
La MPD en este ejemplo puede espeoifioar los siguientes datos, en la que URLbase oorresponden a las partes de base de los URL para aooeder a los segmentos:
URLbase1=
http://www.onn.oom/1024/, IdRepresentaoion = "1024";
Plantilla=seg$Numero$.3gp,
URLbase2=
http://www.onn.oom/512/, IdRepresentaoion = "512";
Plantilla=seg$Numero$.3gp,
URLbase3=
http://www.onn.oom/256/, IdRepresentaoion= "256";
Plantilla=seg$Numero$.3gp,
URLbase4=
http://www.onn.oom/128/, IdRepresentaoion=""128";
Plantilla=seg$Numero$.3gp.
En el ejemplo de la FIG. 23, se supone que el oliente eMBMS no tiene la funoion de proxy HTTP, sino que solo tiene la funoion de redireotor HTTP.
La FIG. 24 es un diagrama de flujo que ilustra un prooedimiento de ejemplo para senalizar datos relaoionados oon una profundidad de la memoriza intermedia desplazada en el tiempo (TSB) de aouerdo oon las teonioas de la presente divulgaoion. Para los propositos del ejemplo, el prooedimiento de la FIG. 25 se explioa oon respeoto a los oomponentes de la FIG. 10, por ejemplo, el MSDC 1010 y la TSB 1212. Sin embargo, se debe entender que las teonioas para utilizar una memoria intermedia desplazada en el tiempo se pueden inoorporar en oualquiera de los diversos sistemas desoritos en el presente dooumento, por ejemplo, los sistemas de oualquiera de las FIG. 1,7, 8, 9, 12, 13 y/o 17.
Inioialmente, el MSDC 1010 puede reoibir un mensaje del protooolo de desoripoion de sesion (SDP) (2400). El mensaje SDP puede inoluir un atributo que define una profundidad de la memoria intermedia desplazada en el tiempo (TSB). En oonseouenoia, el MSDC 1010 puede determinar un valor para el atributo (tambien denominado oomo un atributo de profundidad de la TSB) en el mensaje SDP (2402). El valor del atributo de profundidad de la TSB puede definir la profundidad de la TSB, por ejemplo, en terminos de segundos de reproduooion para los datos de medios a almaoenar en la TSB. Por ejemplo, el valor del atributo puede definir un tiempo de reproduooion maximo, en segundos, que se puede almaoenar en la TSB.
5
10
15
20
25
30
35
40
45
50
55
60
65
Por Io tanto, el MSDC 1010 puede determinar una oantidad de memoria a asignar para formar la TSB de la profundldad indioada (2404). Por ejemplo, suponiendo que la profundidad de la TSB se indioa en terminos de segundos de reproduooion para los datos de medios, y suponiendo que se senaliza una velooidad de tramas para los datos de video, el MSDC puede determinar un numero de tramas de video a almaoenar en la TSB, oomo el produoto de la velooidad de tramas (expresada en tramas por segundo) y el numero de segundos de datos de medios a almaoenar. El MSDC 1010 puede entonoes determinar una oantidad de memoria para la TSB basandose en el produoto de una tasa de bits media por trama y el numero de tramas. El MSDC 1010 puede utilizar oonoeptos similares para determinar el tamano de la memoria para los datos de audio, los datos de texto temporizado y similares.
El MSDC 1010 puede entonoes asignar la oantidad de memoria determinada para formar la TSB (2406). Por lo tanto, oomo el MSDC 1010 reoibe los datos de medios, el MSDC 1010 puede almaoenar los datos de medios reoibidos en la TSB (2408). Una aplioaoion de reproduooion puede utilizar estos datos de medios memorizados para aplioaoiones oon desplazamiento temporal, tal oomo para visualizar posteriormente o para realizar un modo avanzado de reproduooion, tal oomo el avanoe rapido o el rebobinado. Por supuesto, los datos almaoenados temporalmente tambien se pueden usar para la reproduooion en tiempo sustanoialmente real.
De esta manera, el prooedimiento de la FIG. 24 representa un ejemplo de un prooedimiento que inoluye un mensaje de un Protooolo de desoripoion de sesion (SDP) que inoluye un atributo que define una profundidad de una memoria intermedia desplazada en el tiempo (TSB), determina una oantidad de memoria para la TSB basandose en un valor del atributo, asigna la oantidad de memoria determinada a la TSB, y almaoena al menos una parte de los datos de medios asooiados oon el mensaje SDP en la TSB.
Los expertos en la teonioa entenderan que la informaoion y las senales pueden representarse usando oualquiera de varias teonologias y teonioas diferentes. Por ejemplo, los datos, las instruooiones, los oomandos, la informaoion, las senales, los bits, los simbolos y los chips que pueden haber sido menoionados a lo largo de la desoripoion anterior pueden representarse mediante tensiones, oorrientes, ondas eleotromagnetioas, oampos o partioulas magnetioos, oampos o partioulas optioos, o oualquier oombinaoion de los mismos.
Los expertos en la teonioa apreoiaran ademas que los diversos bloques logioos, modulos, oirouitos y etapas de algoritmo ilustrativos desoritos en relaoion oon la divulgaoion del presente dooumento pueden implementarse oomo hardware eleotronioo, software informatioo o oombinaoiones de ambos. Para ilustrar olaramente esta interoambiabilidad de hardware y software, anteriormente se han desorito diversos oomponentes, bloques, modulos, oirouitos y etapas ilustrativos, generalmente, en lo que respeota a su funoionalidad. Si tal funoionalidad se implementa oomo hardware o software depende de la aplioaoion partioular y de las limitaoiones de diseno impuestas sobre todo el sistema. Los expertos en la teonioa pueden implementar la funoionalidad desorita de diferentes maneras para oada aplioaoion partioular, pero no debe interpretarse que tales deoisiones de implementaoion suponen un apartamiento del aloanoe de la presente divulgaoion.
En uno o mas ejemplos, las funoiones desoritas pueden implementarse en hardware, software, firmware o oualquier oombinaoion de los mismos. Si se implementan en software, las funoiones pueden almaoenarse en, o transmitirse oomo una o mas instruooiones o oodigo en un medio legible por ordenador, y ejeoutarse mediante una unidad de prooesamiento basada en hardware. Los medios legibles por ordenador pueden inoluir medios de almaoenamiento legibles por ordenador, que oorresponden a un medio tangible tal oomo medios de almaoenamiento de datos o medios de oomunioaoion que inoluyen oualquier medio que faoilite la transferenoia de un programa informatioo desde un lugar a otro, por ejemplo, segun un protooolo de oomunioaoion. De esta manera, los medios legibles por ordenador pueden oorresponder, generalmente, a (1) medios de almaoenamiento tangibles y legibles por ordenador, que sean no transitorios, o (2) un medio de oomunioaoion tal oomo una senal o una onda portadora. Los medios de almaoenamiento de datos pueden ser medios disponibles oualesquiera, a los que se pueda aooeder desde uno o mas ordenadores o uno o mas prooesadores para reouperar instruooiones, oodigo y/o estruoturas de datos para la implementaoion de las teonioas desoritas en esta divulgaoion. Un produoto de programa informatioo puede inoluir un medio legible por ordenador.
A modo de ejemplo, y no de manera limitativa, tales medios de almaoenamiento legibles por ordenador pueden oomprender RAM, ROM, EEPROM, CD-ROM u otro almaoenamiento de disoo optioo, almaoenamiento de disoo magnetioo u otros dispositivos de almaoenamiento magnetioo, memoria flash o oualquier otro medio que pueda usarse para almaoenar oodigo de programa deseado en forma de instruooiones o estruoturas de datos y al que pueda aooederse mediante un ordenador. Ademas, oualquier oonexion puede denominarse adeouadamente un medio legible por ordenador. Por ejemplo, si las instruooiones se transmiten desde una sede de la Red, un servidor u otra fuente remota usando un oable ooaxial, un oable de fibra optioa, un par trenzado, una linea de abonado digital (DSL) o teonologias inalambrioas tales oomo infrarrojos, radio y mioroondas, entonoes el oable ooaxial, el oable de fibra optioa, el par trenzado, la DSL o las teonologias inalambrioas tales oomo infrarrojos, radio y mioroondas se inoluyen en la definioion de medio. Sin embargo, deberia entenderse que los medios de almaoenamiento legibles por ordenador y los medios de almaoenamiento de datos no inoluyen oonexiones, ondas portadoras, senales u otros medios transitorios, sino que, en oambio, se orientan a medios de almaoenamiento tangibles no transitorios. Los disoos, oomo se usan en el presente dooumento, inoluyen el disoo oompaoto (CD), el disoo de laser, el disoo optioo,
5
10
15
20
25
30
el disco versatil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos normalmente reproducen datos de manera magnetica, mientras que otros discos reproducen los datos de manera optica con laser. Las combinaciones de lo anterior tambien deberian incluirse dentro del alcance de los medios legibles por ordenador.
Las instrucciones pueden ser ejecutadas por uno o mas procesadores, tales como uno o mas procesadores de senales digitales (DSP), microprocesadores de proposito general, circuitos integrados de aplicacion especifica (ASIC), matrices logicas de campo programable (FPGA), u otro circuito logico integrado o discreto equivalente. Por consiguiente, el termino "procesador", como se usa en el presente documento, puede referirse a cualquier estructura anterior o a cualquier otra estructura adecuada para la implementacion de las tecnicas descritas en el presente documento. Ademas, en algunos aspectos, la funcionalidad descrita en el presente documento puede proporcionarse dentro de hardware especializado y/o modulos de software configurados para la codificacion y la descodificacion, o incorporarse en un codec combinado. Ademas, las tecnicas podrian implementarse completamente en uno o mas circuitos o elementos logicos.
Las tecnicas de esta divulgacion se pueden implementar en una amplia variedad de dispositivos o aparatos, incluyendo un equipo de mano inalambrico, un circuito integrado (IC) o un conjunto de IC (por ejemplo, un conjunto de chips). Varios componentes, modulos o unidades se describen en esta divulgacion para enfatizar aspectos funcionales de dispositivos configurados para realizar las tecnicas divulgadas, pero no requieren necesariamente la realizacion mediante diferentes unidades de hardware. Mas bien, como se ha descrito anteriormente, pueden combinarse diversas unidades en una unidad de hardware de codec, o ser proporcionadas por una coleccion de unidades de hardware inter-operativas, incluyendo uno o mas procesadores, como se ha descrito anteriormente, conjuntamente con el software y/o firmware adecuado.
La descripcion detallada que se ha expuesto anteriormente, en relacion con los dibujos adjuntos, esta concebida como una descripcion de varias configuraciones y no pretende representar las unicas configuraciones en las que pueden llevarse a la practica los conceptos descritos en el presente documento. La descripcion detallada incluye detalles especificos con el objeto de proporcionar un entendimiento minucioso de varios conceptos. Sin embargo, a los expertos en la tecnica les resultara evidente que estos conceptos pueden llevarse a la practica sin estos detalles especificos. En algunos casos, estructuras y componentes ampliamente conocidos se muestran en forma de diagrama de bloques para evitar oscurecer tales conceptos.
Se han descrito diversos ejemplos. Estos y otros ejemplos estan dentro del alcance de las siguientes reivindicaciones.

Claims (16)

10
15
20 2.
25
30
3.
35
4.
40
5.
45
6.
50
7.
55
8.
60
REIVINDICACIONES
Un procedimiento de recuperacion de datos de medios, comprendiendo el prooedimiento; mediante una unidad de proxy (818, 1218);
la obtencion de informacion de asignacion que asigna un identificador para datos de medios a una ubicacion de recursos basandose en un servicio para recuperar los datos de medios, caracterizado porque
el servicio define al menos uno de una pluralidad de tipos de transportes para transportar los datos de medios;
la recepcion de una peticion para los datos de medios desde un cliente de servicios de aplicaciones (802, 1202); la determinacion de si el servicio esta disponible; y
si el servicio esta disponible, hacer que el cliente de servicios de aplicaciones reciba los datos de medios de una unidad (808, 1208) que recibe los datos de medios utilizando el servicio de la ubicacion de recursos, basandose en la informacion de asignacion.
El procedimiento, de acuerdo con la reivindicacion 1, en el que la ubicacion de recursos comprende una ubicacion de red (806, 1206), comprendiendo ademas el procedimiento;
la determinacion de si los datos de medios especificados en la peticion coinciden con los datos de medios en la informacion de asignacion; y
si los datos de medios especificados en la peticion coinciden con los datos de medios en la informacion de asignacion, el envio de un mensaje de redireccionamiento al cliente de servicios de aplicaciones que especifica la ubicacion de red a la que esta asignado el identificador para los datos de medios en la informacion de asignacion para hacer que el cliente de servicios de aplicaciones recupere los datos de medios de la ubicacion de red.
El procedimiento, de acuerdo con la reivindicacion 2, que comprende ademas, si los datos de medios especificados en la peticion no coinciden con los datos de medios en la informacion de asignacion, el envio de un mensaje de redireccionamiento al cliente de servicios de aplicaciones especificando una ubicacion de red de redireccionamiento predeterminada para hacer que el cliente de servicios de aplicaciones recupere los datos de medios desde la ubicacion de red de redireccionamiento predeterminada.
El procedimiento, de acuerdo con la reivindicacion 2, que comprende ademas, si los datos de los medios especificados en la peticion no coinciden con los datos de medios en la informacion de asignacion, volver a enviar una copia de la peticion al cliente de servicios de aplicaciones.
El procedimiento, de acuerdo con la reivindicacion 2, que comprende ademas el almacenamiento de la informacion de asignacion en una tabla de asignacion, en el que la determinacion de si los datos de medios especificados en la peticion coinciden con los datos de medios en la informacion de asignacion comprende la determinacion de si un identificador para el dispositivo de medios corresponde a una entrada en la tabla de asignacion.
El procedimiento, de acuerdo con la reivindicacion 2, en el que la informacion de asignacion comprende criterios de asignacion expresados como prefijos de un Identificador uniforme de recursos, URI, y en en el que la determinacion de si los datos de medios especificados en la peticion coinciden con los datos de medios en la informacion de asignacion comprende la determinacion de un prefijo URI de la informacion de asignacion que coincide con al menos una parte de un URI de los datos de los medios indicados en la peticion.
El procedimiento, de acuerdo con la reivindicacion 6, en el que la determinacion de un prefijo URI de la informacion de asignacion que coincide con al menos una parte de un URI de los datos de medios indicados en la peticion comprende la determinacion de un prefijo URI mas largo de la informacion de asignacion que coincida con al menos una parte de un URI de los datos de medios indicados en la peticion.
El procedimiento, de acuerdo con la reivindicacion 6, en el que los prefijos URI expresados por los criterios de asignacion corresponden a servicios respectivos que definen tipos de transporte para transportar datos de medios, y en el que un primer prefijo URI de los prefijos URI define un servicio de difusion y un segundo prefijo URI de los prefijos URI define un servicio de unidifusion.
El procedimiento, de acuerdo con la reivindicacion 2, en el que la informacion de asignacion incluye valores de prioridad para cada coincidencia potencial, y en el que la determinacion de si los datos de medios
5
10
15
20
25
30
35
40
45
50
55
60
espeoifioados en la petioion ooinoiden con Ios datos de medios en la informacion de asignacion comprende la seleccion de una ooinoidenoia que tiene un mayor valor de prioridad.
10. El prooedimiento, de aouerdo con la reivindioaoion 2, en el que la informacion de asignacion inoluye valores de prioridad para oada ooinoidenoia potenoial, y en el que la determinacion de si los datos de medios espeoifioados en la petioion ooinoiden con los datos de medios en la informacion de asignacion comprende la seleccion de una ooinoidenoia que tiene un menor valor de prioridad.
11. El prooedimiento, de aouerdo con la reivindicacion 2, en el que la informacion de asignacion comprende oriterios de asignacion expresados oomo expresiones regulares, y en el que la determinacion de si los datos de medios espeoifioados en la petioion ooinoiden con los datos de medios en la informacion de asignacion comprende la seleccion de una expresion regular que coincide con un mayor numero de oaraoteres que ooinoiden direotamente con un identifioador para los datos de medios indioados en la petioion.
12. El prooedimiento, de aouerdo con la reivindicacion 2, en el que la informacion de asignacion comprende
oriterios de asignacion expresados oomo expresiones regulares, en el que la informacion de asignacion
inoluye valores de prioridad para oada ooinoidenoia potenoial, y en el que la determinacion de si los datos de medios espeoifioados en la petioion ooinoiden con los datos de medios en la informacion de asignacion oomprende la seleooion de una ooinoidenoia que tiene un mayor valor de prioridad.
13. El prooedimiento, de aouerdo con la reivindicacion 2, en el que la informacion de asignacion comprende
oriterios de asignacion expresados oomo expresiones regulares, en el que la informacion de asignacion
inoluye valores de prioridad para oada ooinoidenoia potenoial, y en el que la determinacion de si los datos de medios espeoifioados en la petioion ooinoiden con los datos de medios en la informacion de asignacion oomprende la seleooion de una ooinoidenoia que tiene un menor valor de prioridad.
14. El prooedimiento, de aouerdo con la reivindicacion 1, en el que la determinacion de si el servicio esta
disponible comprende la determinacion de si la unidad de proxy esta dentro de un area de oobertura de
servicio.
15. El prooedimiento, de aouerdo con la reivindicacion 1, en el que la petioion se ajusta a una petioion de transmision oontinua dinamica adaptativa sobre HTTP, DASH, oomprendiendo ademas el prooedimiento:
mediante la unidad de proxy:
la recepcion de la petioion DASH, en la que la petioion DASH espeoifioa una direccion de red de la unidad de proxy; en respuesta a la petioion DASH, la recuperacion de los datos de medios espeoifioados en la petioion, y el aprovisionamiento de los datos de medios al oliente de servicios de aplioaoiones.
16. Un dispositivo para la recuperacion de datos de medios, oomprendiendo el dispositivo una unidad de proxy (818, 1218), que comprende:
medios para obtener informacion de asignacion que asigna un identifioador para los datos de medios a una ubicacion de reoursos basandose en un servicio para reouperar los datos de medios, caracterizado porque el servicio define al menos uno de una pluralidad de tipos de transportes para transportar los datos de medios;
medios para reoibir una petioion para los datos de los medios desde un oliente de servicios de aplioaoiones (802, 1202);
medios para determinar si el servicio esta disponible; y
si el servicio esta disponible, medios para hacer que el oliente de servicios de aplioaoiones reoiba los datos de medios de una unidad (808, 1208) que reoibe los datos de medios utilizando el servicio de la ubicacion de reoursos, basandose en la informacion de asignacion.
17. El dispositivo, de aouerdo con la reivindicacion 16, que comprende ademas una unidad de soporte intermedio que reoibe los datos de medios, en el que la unidad de soporte intermedio comprende uno de unos servicios de difusion/multidifusion multimedia, MBMS, la unidad de soporte intermedio y una unidad de soporte intermedio de MBMS evoluoionado, eMBMS.
18. El dispositivo, de aouerdo con la reivindicacion 16, en el que el dispositivo comprende un dispositivo de proxy, en el que un dispositivo de oliente comprende el oliente de servicios de aplioaoiones, y en el que el dispositivo de proxy es independiente del dispositivo de oliente.
ES14703972.1T 2013-01-15 2014-01-14 Soporte para diversidad de transportes y memorias intermedias desplazadas en el tiempo para la transmisión continua de medios sobre una red Active ES2630279T3 (es)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201361752456P 2013-01-15 2013-01-15
US201361752456P 2013-01-15
US201361809871P 2013-04-08 2013-04-08
US201361809871P 2013-04-08
US201414153888 2014-01-13
US14/153,888 US10015437B2 (en) 2013-01-15 2014-01-13 Supporting transport diversity and time-shifted buffers for media streaming over a network
PCT/US2014/011475 WO2014113383A1 (en) 2013-01-15 2014-01-14 Supporting transport diversity and time-shifted buffers for media streaming over a network

Publications (1)

Publication Number Publication Date
ES2630279T3 true ES2630279T3 (es) 2017-08-21

Family

ID=51165207

Family Applications (1)

Application Number Title Priority Date Filing Date
ES14703972.1T Active ES2630279T3 (es) 2013-01-15 2014-01-14 Soporte para diversidad de transportes y memorias intermedias desplazadas en el tiempo para la transmisión continua de medios sobre una red

Country Status (9)

Country Link
US (2) US20140199044A1 (es)
EP (1) EP2946542B1 (es)
JP (1) JP6231583B2 (es)
KR (1) KR101847585B1 (es)
CN (1) CN105284093B (es)
BR (1) BR112015016989B1 (es)
ES (1) ES2630279T3 (es)
HU (1) HUE031896T2 (es)
WO (1) WO2014113383A1 (es)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
US9160779B2 (en) 2011-06-30 2015-10-13 Qualcomm Incorporated Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
US9445138B2 (en) 2012-04-12 2016-09-13 Qualcomm Incorporated Broadcast content via over the top delivery
US9820259B2 (en) 2012-05-04 2017-11-14 Qualcomm Incorporated Smooth transition between multimedia broadcast multicast service (MBMS) and unicast service by demand
US20140199044A1 (en) 2013-01-15 2014-07-17 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
US9807188B2 (en) * 2013-04-09 2017-10-31 Samsung Electronics Co., Ltd. Methods and apparatuses for dynamic content offloading
US9973559B2 (en) * 2013-05-29 2018-05-15 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for presenting content streams to a client device
US9674251B2 (en) 2013-06-17 2017-06-06 Qualcomm Incorporated Mediating content delivery via one or more services
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
WO2015064350A1 (ja) * 2013-10-28 2015-05-07 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
US9386067B2 (en) * 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
US20150350284A1 (en) * 2014-05-27 2015-12-03 Acer Incorporated Method of Enhancement of Data Transmission in Multimedia Service
WO2015194392A1 (ja) 2014-06-20 2015-12-23 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US9237204B1 (en) * 2014-07-30 2016-01-12 Iboss, Inc. Web redirection for caching
CA2964712C (en) * 2014-10-28 2023-02-28 Sony Corporation Reception device, transmission device, and data processing method
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
WO2016126116A1 (ko) 2015-02-04 2016-08-11 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10412132B2 (en) * 2015-02-16 2019-09-10 Lg Electronics Inc. Broadcasting signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US11057446B2 (en) 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
CN106254300B (zh) * 2015-06-08 2020-04-21 中兴通讯股份有限公司 流媒体传输方法、播放方法、传输装置及播放装置
US10193994B2 (en) * 2015-06-18 2019-01-29 Qualcomm Incorporated Signaling cached segments for broadcast
US10291681B2 (en) 2015-06-18 2019-05-14 Ericsson Ab Directory limit based system and method for storing media segments
US11095537B2 (en) * 2015-06-19 2021-08-17 Qualcomm Incorporated Middleware delivery of dash client QoE metrics
US20170048681A1 (en) * 2015-08-11 2017-02-16 At&T Intellectual Property I, L.P. On-demand time-shifted access of broadcast content
JP6661931B2 (ja) * 2015-09-17 2020-03-11 沖電気工業株式会社 情報配信装置、情報配信プログラム及び情報配信システム
CN106549916A (zh) * 2015-09-18 2017-03-29 中兴通讯股份有限公司 组播传输方法、装置及系统
GB2543312A (en) * 2015-10-14 2017-04-19 Smartpipe Tech Ltd Network identification as a service
WO2017125150A1 (en) * 2016-01-20 2017-07-27 Telefonaktiebolaget Lm Ericsson (Publ) Switching between unicast and multicast in a content delivery network
US20170295188A1 (en) * 2016-04-06 2017-10-12 Karamba Security Automated security policy generation for controllers
CN106331089A (zh) * 2016-08-22 2017-01-11 乐视控股（北京）有限公司 一种视频播放控制方法和系统
WO2018043111A1 (ja) * 2016-08-29 2018-03-08 ソニー株式会社 情報処理装置、情報処理方法、及び、情報処理システム
KR102532645B1 (ko) * 2016-09-20 2023-05-15 삼성전자 주식회사 적응적 스트리밍 서비스에서 스트리밍 어플리케이케이션으로 데이터를 제공하는 방법 및 장치
US10542409B2 (en) * 2016-10-07 2020-01-21 Qualcomm Incorporated Access for group call services through a broadcast channel
CN107979570A (zh) * 2016-10-25 2018-05-01 北京优朋普乐科技有限公司 网络电台资源数据处理方法和装置
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
US10893315B2 (en) 2017-03-24 2021-01-12 Sony Corporation Content presentation system and content presentation method, and program
US11190374B2 (en) 2017-08-28 2021-11-30 Bright Data Ltd. System and method for improving content fetching by selecting tunnel devices
EP4191981A1 (en) 2017-08-28 2023-06-07 Bright Data Ltd. Improving content fetching by selecting tunnel devices grouped according to geographic location
US20190075545A1 (en) * 2017-09-02 2019-03-07 Qualcomm Incorporated Method and apparatus for providing unicast representations within a broadcast coverage area
CN108810652A (zh) * 2018-06-04 2018-11-13 深圳汇通九州科技有限公司 一种信息处理方法及终端设备
EP3750079A4 (en) 2019-02-25 2022-01-12 Bright Data Ltd SYSTEM AND METHOD FOR URL EXTRACTION CHALLENGE MECHANISM
EP4030318A1 (en) 2019-04-02 2022-07-20 Bright Data Ltd. System and method for managing non-direct url fetching service
CN110708293B (zh) * 2019-09-11 2021-11-19 中国联合网络通信集团有限公司 多媒体业务的分流方法和装置
CN112929070B (zh) * 2019-12-06 2023-04-18 中移(上海)信息通信科技有限公司 数据播发系统及方法
EP3886401A1 (en) * 2020-03-27 2021-09-29 Nokia Technologies Oy Method, apparatus, and computer program product for error handling for indirect communications
CN115134420A (zh) * 2021-03-24 2022-09-30 华为技术有限公司 一种媒体播放方法、装置和电子设备

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6052718A (en) 1997-01-07 2000-04-18 Sightpath, Inc Replica routing
US7809854B2 (en) * 2002-02-12 2010-10-05 Open Design, Inc. Logical routing system
US6990512B1 (en) 2001-03-19 2006-01-24 Novell, Inc. Method and system for using live time shift technology to control a multimedia file
US6813690B1 (en) * 2001-06-12 2004-11-02 Network Appliance, Inc. Caching media data using content-sensitive identifiers
ATE292869T1 (de) * 2001-12-21 2005-04-15 Castify Networks Sa Verfahren zur server-auswahl in einem inhaltsauslieferungsnetzwerk
US7987491B2 (en) * 2002-05-10 2011-07-26 Richard Reisman Method and apparatus for browsing using alternative linkbases
US7480723B2 (en) * 2003-04-08 2009-01-20 3Com Corporation Method and system for providing directory based services
US7454510B2 (en) 2003-05-29 2008-11-18 Microsoft Corporation Controlled relay of media streams across network perimeters
US20050102371A1 (en) 2003-11-07 2005-05-12 Emre Aksu Streaming from a server to a client
US7647599B2 (en) * 2003-12-22 2010-01-12 Motorola, Inc. Interprocessor communication network providing dynamic dedication of ports
US7162533B2 (en) 2004-04-30 2007-01-09 Microsoft Corporation Session description message extensions
US20060031559A1 (en) 2004-05-25 2006-02-09 Gennady Sorokopud Real Time Streaming Protocol (RTSP) proxy system and method for its use
US20070130597A1 (en) * 2005-12-02 2007-06-07 Alcatel Network based instant replay and time shifted playback
US9380096B2 (en) * 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
BRPI0621810A2 (pt) 2006-06-27 2011-12-20 Thomson Licensing Método e aparelho para distribuir dados em difusão seletiva de forma confiável
US7584495B2 (en) * 2006-06-30 2009-09-01 Nokia Corporation Redundant stream alignment in IP datacasting over DVB-H
US20080069126A1 (en) * 2006-09-14 2008-03-20 Sbc Knowledge Ventures, L.P. Method and system for buffering content
US8489817B2 (en) * 2007-12-06 2013-07-16 Fusion-Io, Inc. Apparatus, system, and method for caching data
WO2009036184A2 (en) * 2007-09-11 2009-03-19 Research In Motion Limited System and method for sharing a sip communication service identifier
US8458290B2 (en) 2011-02-01 2013-06-04 Limelight Networks, Inc. Multicast mapped look-up on content delivery networks
US8661155B2 (en) * 2008-12-30 2014-02-25 Telefonaktiebolaget Lm Ericsson (Publ) Service layer assisted change of multimedia stream access delivery
US20100180011A1 (en) * 2009-01-12 2010-07-15 Microsoft Corporation Url based retrieval of portions of media content
US9369516B2 (en) 2009-01-13 2016-06-14 Viasat, Inc. Deltacasting
US20110066703A1 (en) 2009-05-20 2011-03-17 Creative Ad Technology Proprietary Limited Methods and systems for delivering media to client device
CN101924944B (zh) * 2009-06-15 2013-06-05 华为技术有限公司 可伸缩视频编码操作点选择方法、信息提供方法及设备
US20110219416A1 (en) * 2010-03-04 2011-09-08 Telefonaktiebolaget L M Ericsson (Publ) Network Time-Shift Methods and Apparatus
US9319448B2 (en) 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
WO2012059376A1 (en) 2010-11-02 2012-05-10 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for media description delivery
US20120124179A1 (en) * 2010-11-12 2012-05-17 Realnetworks, Inc. Traffic management in adaptive streaming protocols
EP2673935B1 (en) * 2011-02-11 2019-04-24 InterDigital Patent Holdings, Inc. Method and apparatus for distribution and reception of content
US9026671B2 (en) 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9226265B2 (en) 2011-04-15 2015-12-29 Qualcomm Incorporated Demand-based multimedia broadcast multicast service management
TWI584662B (zh) 2011-06-01 2017-05-21 內數位專利控股公司 內容傳遞網路互連(cdni)機制
US9160779B2 (en) 2011-06-30 2015-10-13 Qualcomm Incorporated Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
US9268621B2 (en) * 2011-11-02 2016-02-23 Red Hat, Inc. Reducing latency in multicast traffic reception
US9769281B2 (en) * 2011-12-19 2017-09-19 Google Technology Holdings LLC Method and apparatus for determining a multimedia representation for a multimedia asset delivered to a client device
US20130182643A1 (en) 2012-01-16 2013-07-18 Qualcomm Incorporated Method and system for transitions of broadcast dash service receptions between unicast and broadcast
US9547532B2 (en) * 2012-01-19 2017-01-17 Microsoft Technology Licensing, Llc Techniques to provide proxies for web services
US9526091B2 (en) * 2012-03-16 2016-12-20 Intel Corporation Method and apparatus for coordination of self-optimization functions in a wireless network
US9820259B2 (en) 2012-05-04 2017-11-14 Qualcomm Incorporated Smooth transition between multimedia broadcast multicast service (MBMS) and unicast service by demand
US20140199044A1 (en) 2013-01-15 2014-07-17 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
US9674251B2 (en) 2013-06-17 2017-06-06 Qualcomm Incorporated Mediating content delivery via one or more services
US10560509B2 (en) 2013-07-05 2020-02-11 Qualcomm Incorporated Method and apparatus for using HTTP redirection to mediate content access via policy execution

Also Published As

Publication number Publication date
JP6231583B2 (ja) 2017-11-15
JP2016510460A (ja) 2016-04-07
CN105284093B (zh) 2019-09-10
EP2946542B1 (en) 2016-12-28
KR20150107837A (ko) 2015-09-23
HUE031896T2 (en) 2017-08-28
BR112015016989B1 (pt) 2023-02-14
WO2014113383A1 (en) 2014-07-24
KR101847585B1 (ko) 2018-04-10
EP2946542A1 (en) 2015-11-25
US20140201323A1 (en) 2014-07-17
US20140199044A1 (en) 2014-07-17
US10015437B2 (en) 2018-07-03
CN105284093A (zh) 2016-01-27
BR112015016989A2 (pt) 2017-07-11

Similar Documents

Publication Publication Date Title
ES2630279T3 (es) Soporte para diversidad de transportes y memorias intermedias desplazadas en el tiempo para la transmisión continua de medios sobre una red
ES2702103T3 (es) Mediación en la entrega de contenidos mediante uno o más servicios
ES2635082T3 (es) Método, aparato y dispositivo terminal para compartir contenidos de televisión en protocolo Internet
ES2784605T3 (es) Entrega de middleware de métricas de QOE del cliente dash
ES2574805T3 (es) Métodos para cambiar entre una descarga de MBMS y una entrega basada en HTTP de contenido con formato DASH a través de una red de IMS
US10193994B2 (en) Signaling cached segments for broadcast
ES2864645T3 (es) Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios
ES2848116T3 (es) Transmisión basada en formato de archivo con formatos DASH basados en LCT
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
JP6746582B2 (ja) メディアコンテンツストリーミング
ES2550949T3 (es) Gestión de canal de medios
JP5930429B2 (ja) ファイル配信方式を使用したｉｐブロードキャストストリーミングサービスの配信
ES2719819T3 (es) Sistema y procedimiento para adaptar comunicaciones de vídeo
CN113179255B (zh) 用于dash中的一般化http头的系统和方法
ES2764224T3 (es) Robusto funcionamiento en vivo de DASH
BR112014013006B1 (pt) Dispositivo e método para obter conteúdo por pelo menos dois protocolos de transporte tendo diferentes requisitos em termos de largura de banda de rede disponível
ES2865448T3 (es) Procedimiento de gestión de pérdidas de paquetes en transmisiones basadas en la norma dash y el protocolo flute
BR112012005106B1 (pt) Método e dispositivo para distribuir um fluxo multiplexado de multimídia através de uma rede, e método e dispositivo para receber um fluxo multiplexado de multimídia através de uma rede
JP6418665B2 (ja) Ｉｍｓベースのｄａｓｈサービスにおいて、プレゼンスサーバによりプレゼンス情報を供給する方法、および、プレゼンスサーバを介してプレゼンス情報を受信するユーザ機器（ｕｅ）
US20220239601A1 (en) Background data traffic distribution of media data
US11089442B2 (en) System and method for dynamically switching eMBMS services
KR20170140066A (ko) MBMS(Multimedia Broadcast/Multicast Service) 수신기 및 그의 멀티캐스트 신호 수신 방법
Belda et al. Multimedia system for emergency services over tetra-dvbt networks
WO2022164862A1 (en) Background data traffic distribution of media data
KR20170140067A (ko) MBMS(Multimedia Broadcast/Multicast Service) 수신기 및 그의 멀티캐스트 신호 수신 방법