RETROALIMENTACION DE PLANEACION DE CLIENTE DURANTE SESIONES DE TRANSFERENCIA DE FLUJO
CAMPO DE LA INVENCIÓN La presente invención se refiere, de manera general, a servicios de transferencia de flujo de Radiodifusión Multimedia/Servicio de Multidifusión (MB/MS) . De manera más específica, la presente invención se refiere a mecanismos para la planeación y el transporte de una retroalimentación limitada de usuario durante la sesión de transferencia de flujo MB/MS.
ANTECEDENTES DE LA INVENCIÓN Se pretende que esta sección proporcione un antecedente o contexto. La descripción en la presente podría incluir conceptos que pudieran ser adaptados, aunque no necesariamente los que han sido previamente concebidos o adaptados. Por lo tanto, a menos que se indique de otro modo' en la presente, lo que se describe en esta sesión no es la técnica anterior a las reivindicaciones en esta solicitud y no se admite que sea la técnica anterior mediante la inclusión en esta sección. Los servicios de transferencia de flujo de
Radiodifusión Multimedia/Servicio de Multidifusión (MB/MS) facilitan el suministro eficiente de recursos de contenido REF. 187659
popular en tiempo real a los múltiples receptores en un entorno móvil 3G. En lugar de utilizar diferentes portadores de punto-a-punto (PtP) para suministrar el mismo contenido a distintos entornos móviles, un portador único de punto-a-múltiples puntos (PtM) es utilizado para suministrar el mismo contenido a diferentes móviles en una celda dada. El contenido transferido podría consistir de video, a audio, SVG, texto de tiempo y otros medios soportados. El contenido podría ser previamente grabado o generado a partir de una alimentación directa. Una diversidad de propósitos ha sido realizada para el suministro de procedimientos, que incluyen la reparación PtP después de una sesión de descarga de archivo y los reportes de verificación de suministro de contenido después de las sesiones de descarga o transferencia de flujo. En el caso de las sesiones de descarga, los reportes de verificación de suministro de contenido podrían contener detalles de archivos descargados en forma exitosa. En el caso de sesiones de transferencia de flujo, los reportes de verificación de suministro de contenido contienen métricas QoE. La solicitud de patente de los Estados Unidos No. 10/782,371 titulada "DATA REPAIR" presentada en 18 de Febrero del 2004, que tiene el mismo firmante que la presente solicitud, y que se incorpora en la presente como referencia, describe un mecanismo para la reducción de la sobrecarga de
red provocada por las peticiones de reparación PtP y los reportes simultáneos de verificación de suministro de contenido. Se recomienda el uso de una selección de servidor aleatorio de reparación y tiempo aleatorio de respaldo. También define la señalización de los parámetros asociados, es decir, el tiempo máximo de respaldo y una lista de servidores que manejan los reportes de reparación o verificación. Sin embargo, ninguno de estos mecanismos propuestos trata con la retroalimentación de usuario durante la sesión de transferencia de flujo MBMS. La retroalimentación de usuario durante la sesión de transferencia de flujo de radiodifusión/multidifusión es una característica deseable que puede facilitar la programación interactiva en TVs móviles o terminales MBMS. Sin embargo, las actuales especificaciones MBMS no detallan los mecanismos para la retroalimentación de usuario durante las sesiones de transferencia de flujo MBMS. La retroalimentación simultánea de usuario a partir de múltiples clientes MBMS puede originar problemas de implosión de retroalimentación en el servidor y podría sobrecargar/bloquear los recursos de red. Por lo tanto, existe la necesidad de mecanismos de planeación y transporte de retroalimentación limitada de usuario durante la sesión de transferencia de flujo MBMS. Además, existe la necesidad de información relevante de señalización para la planeación de la retroalimentación de
cliente durante las sesiones de transferencia de flujo de radiodifusión y multidifusión.
SUMARIO DE LA INVENCIÓN De manera general, la presente invención se refiere a una retroalimentación que puede ser escalada durante las sesiones de transferencia de flujo de punto-a-múltiples puntos (PtM) . La retroalimentación de usuario durante una sesión de transferencia de flujo de radiodifusión/multidifusión es una característica deseable que puede facilitar la programación interactiva en TVs móviles o terminales MBMS. Esta retroalimentación puede incluir por ejemplo lo siguiente: (1) espectadores de TV móvil que votan durante los programas de realismo asombroso, (2) cambiar el contenido de la siguiente sesión de transferencia de flujo en base a los votos recibidos durante la actual sesión de transferencia de flujo, y (3) animación en el contenido SVG (los gráficos de vector que puede ser escalados) que incita la interacción de usuario en donde las necesidades de respuesta de usuario serán enviadas al servidor dentro de un cierto tiempo. Una modalidad de ejemplo se refiere a un método de suministro de una retroalimentación que puede ser escalada durante las sesiones de transferencia de flujo de punto-a-múltiples puntos (PtM) . El método puede incluir la
comunicación de los datos de un emisor al menos hacia un receptor y la comunicación de retroalimentación al menos de uno por lo menos de un receptor al emisor durante la sesión de transferencia de flujo multimedia. Otras modalidades de ejemplo se refieren a sistemas, programas de computadora y dispositivos que proporcionan una retroalimentación que puede ser escalada durante sesiones de transferencia de flujo PtM.
BREVE DESCRIPCIÓN DE LAS FIGURAS La Figura 1 es un diagrama que ilustra un escenario de transmisión de datos de uno-a-muchos de acuerdo con una modalidad de ejemplo. La Figura 2 es un diagrama que ilustra el significado de los parámetros 'waitTime' y ^maxBackOff de acuerdo con una modalidad de ejemplo. La Figura 3 es un diagrama que ilustra un dispositivo de recepción de acuerdo con una modalidad de ejemplo . La Figura 4 es un diagrama que ilustra un dispositivo de emisión de acuerdo con una modalidad de ejemplo.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La Figura 1 ilustra un escenario de transmisión de
datos de uno-a-muchos de acuerdo con una modalidad de ejemplo. El dispositivo de emisión 10 es un dispositivo servidor baeado en IP, un diepositivo DVB, un dispositivo GPRS (o UMTS) o un dispositivo similar que podría utilizar una corrección proactiva de error hacia adelante, tal como un mecanismo ALC (codificación asincrónica de capas) y/o un mecanismo FEC (conexión de error hacia adelante) , para el envío de bloques de datos de multidifusión (o paquetes) a los dispositivos de recepción 20 en un modo de uno-a-muchos. Cada dispositivo de recepción 20 envía mensajes de reconocimiento negativo (NACK) (o peticiones) al dispositivo de emisión 10 que se refieren a los bloques faltantes (los bloques no recibidos o recibidos de manera incorrecta) . En respuesta al mensaje(s) de reconocimiento negativo 'NACK', el dispositivo de emisión 10 generalmente vuelve a transmitir los bloques faltantes al dispositivo de recepción 20 en una sesión FLUTE (suministro de archivo a través de transporte en una dirección) (la misma sesión que la sesión original FLUTE establecida para la transmisión original, o una subsiguiente sesión FLUTE) . En forma alterna, puede utilizarse una sesión que utiliza otro protocolo diferente de FLUTE. Los datos son transferidos del emisor 10 al receptor (es) 20 como objetos. Por ejemplo, un archivo, una imagen JPEG, una división de archivo todos son objetos. Una sesión es establecida entre el dispositivo de emisión 10 y el
dispositivo (s) de recepción 20 para el suministro de archivo
(o datos) . Una seeión única podría incluir la tranemieión de un objeto único o de múltiples objetos. Distintos identificadores son utilizados para reconocer los objetoe y lae eesiones. Cada bloque de datos tiene un número llamado número de bloque de origen (SBN) o similares, el cual identifica cada bloque. Los bloques son representados por un conjunto de símboloe de codificación. A su vez, un identificador de símbolo de codificación (ESI) o similares, indica como los símbolos de codificación llevados en la carga útil del paquete de datoe (o bloque) fueron generados a partir del objeto mencionado con anterioridad (por ejemplo, el archivo) . Las modalidades de ejemplo proporcionan una retroalimentación que puede ser escalada durante las seeiones de transferencia de flujo de punto-a-múltiples puntos (PtM) . Estas modalidades de ejemplo pueden ser implementadas utilizando las extensiones de retroalimentación conducida de aplicación/contenido con los procedimientos asociados de suministro en los soportes de retroalimentación MBMS, y RTCP. La siguiente es una implementación de ejemplo de retroalimentación conducida de aplicación/contenido. Si el contenido de transferencia de flujo PtM requiriera la retroalimentación de usuario durante la sesión, entonces, el servidor PtM describiría los parámetros relacionados fuera de
banda (por ejemplo, en el archivo SDP que corresponde con los procedimientos asociados de suministro) . Un conjunto mínimo de estos parámetros incluye (1) un conjunto de URIs de los servidores que colectan la retroalimentación y (2) un tiempo máximo de respaldo para la dispersión aleatoria de tiempo ( 'maxBackOff ' ) . Durante la sesión de transferencia de flujo MBMS, una aplicación de cliente o una animación SVG podría animar la entrada de usuario, por ejemplo, seleccionar si/no, seleccionar la mejor, clasificar las tres más altas, etcétera. La aplicación colecta la entrada de usuario tan pronto como sea proporcionada (es decir, en time= ' feedback_time ' ) y la almacena en una memoria intermedia para un transporte programado hacia el servidor de colección de retroalimentación. El programador de transporte en el cliente genera un número aleatorio 'X' entre '0' y 'maxBackoff ' . Posteriormente, calcula
Actual_transport_time=feedback_time + X. Un servidor de colección de retroalimentación es elegido en forma aleatoria a partir del conjunto de URIs señalizadas por anticipación en SDP. Cuando current_time= ' actual_transport_time ' , sea establecido, una conexión TCP con la URI es seleccionada en forma aleatoria. La respuesta de usuario es embebida en un objeto XML que es enviado utilizando el método HTTP POST. La retroalimentación de usuario puede ser formateada
en un objeto XML. El objeto XML incluye loe parámetroe necesarios para identificar la retroalimentación, la seeión de traneferencia de flujo y la ID de cliente. La retroalimentación eepecífica por aplicación es incluida en el objeto XML mediante las extensiones de eepecificación en el eequema correepondiente XML. La retroalimentación de ueuario durante la sesión de transferencia de flujo MBMS puede ser proporcionada a través de las extensionee eimples del esquema XML definido en MBMS para los procedimientos asociados de euminietro. Lo siguiente es una implementación de ejemplo de las extensionee hacia loe procedimientoe aeociadoe de euminietro en MBMS. Un nuevo elemento de tipo userFeedbackType es introducido en el esquema XML que corresponde con el 'Associated Delivery Procedures' como se mueetra en el código de muestra más adelante. El elemento(s) requerido 'eerverURI' especifica las URIs de la lista de servidoree que colecta la retroalimentación de loe clientes. La Figura 2 ilustra la definición de los parámetros ' aitTime' y 'maxBackOff. Despuée de la colección de la retroalimentación, el cliente eepera lae unidadee de tiempo 'waitTime' y genera un número aleatorio 'X' entre '0' y 'maxBackOff ' . Deepués envía la retroalimentación después de esperar más unidades de tiempo 'X'. La retroalimentación es enviada en forma confiable utilizando HTTP/TCP.
«¡tanl vßBioip"I.O" enood¡ng-l,UTF-B"7> <xs:síhema «ntnsms="http-y w\v.w3.orB/2001/XMLSchema'' elementF?fmDefault="qualified, W?lanenínane^-tBociat<rfP-Dcedu?eD^ <ß:coaflexType namrI'as!?clate Pít>eedureTypc''> <mequence> Ots'.elonent ?iame=,"?o?ffileRe?nir" l pe="baslcProcedu?eType" minOcconEa0l, axOcc??iF3" 5s:element pameJ,bmFfleRq)alr, type=" bmPileRepai?T pß', minOccure="0* p??Occopa"l,/> 5 <m:e)emept nam^postRcceptionRqxut" type="repQrtProce areType"m¡nOccur»="0'' pwxOccup="l 7> <w:element níD»=*u!HFe?dbackRepo?t" typr^cßdbaeld'roce ?ueType'p?inOcGupp'0' mnxOccure="l"/> </xsr$equence> <?a:complßfl' pe> <?j:co?nplexType
Oasequenco <w:clement na ^tavcrURT t pew"»:anyURF mlnOcw?s="l" maxOccurF??nboanded' > <?(s:sequencí
<xs:attributename^maxBackOfTtype^s:ur?signe(ILM <?ß:complexType>
<?a:comple)( ypc
<xs:complexType nam^?epai?P.ocedurcT pe > <w.5lmpleContenP i c <x?:ßrtH»ion b8SF>*basicProcedureTypen> «WBttribute <w:ßttribute
<?a:ßt-en?lcp>
•report-lM-e" vplue= "raelt" || "rtai" |) "ilar-oll"
<xs:co ?lexType Dap?^,uscrFcedbßG Procedupfrypen> ^ <x?:?¡mp1eC?ntent> ocrcxtcnsion
<x?:a tribate ??mcp"fMdbodc eportType" type *xnstring" use=^opiíop??l' > </xí:exten?ion> <t?s:slmpleOmtent> <?u:complexType
<?cs:schßma>
ftedbackRßportType- {' ßsNo,, P,te?tOne"||,4ranldngM)
El eervidor de transferencia de flujo MBMS decide colectar ciertos tipos de retroalimentación durante la seeión de transferencia de flujo MBMS. Los ejemploe del tipo de retroalimentación pueden eer 'Yes/No vote', 'Best among a group of ítems (A/B/C/..) ', ' Ranking ', etcétera. La aplicación de cliente colecta el tipo adecuado de retroalimentación en los instantes requeridos de tiempo. La aplicación de cliente formatea la retroalimentación en objetos XML que serán traneportadoe en forma subsiguiente utilizando un método HTTP POST. El usuario podría proporcionar el mismo tipo de retroalimentación en múltiplee instantes de tiempo durante una sesión de transferencia de flujo MBMS. El objeto XML que corresponde con la retroalimentación de cliente podría contener algún medio de identificación única de cada retroalimentación, tal como por ejemplo, el correspondiente reloj fechador en el instante de tiempo en el cual fue colectada la retroalimentación de cliente. En algunas otras modalidadee, un contador de retroalimentación podría eer utilizado para permitir el seguimiento de varios ejemploe de retroalimentación. Otra información útil tal como clientID, eerverURl etc., eon incluidas de manera opcional en el objeto XML que corresponde con
la retroalimentación de usuario. El esquema XML que corresponde con cada tipo de retroalimentación puede ser definido como se muestra en el siguiente código de muestra. La aplicación de cliente formatea la retroalimentación en objetos XML que utilizan eete eequema XML.
<?xml
encodipg "UTF-8"?> <xs:schema xmlns:xs="http://w .w3.org/2001/XMLSche a" elementFopnDefault="qualif.ed"> xs:element
« cs:choice> <xs:element
<xs:elemßnt name="bestA?nongAGroup" type="bestOneType"
<Xs:eleraent
xs:choice> ?s:ßlemetrt
<xs:complexTpe name=nyesNo'iype"> xs:5equence> <xs:element
maxOccurs="ln/> <5cs:e)eme--t napi£F:nti?neStBp?pn
p.axOccursa"l'7> <5.s:attribute
use-"opt¡onal"/> <5.s:attribute
<?s:attribute name="serviceld" type^'xsistripg" use="optíonal"/ <xs:attribute <xs:attríbute
<xs:sequencß ?cs:complßxType>
<5c5:co pleocType Dame=MbestOneType"> xs:simpleContept> <xs:element name="bestOpeVote" tpe"xs:tiriagn minOccura^O" maxOccurs^'l"^ <xs:element name="tímeSta?pp1' typea>nxs:stringn punOccurB="0" maxOccurs=T <xs:atttibute
xs:attribute na-nes"sessionT pe"
<xs:attribute pa_ne,="ser?iceldn typ&=nx&stiiag" usß""optlonal"> <Xs:attribute
use»"optíonal"> <Xs:attribute name""sßrv ßrtRI"
<xs:si pleContept>
<y?s:complexTpe> <Xs:co plßxT pß
<5c5:5ÍmpleCopt?pt>
<5s:elemepl <xs:attribute
<xs:attribute
type-"xs:stripg" usß"poptional"> <xs:attributß name-"serviceld''
<Xs:attríbute
x5:5ÍmpleContent>
X8;complexType> ^xs:complex1 pe> < xs:schema
Los objetos XML que corresponden con múltiples ejemplos de retroalimentación podrían ser agregados utilizando una estructura MIME de múltiples partes. El siguiente es un ejemplo de una implementación de reportes de retroalimentación RTCP (protocolo de control en tiempo real) . Un emisor que solicita retroalimentación a partir de una pluralidad de receptores, por medio del envío de un aviso de retroalimentación en un canal de anuncio de servicio (SDP, XML, FLUTE, etc.) fuera de banda en una dirección de enlace descendente, o dentro de banda en una dirección de enlace deecendente dentro del flujo RTP o RTCP (por ejemplo, utilizando una exteneión de encabezado RTP con un campo apropiado o con un paquete RTCP APP con una exteneión con un campo adecuado) . El campo contiene un indicador de retroalimentación (que indica que es solicitada la retroalimentación), y de manera opcional, un indicador de tiempo (que señala cuando ee requerida la retroalimentación) , y un número que indica la fracción de receptores que son requeridos para enviar la retroalimentación. Los receptores extraen un número aleatorio y si el número fuera menor o igual que el número que indica la fracción de receptores (recibidos por el emisor) , envía un
reporte RTCP (o cualquier otro reporte de calidad) en forma inmediata o utilizando la regla de sincronización que es comunicada por el emisor a los receptoree . La Figura 3 ilustra un dispoeitivo de recepción 20 de acuerdo con una modalidad de ejemplo. Un eietema de comunicación incluye un dispositivo de emisión 10, una red de transmisión 30, por ejemplo, una red IP u otra red fija, una red inalámbrica o una combinación de una red fija y una red inalámbrica (celular), etc., y el dispoeitivo de recepción 20. El dispositivo de recepción 20 puede ser un teléfono celular, un teléfono satelital, un asietente digital pereonal o un diepositivo Bluetooth, un dispositivo WLAN, un dispositivo DVB, u otro dispositivo similar inalámbrico. El dispositivo 20 incluye una memoria interna 21, un procesador 22, un sistema operativo 23, programas de aplicación 24, una interfaz de red 25 y un mecanismo de reconocimiento negativo
' NACK ' y de reparación 26. La memoria interna 21 acomoda el procesador 22, el sietema operativo 23 y loe programae de aplicación 24. El mecanismo de reconocimiento negativo ' NACK ' y de reparación 26 permite los procedimientos de reconocimiento negativo '?ACKing' y de reparación en respuesta a la falta de datos o los datos deformados en una transmisión de datos. El dispositivo 20 es capaz de comunicarse con el dispositivo de emisión 10 y otros diepositivos a través de la interfaz de red 25 y la red 30.
La Figura 4 ilustra el dispositivo de emisión 10 de acuerdo con una modalidad de ejemplo. El dispoeitivo de emisión 10 puede ser por ejemplo, un servidor de red o cualquier dispoeitivo adecuado que ee pretende utilizar para el suministro de archivo (o medios) . El dispoeitivo 10 incluye una memoria interna 11, un proceeador 12, un sistema operativo 13, programas de aplicación 14, una interfaz de red 15, un mecanismo de tranemieión y reparación 16 y un almacenamiento de datoe 17. La memoria interna 11 acomoda el proceeador 12, el sistema operativo 13 y los programas de aplicación 14. El mecanismo de tranemieión y reparación 16 permite la transmisión de loe paquetes de datos al diepoeitivo (e) de recepción 20. Ademáe, permite la retranemisión de paquetes de datos en sesionee de reparación. Los datos que serán enviadoe a los dispositivos de recepción 20 y los datos que serán retransmitidos pueden ser guardados en el almacenamiento de datos 17. En forma alterna, los datos pueden ser guardados en un diepoeitivo eeparado co-eituado con o fuera del dispositivo de emisión 10. El dispositivo 10 es capaz de comunicarse con el dispositivo de recepción 20 y otros dispositivos por medio de la interfaz de red 15 y la red 30. Mientras que varias modalidades de la invención han sido deecritas, se entenderá que modificaciones y cambios se les ocurrirán a aquellas personae expertae en la técnica a la
cual pertenece la invención. En coneecuencia, lae reivindicacionee adjuntae a eeta eepecificación ee pretende que definen la invención con precieión. Se hace conetar que con relación a eeta fecha el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que reeulta claro de la presente descripción de la invención.