ES2359762T3 - Método para transmitir y recibir mensajes de notificación y aparato para ello. - Google Patents
Método para transmitir y recibir mensajes de notificación y aparato para ello. Download PDFInfo
- Publication number
- ES2359762T3 ES2359762T3 ES08172936T ES08172936T ES2359762T3 ES 2359762 T3 ES2359762 T3 ES 2359762T3 ES 08172936 T ES08172936 T ES 08172936T ES 08172936 T ES08172936 T ES 08172936T ES 2359762 T3 ES2359762 T3 ES 2359762T3
- Authority
- ES
- Spain
- Prior art keywords
- notification
- notification messages
- rtp
- information
- flute
- 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
Links
- 238000000034 method Methods 0.000 title claims description 34
- 230000009471 action Effects 0.000 description 118
- 230000032258 transport Effects 0.000 description 50
- 238000010586 diagram Methods 0.000 description 30
- 230000002596 correlated effect Effects 0.000 description 26
- 238000004891 communication Methods 0.000 description 14
- 238000011084 recovery Methods 0.000 description 13
- 230000005540 biological transmission Effects 0.000 description 8
- 238000012217 deletion Methods 0.000 description 8
- 230000037430 deletion Effects 0.000 description 8
- 238000005538 encapsulation Methods 0.000 description 6
- 230000002452 interceptive effect Effects 0.000 description 6
- 230000007704 transition Effects 0.000 description 6
- 230000000875 corresponding effect Effects 0.000 description 5
- 238000013507 mapping Methods 0.000 description 5
- 230000001960 triggered effect Effects 0.000 description 5
- 238000001914 filtration Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000013467 fragmentation Methods 0.000 description 3
- 238000006062 fragmentation reaction Methods 0.000 description 3
- 102100037124 Developmental pluripotency-associated 5 protein Human genes 0.000 description 2
- 101000881848 Homo sapiens Developmental pluripotency-associated 5 protein Proteins 0.000 description 2
- 101000864093 Mus musculus Developmental pluripotency-associated protein 5A Proteins 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000009849 deactivation Effects 0.000 description 2
- 239000012092 media component Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
-
- 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- 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/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Radar Systems Or Details Thereof (AREA)
Abstract
Aparato de recepción de mensajes de notificación que comprende: un desencapsulador (120) de protocolo de internet (IP), configurado para desencapsular un paquete IP que transporta mensajes de notificación sobre una red: un decodificador (130) de protocolo datagrama de usuario (UDP), configurado: - para decodificar el paquete IP desencapsulado según un UDP; y - para sacar un paquete de protocolo de transporte en tiempo real (RTP); un decodificador (140) RTP, configurado: - para decodificar el paquete RTP; - para adquirir, desde el paquete RTP, una primera información que describe un tipo de notificación de cada uno de entre una pluralidad de mensajes de notificación y una segunda información que indica que los datos de la pluralidad de los mensajes de notificación están agregados dentro de una única carga útil en el paquete RTP; y - para sacar la pluralidad de los mensajes de notificación según la información adquirida.
Description
La presente invención se refiere a un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de transmisión/recepción de mensajes de notificación en un sistema de comunicación y difusión.
En los campos de comunicación y difusión, el término “contenido” o “contenidos” representa contenidos o información que incluyen una imagen, un sonido y texto entregado al usuario sobre redes de comunicación y difusión por cable/inalámbricos. Según técnicas recientes, los contenidos digitales con proporcionados en varios canales de emisión y canales interactivos. Por ejemplo, el usuario puede descargar contenidos ya difundidos, para ver los contenidos. Según la reciente incorporación de un sistema de difusión y un sistema de comunicación, los mismos contenidos podrían ser proporcionados desde el sistema de difusión o el sistema de comunicación. Por ejemplo, se ha propuesto un sistema de difusión de video digital (Digital Video Broadcasting, DVB). El sistema DVB es un sistema en el que un sistema de difusión digital, basado en un sistema grupo 2 de expertos en imágenes en movimiento (Moving Picture Experts Group-2, MPEG-2), incluye un sistema de comunicación basado en protocolo de Internet (Internet Protocol, IP). Usando el sistema DVB, es posible acceder a contenidos deseados sobre un canal de difusión o un canal de comunicación, y, de esta manera, comprar los contenidos o adquirir toda la información de servicios asociados con los contenidos.
Un servidor que proporciona servicios asociados con los contenidos informa al usuario de una situación inesperada o un cambio en los detalles de servicio, sobre las redes de difusión y comunicación, usando un mensaje. En adelante, en esta memoria, dicho mensaje que notifica de la información indicada anteriormente será referido como “mensaje de notificación”. Aquí, “notificación” significa la transmisión del propio mensaje de notificación.
Consiguientemente, la presente invención está dirigida a un procedimiento de transmisión y recepción de un mensaje de notificación que evite sustancialmente uno o más problemas debidos a limitaciones y desventajas de la técnica relacionada.
Un objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de entregar eficientemente un mensaje de notificación. Un objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de transmitir y recibir información descriptiva que describe cada uno de los mensajes de notificación, cuando se transmite la pluralidad de mensajes de notificación.
Otro objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de anunciar fácilmente un mensaje de notificación a un receptor.
Otro objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de proporcionar una notificación.
Consiguientemente, la presente invención está dirigida a un procedimiento de transmisión y recepción de un mensaje de notificación que evita sustancialmente uno o más problemas debidos a limitaciones y desventajas de la técnica relacionada.
El documento US2007/086465 y la publicación "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols" vol 1.2.1, 1 publicada el 12 de Diciembre de 2006, son ejemplos de realizaciones de la técnica anterior.
Un objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de entregar eficientemente un mensaje de notificación. Un objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de transmitir y recibir información descriptiva que describe cada uno de los mensajes de notificación, cuando la pluralidad de mensajes de notificación son transmitidos tal como se indica en las reivindicaciones 1, 6 y 11.
Otro objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de anunciar fácilmente un mensaje de notificación a un receptor.
Otro objeto de la presente invención es proporcionar un procedimiento de transmisión/recepción de mensajes de notificación y un aparato de recepción de mensajes de notificación que sean capaces de proporcionar un mensaje de notificación en un tiempo apropiado sin un incremento en el ancho de banda de transmisión.
Las ventajas, objetos y características adicionales de la invención se expondrán, en parte, en la descripción siguiente y, en parte, serán evidentes, para las personas con conocimientos ordinarios en la materia, tras un examen de lo expuesto a continuación, o puede ser aprendido con la práctica de la invención. Los objetivos y otras ventajas de la invención pueden realizarse y conseguirse mediante la estructura indicada particularmente en la descripción por escrito y en las reivindicaciones, así como en los dibujos adjuntos.
Ventajosamente, el aparato de recepción de mensajes de notificación comprende además una entrega de ficheros sobre un decodificador de transporte unidireccional (FLUTE) configurado para decodificar los datos obtenidos mediante la decodificación según el UDP, según un FLUTE, un segundo analizador de notificación configurado para analizar los mensajes de notificación desde un fichero obtenido mediante la decodificación según el FLUTE, un analizador de contenedor configurado para analizar un contenedor de datos incluido en el fichero decodificado según el FLUTE, un analizador de guía de servicios configurado para analizar la información de la guía de servicios, incluida en el contenedor analizado, y un controlador de información de guía de servicios, configurado para proporcionar los mensajes de notificación según la información de guía de servicios analizada.
En otra realización, el aparato de recepción de mensajes de notificación comprende además un demultiplexador de flujo de transporte configurado para demultiplexar una señal de difusión que transporta información de descripción de servicios sobre la red, y un decodificador de información de descripción de servicios, configurado para decodificar la información de descripción de servicios, demultiplexada por el demultiplexador de flujo de transporte, y para decodificar una información de anuncio de mensaje de notificación por defecto de red (Network Default Notification, NDN) desde una tabla de información de red (Network Information Table, NIT), incluida en la información de descripción de servicios.
En una realización, el controlador de información de guía de servicios está configurado para proporcionar un mensaje de notificación por defecto de guía de servicios analizado por el segundo analizador de notificación.
Ventajosamente, el aparato de recepción de mensajes de notificación comprende además una pantalla configurada para proporcionar un mensaje de notificación por defecto de plataforma, analizado por el primer analizador de notificación.
La invención se refiere también a un procedimiento de transmisión de mensajes de notificación que comprende la generación de una pluralidad de mensajes de notificación a ser entregados sobre una red, insertar la pluralidad de mensajes de notificación generados en una carga útil de protocolo de transporte en tiempo real (Real-Time Protocol, RTP), y generar un paquete RTP que incluye información que describe un tipo de notificación de cada uno de entre la pluralidad de mensajes de notificación en la carga útil RTP y encapsular en protocolo de internet (Internet Protocol, IP) el paquete RTP generado, y transmitir el paquete encapsulado en IP sobre la red.
En una realización, el procedimiento de transmisión de mensajes de notificación comprende además insertar la pluralidad de mensajes de notificación generados en un objeto de transporte, según una entrega de ficheros sobre un transporte unidireccional (FLUTE) e insertar información que describe la pluralidad de mensajes de notificación en una tabla descriptora de ficheros (File Description Table, FDT), generar así datos FLUTE y transmitir los datos FLUTE generados.
Ventajosamente, el paquete RTP tiene una cabecera de formato de carga útil (Payload Format, PF) RTP que incluye información acerca de una pluralidad de acciones para cada uno de los mensajes de notificación e información que indica los tiempos en los cuales deben realizarse las acciones, respectivamente.
La invención se refiere también a un procedimiento de recepción de mensajes de notificación que comprende demultiplexar una señal recibida sobre una red, adquirir así un paquete de protocolo de transporte en tiempo real (RTP) desde un paquete de protocolo de Internet (IP) que transporta mensajes de notificación, decodificar el paquete RTP, adquirir, desde el paquete RTP, información que describe un tipo de notificación de cada uno de entre una pluralidad de mensajes de notificación en el paquete RTP y adquirir la pluralidad de mensajes de notificación desde la carga útil RTP, según la información adquirida, y recibir eventos de los mensajes de notificación según una información de acción de los mensajes de notificación adquiridos.
La invención se refiere también a un procedimiento de recepción de mensajes de notificación que comprende desencapsular un paquete IP que transporta mensajes de notificación sobre una red, decodificar una carga útil del paquete IP desencapsulado según un UDP, y sacar un paquete de protocolo de transporte en tiempo real (RTP), decodificar el paquete RTP para adquirir, desde el paquete RTP, información que describe un tipo de notificación de cada uno de entre una pluralidad de mensajes de notificación, cuando hay una pluralidad de mensajes de notificación en el paquete RTP, y analizar la pluralidad de mensajes de notificación según la información adquirida.
Ventajosamente, el paquete RTP incluye además información de identificación que indica si hay una pluralidad de mensajes de notificación en una carga útil del paquete RTP.
En una realización, el procedimiento de recepción de mensajes de notificación comprende además adquirir información de descripción de servicios desde la señal recibida sobre la red, decodificar una tabla de información de red (NIT), incluida en la información de descripción de servicios, y adquirir información de anuncio para los mensajes de notificación desde la NIT decodificada.
En otra realización, el paquete RTP tiene una cabecera de formato de carga útil RTP que incluye información acerca de una pluralidad de acciones para cada uno de los mensajes de notificación e información que indica los tiempos en los
que deben realizarse las acciones, respectivamente. Ventajosamente, el procedimiento de recepción de mensajes de notificación comprende además ejecutar cada uno de los mensajes de notificación según las acciones que corresponden respectivamente a los tiempos. Debe entenderse
que tanto la descripción general anterior como la descripción detallada siguiente de la presente invención son ejemplares y explicativas, y pretenden proporcionar una explicación adicional de la invención reivindicada. Los dibujos adjuntos, que se incluyen para proporcionar una comprensión adicional de la invención y que se incorporan
a la presente solicitud y constituyen una parte de la misma, ilustran realizaciones de la invención y, junto con la descripción, sirven para explicar el principio de la invención. En los dibujos: La FIG. 1 es un diagrama que ilustra una pila de protocolos capaz de transmitir y recibir un mensaje de notificación;
La FIG. 2 es un diagrama que ilustra un marco de notificación para transmitir y recibir un mensaje de notificación;
La FIG. 3 es un diagrama que ilustra una ruta sobre la que puede descubrirse un mensaje de notificación entregado
sobre una red de difusión;
La FIG. 4 es un diagrama que ilustra un descriptor capaz de acceder a un servicio de notificación por defecto;
La FIG. 5 es un diagrama que ilustra una tabla de información de red (NIT) incluida en la información de descripción
de servicios;
La FIG. 6 es un diagrama que ilustra un descriptor que describe una información de entrada de notificación por
defecto de red (NDN);
La FIG. 7 es una realización en la que un mensaje de notificación es mapeado o correlacionado en una entrega de
ficheros sobre un transporte unidireccional (FLUTE);
La FIG. 8 es un diagrama que ilustra una realización en la que una pluralidad de mensajes de notificación son
mapeados o correlacionados en un FLUTE;
La FIG. 9 es un diagrama que ilustra una realización en al que un mensaje de notificación es mapeado o
correlacionado en un RTP o en un RTP y un FLUTE;
La FIG. 10 es un diagrama que ilustra una realización en la que se entregan una pluralidad de mensajes de
notificación;
La FIG. 11 ilustra un ejemplo de una cabecera de formato de carga útil (PF) RTP;
La FIG. 12 es un diagrama que ilustra una información de identificador que representa que una pluralidad de
mensajes de notificación son transportados en una carga útil RTP;
La FIG. 13 es un diagrama que ilustra un identificador que representa que la carga útil RTP transporta una pluralidad
de mensajes de notificación;
La FIG. 14 es un diagrama que ilustra un ciclo de vida de un objeto de notificación;
La FIG. 15 es un diagrama que ilustra un ejemplo en el que se transmite un mensaje de notificación;
La FIG. 16 es un diagrama que ilustra un estado de una notificación según una acción;
La FIG. 17 es un diagrama que ilustra un ejemplo en el que un mensaje de notificación es descrito usando un
FLUTE;
La FIG. 18 es un diagrama que ilustra “NotificationAgregateDescriptionType” que describe un mensaje de
notificación que incluye una pluralidad de acciones e información temporal de las mismas;
La FIG. 19 es un diagrama que ilustra una cabecera RTP PF;
La FIG. 20 es un diagrama que ilustra una cabecera de extensión de carga útil RTP;
La FIG. 21 es un diagrama de flujo que ilustra una realización de un procedimiento de transmisión/recepción de
mensajes de notificación; y La FIG. 22 es un diagrama de bloques que ilustra una realización de un aparato de recepción de mensajes de notificación. Ahora, se hará referencia, en detalle, a las realizaciones preferentes de la presente invención, cuyos ejemplos se ilustran en los dibujos adjuntos. Cuando sea posible, se usarán los mismos números de referencia a lo largo de los
dibujos para hacer referencia a las mismas partes o a partes similares.
Un mensaje de notificación puede ser entregado a un receptor sobre una red de difusión. Cuando el receptor puede comunicarse con una red interactiva, el mensaje de notificación puede ser entregado al receptor sobre la red interactiva. El mensaje de notificación entregado al receptor sobre la red de difusión puede ser complementado mediante la red interactiva.
La FIG. 1 es un diagrama que ilustra una pila de protocolos capaz de transmitir y recibir un mensaje de notificación. Este dibujo ilustra un sistema de difusión de video digital (Digital, Video Broadcasting, DVB) como un sistema de difusión capaz de transmitir y recibir un mensaje de notificación.
En un protocolo que define un sistema terrestre/portátil de difusión de video digital (DVB-T/H), puede disponerse un protocolo que define un flujo de transporte tipo grupo 2 de expertos en imágenes en movimiento (Moving Picture Experts Group-2 Transport Stream, MPEG-2 TS). El MEPG-2 TS puede incluir datos según un esquema de división de tiempo o datos encapsulados en un esquema de encapsulación multiprotocolo (Multiprotocol Encapsulation, MPE) o un esquema de corrección de errores en avance para encapsulación multiprotocolo (MPE-FEC).
Puede disponerse un protocolo de Internet (IP) sobre el protocolo MPEG-2 TS. Puede disponerse un protocolo de control de transmisión (TCP) o protocolo de datagrama de usuario (UDP) sobre el protocolo IP. Un protocolo de transporte en tiempo real (RTP) o una entrega de ficheros unidireccional sobre un transporte unidireccional (FLUTE)/protocolo de codificación asíncrona por capas (ALC) puede ser dispuesto sobre el UDP.
Un mensaje de notificación puede ser clasificado según un procedimiento de acceso, tal como se indica a continuación.
Es decir, el mensaje de notificación puede ser clasificado en un mensaje según una notificación por defecto y un mensaje según una notificación seleccionada por el usuario.
La notificación por defecto representa el caso en el que un mensaje de notificación es entregado independientemente de si hay o no una selección de usuario.
El mensaje de notificación por defecto es entregado al usuario incluso cuando el usuario no está abonado a un servicio asociado. Por referencia, si el servicio es proporcionado por medio de una red interactiva, puede darse el caso en el que, incluso en la notificación por defecto, el usuario puede recibir un mensaje de notificación solo cuando se abone al servicio asociado.
La notificación por defecto puede incluir una notificación por defecto de red (NDN), una notificación por defecto de plataforma (PDN), y una notificación por defecto de guía electrónica de servicios (ESG) (EDN).
La NDN representa una notificación que se puede entregar a un nivel de red de un sistema de difusión o comunicación. La NDN puede ser entregada usando un señalamiento a nivel de red (por ejemplo, un señalamiento DVB-SI) y/o una sesión basada en IP. La NDN está relacionada con un mensaje asociado con una emergencia, tal como una noticia urgente, parada de la difusión y variación de la red.
La PDN es usada para entregar un mensaje asociado con una plataforma IP específica. Por ejemplo, la PDN puede representar un mensaje de notificación asociado con una variación en el formato de una plataforma.
La EDN representa una notificación asociada con servicios descritos en una guía electrónica de servicios (ESG). La EDN puede ser entregada sobre un carrusel ESG o un canal ESG dedicado. Por ejemplo, el mensaje EDN puede estar asociado con un proveedor de ESG o con servicios descritos en una ESG.
La notificación seleccionada por usuario representa una notificación que puede ser entregada al usuario cuando el mismo está abonado a un servicio asociado. La notificación seleccionada por usuario puede incluir mensajes asociados con servicios que pueden ser descubiertos en una ESG. La notificación seleccionada por usuario puede ser proporcionada bajo la condición en la que el usuario selecciona el componente de notificación y el servicio asociados.
La notificación seleccionada por usuario incluye una notificación relacionada con servicios. La notificación relacionada con servicios es una notificación relacionada con servicios específicos descritos en una ESG. Cuando la notificación relacionada con servicios es entregada usando una parte de una sesión de servicio, puede ser denominada como un mensaje de notificación relacionado con servicios en banda (iSRN).
Por otra parte, cuando la notificación relacionada con servicios es entregada usando una sesión de red dedicada a ESG, su entrega puede ser conseguida usando una sesión EDN sin una selección de un servicio específico. En este caso, la notificación relacionada con servicios puede ser denominada como un mensaje de notificación relacionada con servicios fuera de banda (oSRN).
La SRN requiere una subscripción al servicio asociado. En el caso de la iSRN, el servicio asociado es proporcionado según una sincronización precisa del mismo con un componente de medios de la sesión de servicio, cuando la iSRN es transmitida por medio de RTP. Por otra parte, en el caso de la oSRN, el servicio asociado es proporcionado sin una sincronización del mismo con un componente de medios, ya que la oSRN es entregada usando una sesión EDN.
Mientras, el servicio de notificación es un servicio asociado con la entrega de un mensaje de notificación descrito en una ESG. El servicio de notificación representa un servicio que puede estar descrito en una ESG según una subscripción a un servicio del usuario, por ejemplo, un servicio de noticias.
La FIG. 2 ilustra un marco de notificación para transmitir y recibir un mensaje de notificación.
El marco ilustrado incluye, por ejemplo, un nivel de servicios, un nivel de componentes, un nivel de canales y un nivel de protocolos. Los servicios del nivel de servicio pueden ser divididos en noticias de servicios seleccionados por usuario y servicios A/V incluidos (Rich A/V), y servicios por defecto que incluyen información de servicios de gestión ESG, información de servicios de gestión de plataforma y mensajes de emergencia.
En el nivel de componentes, “A” representa un componente de audio, “V” un componente de video, y “N” un componente de notificación. El nivel de canales incluye canales para entregar los componentes respectivos. Estos canales se designan mediante “A”, “V”, “EDN”, “iSRN”, “NDN”, “oSRN”, “PDN” y “NS”, respectivamente, y sus significados se describen en la parte inferior de la FIG. 2.
Las noticias pueden ser entregadas en un formato FLUTE sobre un canal de servicios de notificación (NS). El audio y el video del servicio Rich A/V pueden ser suministrados mediante RTP mediante canales A/V, y un N (componente de notificación) puede ser entregado mediante formato FLUTE o RTP sobre canales oSRN e iSRN.
La información de gestión de ESG puede ser entregada en un formato FLUTE sobre un canal EDN. La información de gestión de plataforma puede ser entregada en un formato FLUTE sobre una canal PDN. Un mensaje de emergencia puede ser entregado en un formato FLUTE o un formato de información de descripción de servicios de difusión sobre una NDN. Se ilustra un DVB SI como un ejemplo de la información de descripción de servicio.
La FIG. 3 ilustra una ruta en la que puede descubrirse un mensaje de notificación entregado sobre una red de difusión. Por ejemplo, se supone que una red 1 DVB incluye una plataforma-1 y una plataforma-2. Cada una de entre la plataforma-1 y la plataforma-2 puede ser, por ejemplo, una plataforma IP.
Un mensaje según una notificación por defecto de red puede ser transportado en una información de descripción de servicio de una red DVB, por ejemplo, información de especificación de programa/información de servicio (PSI/SI).
Por ejemplo, un canal de red por defecto puede ser descubierto a partir de un canal de arranque usado para descubrir una ESG. La información de descripción de servicio puede incluir información de arranque para un acceso de servicio. La información de arranque de cada plataforma puede transportar un mensaje de notificación por defecto de plataforma (PDN). Es decir, el arranque de cada plataforma puede anunciar una PDN. La PDN puede transportar también un mensaje NDN.
La información de arranque puede anunciar una ESG o una EDN a un receptor. Por ejemplo, una ESG-1 puede anunciar un servicio-2 (SRN) que transporta una notificación relacionada con servicios. La ESG-1 puede anunciar también un servicio-3 que proporciona un NS que transporta un servicio de notificación. La información de arranque puede anunciar también una EDN. Una ESG-2 puede anunciar un servicio-1 que transporta un NS.
De esta manera, el receptor puede descubrir un canal de notificación por defecto a partir del canal de arranque, a partir del cual puede descubrirse también una ESG. Un canal de notificación que entrega un mensaje relacionado con servicios descrito en una ESG puede ser descubierto a partir de la ESG, de manera similar a los canales relacionados con los servicios descritos en la ESG.
La FIG. 4 ilustra un descriptor capaz de acceder a un servicio de notificación por defecto. En este dibujo, el descriptor ilustrado está representado por “DefaultNotificationAccessDescriptor”. Un servicio PDN y al menos un servicio EDN pueden ser entregados sobre la misma plataforma IP. La información de arranque, que puede anunciar una ESG a un receptor, puede proporcionar información de entrada EDN y PDN, mediante el descriptor indicado anteriormente. Es decir, el descriptor ilustrado en el dibujo puede incluir información de adquisición de PDN asociada con la plataforma IP actual o información de adquisición de EDN asociada con información “ESGProviderID” acerca de un identificador de un proveedor de ESG específico indicado en un descriptor “ESGProviderDiscovery”, a partir del cual puede ser descubierto el proveedor de ESG.
En detalle, un campo “PDNFlag” indica si hay o no una PDN. Un campo “n_o_EDNEntris” indica el número de campos EDN.
PDNEntry() puede describir información de entrada PDN según el valor del campo “PDNFlag”. EDNEntry() puede describir información de entrada EDN según el valor del campo “n-o-EDNEntris”.
Mientras, la información de entrada NDN no puede entregada usando el descriptor ilustrado en la FIG. 4, diferente del caso de la FIG. 3. En adelante, se describirá una realización en la que se proporciona información de entrada NDN.
La FIG. 5 es un diagrama que ilustra una tabla de información de red (NIT) como un ejemplo de información de descripción de servicios. La información de entrada NDN puede ser incluida en la NIT. En adelante, se describirá la NIT.
Un campo “table_id” indica un identificador que identifica la NIT. Un campo “section_syntax_indicator” puede ser puesto a “1”. Este campo puede tener un formato de longitud MPEG. Un campo “reserved_future_use” y un campo “reserved”, que son campos no designados, pueden ser puestos a, por ejemplo, “1” y “11”, respectivamente. Un campo “section_length” indica la longitud de una sesión que es una unidad de entrega NIT.
Un campo “network_id” indica un identificador que identifica un sistema de entrega que entrega flujos de transporte de un servicio asociado. Por ejemplo, el campo “network_id” puede incluir información de identificación de un transmisor de difusión. Un campo “version_number” indica un número de versión de una sección o una sub-tabla. Un campo “current_next_indicator” indica si la información que sigue al campo “current_next_indicator” se aplica o no a la sección actual. Un campo “section_number” indica un número de serie de sección. Un campo “last_section_number” indica el número de una última sección.
Un campo “reserved_future_use” indica un campo no designado. Un campo “network_descriptors_length” indica la longitud de los descriptores que siguen al campo “network_descriptors_length”. Los descriptores pueden incluir un descriptor A que tiene información que hace posible describir una red asociada.
Un campo “transport_stream_loop_length” que sigue al campo no designado, concretamente, al campo “reserved_future_use”, indica la longitud de un bucle de flujo de transporte que sigue al campo “transport_stream_loop_length”.
Un campo “transport_stream_id” indica un identificador de flujo de transporte que identifica un flujo de transporte entregado por un sistema de comunicación, que entrega una señal de difusión actual, para distinguir el flujo de transporte de otros flujos de transporte entregados por otros sistemas de comunicación. Un “original_network_id” indica un identificador de red de un sistema de entrega original, que entrega servicios. Un campo “transport_descriptor_length” indica la longitud de un descriptor que sigue al campo “reserved_future_use”, que es un campo no designado. Este descriptor puede ser un descriptor B.
El descriptor B puede incluir un descriptor que describe información de entrada NDN. La información de entrada NDN se describirá más adelante.
La FIG. 6 ilustra un descriptor que describe una información de entrada NDN. Este descriptor puede ser referido como “NDNEntryDescriptor”. Este descriptor puede ser incluido en el campo descriptor B de la NIT ilustrada anteriormente.
Un campo “Descriptor_tag” indica un identificador que identifica el descriptor asociado. Un campo “descriptor_length” indica la longitud del descriptor en una unidad de bytes. Un campo “NDNEntryVersion” indica una versión de la información de entrada NDN. Por ejemplo, un valor del campo “NDNEntryVersion” puede ser puesto a “1”. Cuando no hay compatibilidad entre versiones de información de entrada, el valor del campo “NDNEntryVersion”, indicado anteriormente, se incrementa cuando hay una variación en la versión. El receptor puede decodificar solo la información de entrada NDN correspondiente al campo “NDNEntryVersion”.
Un campo “IPVersion6” indica una versión IP de la información de dirección que sigue al campo “IPVersion6”. Por ejemplo, cuando el campo “IPVersion6” tiene un valor de “1”, los valores de los campos “SourceIPAddress” y “DestinationIPAddress” se determinan según una versión 6 de IP. Por otra parte, si el campo “IPVersion6” tiene un valor de “0”, los valores de los campos “SourceIPAddress” y “DestinationIPAddress” se determinan según una versión IP 4.
Un campo “SourceIPAddress” y un campo “DestinationIPAddress” representan una dirección IP de origen y una dirección IP de destino de una sesión FLUTE que entrega un mensaje NDN, respectivamente.
Un campo “Port” indica un número de puerto de la sesión FLUTE que entrega el mensaje NDN. Un campo “TSI” indica un identificador de sesión de transporte de la sesión FLUTE.
Cuando una información de entrada NDN está incluida en una NIT, tal como se ha indicado anteriormente, el receptor puede adquirir la información de entrada NDN desde la información de descripción de servicio, concretamente, la NIT, y, de esta manera, puede recibir un mensaje NDN desde una sesión identificada usando la información de entrada adquirida.
En adelante, se describirá una realización en la que se entrega un mensaje de notificación. Los mensajes de notificación pueden ser entregados según los protocolos ilustrados anteriormente. En la descripción anterior, se ha descrito un ejemplo en el que los mensajes de notificación son entregados usando un RTP y un FLUTE definidos sobre una capa de transporte. La descripción siguiente se proporcionará en conjunción con un ejemplo en el que un mensaje de notificación es mapeado o correlacionado sobre una capa de transporte, para su entrega.
La información incluida en un mensaje de notificación está relacionada con una red que soporta un sistema de difusión de datos con protocolo de Internet (IPDC) (por ejemplo, una red DVB), una plataforma IP o servicios descritos en una ESG determinada.
Se describirá un formato de un mensaje de notificación, previamente a una descripción de un mapeo de un mensaje de notificación sobre una capa de transporte.
Un mensaje de notificación incluye una parte genérica de mensaje de notificación y una carga útil de notificación. La carga útil de notificación incluye una parte mensaje de notificación específica de aplicación y un objeto de medios.
Cuando los mensajes de notificación son mapeados o correlacionados sobre una capa de transporte, los mismos pueden ser divididos según unos atributos y una aplicación de notificación objetivo (por ejemplo, tamaño, tiempo, restricciones de sincronización, etc.), de manera que sus mensajes divididos puedan ser mapeados o correlacionados sobre diferentes protocolos de transporte, respectivamente. De manera similar, los mensajes de notificación pueden ser ordenados según unos atributos y una aplicación de notificación objetivo, de manera que puedan ser mapeados o correlacionados sobre diferentes protocolos de transporte. En el caso de mensajes de notificación que pueden ser entregados sin una restricción temporal, los mismos pueden ser mapeados o correlacionados sobre un FLUTE. Por otra parte, en el caso de unos mensajes de notificación que pueden ser entregados con una restricción temporal asociada con un flujo de audio o video, los mismos pueden ser mapeados o correlacionados sobre un RTP.
La FIG. 7 es una realización en la que un mensaje de notificación es mapeado o correlacionado sobre un FLUTE. En este caso, el mensaje genérico de notificación del mensaje de notificación puede ser mapeado o correlacionado sobre una instancia de tabla de descripción de ficheros (FDT) del FLUTE, mientras que la carga útil del mensaje de notificación puede ser mapeado o correlacionado sobre un objeto de transporte FLUTE del FLUTE.
Más de un mensaje de notificación pueden ser agregados dentro de un único objeto de transporte de un FLUTE, para una comunicación eficiente de los mismos.
La FIG. 8 ilustra una realización en la que una pluralidad de mensajes de notificación son mapeados o correlacionados en un FLUTE. Los mensajes de notificación agregados dentro de único objeto de transporte de un FLUTE son referenciados como “agregado de notificación”, y el objeto de transporte es referenciado también como “un objeto de transporte agregado FLUTE”. Las porciones comunes de las partes genéricas de los mensajes de notificación de los múltiples mensajes de notificación pueden ser mapeadas o correlacionadas en la instancia FDT del FLUTE, mientras que las porciones diferentes de las partes genéricas de los mensajes de notificación y las cargas útiles de los múltiples mensajes de notificación pueden ser mapeadas o correlacionadas en el objeto de transporte agregado FLUTE del FLUTE.
La instancia FDT del FLUTE puede describir el agregado de notificación transportado en objeto de transporte agregado FLUTE, en una manera individual para cada mensaje. Como alternativa, las partes comunes de todos los mensajes mapeados o correlacionados pueden ser descritas en la instancia FDT.
La FIG. 9 ilustra una realización en la que un mensaje de notificación es mapeado o correlacionado sobre un RTP o sobre un RTP y un FLUTE. Tal como se ha indicado anteriormente, un mensaje de notificación, que es entregado con una restricción temporal asociada con un flujo de audio o video, puede ser mapeado o correlacionado sobre un RTP. Por otra parte, en el caso de un mensaje de notificación que incluye una parte a entregar en sincronismo con un flujo de audio/video, y la parte restante a entregar sin sincronización, la parte sincronizada del mensaje puede ser mapeada o correlacionada sobre un RTP, mientras que la parte restante del mensaje puede ser mapeada o correlacionada sobre un FLUTE.
La parte superior de la FIG. 9 ilustra un ejemplo en el que un mensaje de notificación es mapeado o correlacionado sobre un RTP. En este caso, la parte genérica del mensaje de notificación puede ser mapeada o correlacionada sobre una cabecera de formato de carga útil (PF) de RTP y una carga útil de RTP, y la carga útil del mensaje de notificación puede ser mapeada o correlacionada sobre la partes restante de la carga útil de RTP.
La parte inferior de la FIG. 9 ilustra un ejemplo en el que una parte de un mensaje de notificación es mapeada o correlacionada sobre un RTP, y la parte restante del mensaje de notificación es mapeada o correlacionada sobre un FLUTE. En este caso, el mapeo del mensaje sobre el RTP es idéntico al procedimiento de mapeo de mensaje ilustrado en la parte superior de la FIG. 9, y el mapeo de mensaje sobre el FLUTE es idéntico al procedimiento de mapeo de mensaje indicado con referencia a las FIGS. 7 y 8.
La FIG. 10 ilustra una realización en la que se entregan una pluralidad de mensajes de notificación. En este caso, una pluralidad de mensajes de notificación pueden ser agregados dentro de una única carga útil de un RTP, para una entrega eficiente de los mismos.
Las porciones comunes de las partes genéricas de mensajes de notificación de los múltiples mensajes de notificación, pueden ser mapeadas o correlacionadas sobre una cabecera RTP PF del RTP, mientras que las partes restantes de los múltiples mensajes de notificación pueden ser mapeadas o correlacionadas sobre secciones respectivas o una parte índice de una carga útil agregada del RTP. En esta realización, cada una de las cabeceras RTP PF puede corresponder a cada uno de los múltiples mensajes de notificación de la carga útil RTP. Tal como se ilustra en esta figura, cuando el paquete RTP incluye una pluralidad de mensajes de notificación, la cabecera RTP PF que describe cada uno de los mensajes de notificación es incluida en el paquete RTP. Por ejemplo, la cabecera RTP PF puede incluir información de descripción, versión de mensaje de notificación, tipo de mensaje de notificación, etcétera, para cada uno de entre la pluralidad de mensajes de notificación. Los ejemplos detallados de esta información se describirán más adelante.
Por otra parte, cuando varios mensajes de notificación son entregados simultáneamente usando un RTP o un FLUTE, las partes de los mensajes a entregar con restricciones temporales pueden ser mapeadas o correlacionadas sobre la carga útil agregada del RTP, y las partes restantes de los mensajes pueden ser mapeadas o correlacionadas sobre el objeto de transporte agregado del FLUTE. En este caso, las porciones comunes de las partes genéricas de mensajes de notificación de los mensajes de notificación agregados pueden ser mapeadas o correlacionadas sobre la cabecera RTP PF (para las partes con restricciones temporales) y sobre la instancia FDT (para las partes sin una restricción temporal).
La FIG. 11 ilustra un ejemplo de una cabecera RTP PF. La cabecera RTP PF puede tener el formato siguiente.
La cabecera RTP PF puede incluir un campo ID, un campo número de versión (VN), un campo tipo de notificación (NT), un campo acción (ACT), un campo tipo de carga útil de notificación (NPT), un campo tipo (T) y un campo longitud de cabecera (HL). El tamaño de cada campo mostrado en la FIG. 11 es ilustrativo, de manera que pueden tener otros valores.
El campo ID indica un identificador del mensaje de notificación asociado. El campo VN indica un número de versión del mensaje de notificación.
El campo NT indica un tipo de notificación. El campo ACT define una acción a realizar para el mensaje de notificación entregado en la actualidad. Las acciones para los mensajes de notificación se describirán en detalle más adelante.
El campo ACT de la cabecera RTP PF puede ser un campo de 4 bits, y puede tener información según se describe en una tabla ilustrada en una porción inferior de la FIG. 11. Por ejemplo, cuando el campo ACT tiene un valor de “0”, representa información relativa a una acción para lanzar el mensaje de notificación en un sello temporal del RTP. Cuando el campo ACT tiene un valor “1”, representa información relativa a una acción para lanzar el mensaje de notificación en cuanto sea posible. Un valor del campo ACT de “2” indica una acción para cancelar el mensaje de notificación. Un valor del campo ACT de “3” indica una acción de eliminación. Un valor del campo ACT de “4” indica una acción de prerrecuperación. Un valor del campo ACT de “5” indica una acción de actualización. Cuando el campo ACT tiene un valor de “6”, la acción representada por el campo ACT es determinada según una definición de la cabecera de extensión de RTP. En este caso, la cabecera de extensión de RTP puede incluir una pluralidad de acciones, e información temporal asociada a cada acción. Esto se describirá más adelante.
El campo NT indica un tipo de notificación. Por ejemplo, se fijan diferentes valores en el campo NT según los tipos de carga útil de notificación, tales como anuncio de emergencia, cambio de programación de difusión, noticias, etcétera. El valor detallado para cada uno de los tipos de notificación puede ser especificado por los usuarios que se supone que transmiten y reciben los mensajes de notificación. El campo T indica un tipo de paquete RTP. Estos se describirán más adelante. El campo HL indica la longitud de la cabecera RTP PF de notificación.
Cuando una pluralidad de mensajes de notificación es mapeada o correlacionada sobre un RTP (concretamente, cuando mensajes de notificación agregados son transportados en una carga útil RTP), la cabecera RTP PF puede describir el identificador de mensaje de notificación, la versión del mensaje de notificación y el tipo de notificación, para cada mensaje de notificación. Consiguientemente, aunque se incluyan diferentes tipos de mensajes en un paquete RTP, cada uno de los mensajes puede ser identificado y descrito.
La FIG. 12 es un diagrama que ilustra información de identificación, que representa que una pluralidad de mensajes de notificación es transportada en una carga útil RTP. En una realización ilustrada en la FIG. 12, la cabecera de formato de carga útil (PF) RTP en el paquete RTP puede incluir, para cada mensaje de notificación, un campo identificación (I), como un identificador que distingue un mensaje de notificación de otro mensaje de notificación en la carga útil RTP. En esta realización, el campo I es asignado a partir del campo T, indicado anteriormente, de la cabecera RTP PF, por ejemplo, en esta realización se asigna 1 bit para el campo I.
El campo T puede representar el tipo de un paquete RTP. Por ejemplo, cuando el campo T tiene un valor de “0”, puede representar que el paquete RTP es un único paquete. Cuando el campo T tiene un valor de “1”, puede representar que el paquete RTP es un paquete de inicio de fragmentación. Cuando el campo T tiene un valor de “2”, puede representar que el paquete RTP incluye un paquete de continuación de fragmentación. Por el contrario, cuando el campo T tiene un valor de “3”, puede representar que el paquete RTP es un paquete de final de fragmentación. Cuando el campo T tiene otros valores, es un campo no designado, reservado para uso futuro.
El valor del campo I indica si hay o no otra cabecera RTP PF, concretamente, significa cuando el campo I se activa para indicar que hay otros mensajes de notificación en la carga útil RTP y como distinción entre los mensajes de notificación, el campo T puede ser fijado a 3 bits.
Cuando la cabecera RTP PF incluye el campo I, el campo I puede ser información de identificación, que identifica, respectivamente, los múltiples mensajes de notificación en la carga útil RTP. El campo I de esta realización puede representar si hay o no múltiples mensajes de notificación en la carga útil RTP. El campo I se describe, en detalle, más adelante.
La FIG. 13 es un diagrama que ilustra un identificador que representa que la carga útil RTP transporta una pluralidad de mensajes de notificación.
Con referencia a la FIG. 13, un campo tipo de carga útil de notificación (NPT) define el formato de una carga útil de notificación. El campo NPT puede incluir un campo compresión (C), un campo encapsulación (E), un campo indicación
(I) y un campo tipo.
El campo tipo define los mensajes de notificación presentes en una carga útil RTP.
Cuando el campo tipo tiene un valor de “0”, indica un campo reservado. Cuando el campo tipo tiene un valor de “1”, indica un carga útil de notificación que incluye solo una acción sin una carga útil. Cuando el campo tipo tiene un valor de “2”, indica una carga útil de notificación que incluye solo una parte genérica de mensaje. Cuando el campo tipo tiene un valor de “3”, indica una carga útil de notificación que incluye una parte genérica de mensaje y una parte de mensaje específica de aplicación. Cuando el campo tipo tiene un valor de “4”, indica una carga útil de notificación que incluye un mensaje de notificación completo. Cuando el campo tipo tiene un valor de “5”, indica una carga útil de notificación que incluye múltiples mensajes de notificación agregados que comparten el mismo campo de notificación (por ejemplo, un sello temporal, acciones, etc.). Cuando el campo tipo tiene un valor de “6”, indica una carga útil de notificación que incluye un contenedor de inicialización para una aplicación de notificación.
El campo I representa información que describe si hay o no una cabecera RTP PF adicional para el siguiente mensaje en el paquete RTP asociado. Cuando el campo I tiene un valor de “0”, indica que no hay una cabecera RTP para múltiples mensajes de notificación agregados. Cuando el campo I tiene un valor de “1”, indica que hay una cabecera RTP PF adicional para otro mensaje de notificación en esta carga útil. La cabecera RTP PF incluye información que describe, en detalle, el mensaje de notificación correspondiente. Por lo tanto, puede anunciarse, mediante el campo I, que hay una cabecera RTP PF adicional para otro mensaje de notificación en el paquete RTP, y la información de descripción en detalle del mensaje de notificación correspondiente a la cabecera RTP PF puede ser obtenida a partir de la cabecera RTP PF.
El campo E describe el tipo de encapsulación. Por ejemplo, cuando el campo E tiene un valor de “1”, indica un tipo de encapsulación correspondiente a un contenedor MIME multiparte.
El campo C indica si la carga útil RTP está o no en un estado comprimido. Por ejemplo, cuando el campo C tiene un valor “0”, indica que la carga útil RTP no está en un estado comprimido. Por otra parte, cuando el campo C tiene un valor de “1”, indica que la carga útil RTP está en un estado comprimido.
Según la realización indicada anteriormente, puede ser posible mapear una pluralidad de mensajes de notificación sobre diferentes protocolos de transporte, concretamente, un RTP y un FLUTE, para una entrega eficiente de los mensajes de notificación. En particular, cuando una pluralidad de mensajes de notificación es transportada en una carga útil RTP, cada una de las cabeceras RTP PF puede incluir información que describe cada uno de los múltiples mensajes de notificación agregados en la carga útil RTP. La información de descripción puede incluir el identificador de mensaje, la versión de mensaje, y el tipo de notificación para cada uno de los múltiples mensajes de notificación agregados. De esta manera, cuando hay una pluralidad de mensajes de notificación, la información de descripción para cada uno de los mensajes de notificación puede ser transmitida y recibida. En particular, para una pluralidad de mensajes de notificación a entregar con restricciones temporales o en sincronismo con flujos de audio/video, la cabecera RTP PF puede incluir información que describe los mensajes en detalle.
Cuando el campo tipo del campo NPT tiene un valor de “5”, concretamente, cuando una pluralidad de mensajes de notificación es transportada en la carga útil RTP, la información de identificador asociada puede fijarse en la cabecera RTP PF según varios procedimientos diferentes del procedimiento indicado anteriormente.
En adelante, en la presente memoria, se describirá una realización en la que pueden conseguirse eficientemente una transmisión y una recepción de mensajes de notificación. Un mensaje de notificación puede ser transportado sobre un objeto de notificación, que puede tener múltiples estados. El objeto de notificación puede tener un ciclo de vida dependiendo de una variación en el estado.
La FIG. 14 ilustra un ciclo de vida de un objeto de notificación. El objeto de notificación ilustrado puede tener un estado ausente, un estado cargado y un estado activado. El estado del objeto de notificación puede ser variado según varias acciones.
Una transición desde un estado activo o cargado a un estado de reposo puede ser posible no solo mediante acciones explícitas, si no que puede ocurrir también espontáneamente, de manera que el receptor puede recuperar su estado inicial incluso bajo malas condiciones de recepción, o cuando se realiza una conmutación de canal.
Primero, se describirá una acción de recuperación para el objeto de notificación.
Cuando el objeto de notificación es recuperado, el tiempo de vida de la notificación puede ser determinado para que tenga cualquier valor posible. El tiempo de vida puede tener un valor de tiempo relativo, desde un punto de recuperación a un punto de eliminación automático, o puede tener un valor de tiempo absoluto, hasta que la notificación desaparece. Aunque la exactitud no es crítica, el proveedor de notificación puede proporcionar la notificación mientras proporciona un margen suficiente. Un tiempo activo objetivo puede ser determinado, inmediatamente después de la recuperación del objeto. No pueden proporcionarse parámetros de recuperación, usando una acción de lanzamiento. Sin embargo, si la acción de lanzamiento es repetida regularmente durante el tiempo activo, puede ocurrir un derroche de ancho de banda. Puede usarse una recuperación explícita o una recuperación implícita (cuando se recibe una acción de lanzamiento para un objeto no cargado todavía).
En adelante, en la presente memoria, se describirá una acción de lanzamiento para un objeto de notificación.
Una vez lanzado un objeto, puede definirse un tiempo máximo activo. Aunque un mensaje de lanzamiento (desencadenador) puede ser entregado repetidamente, con el fin de contrarrestar una recepción imperfecta de una señal de difusión o una conmutación de canal tardía, es innecesario entregar repetidamente el tiempo activo del mensaje de lanzamiento para cada entrega del mensaje de lanzamiento (esto es debido a que el tiempo activo puede ser conocido a partir de la acción de recuperación). Consiguientemente, es posible ahorrar ancho de banda. El intervalo de entrega del tiempo activo puede ser menor de un segundo. La acción de lanzamiento puede ser realizada inmediatamente en un tiempo de lanzamiento indicado en una acción previa, o cuando llega un tiempo de lanzamiento, indicado en la acción de lanzamiento. Por esta razón, el tiempo de lanzamiento puede ser determinado según el resultado de una comparación del mismo con un tiempo de referencia. Por ejemplo, la acción de lanzamiento puede ser realizada dependiendo de un mecanismo de transporte, por ejemplo, cuando el tiempo de presentación del sello temporal RTP alcanza el tiempo de lanzamiento.
Ahora, se describirá una acción de cancelación del objeto de notificación.
La acción de cancelación puede ser desencadenada mediante un mensaje de notificación específico. La desactivación de una notificación puede ser desencadenada por la expiración de un temporizador. Por esta razón, la acción de cancelación puede no tener ningún parámetro adicional. Esto significa que el tiempo de vida de la notificación no será modificado por la acción de cancelación.
En adelante, se describirá una acción de eliminación del objeto de notificación. La acción de eliminación puede ser desencadenada mediante un mensaje de notificación específico. En la mayoría de los casos, sin embargo, el objeto es eliminado después de un tiempo determinado. Esto significa el final de la vida del objeto, de manera que no se transmite ningún parámetro adicional.
Ahora, se describirá una acción de actualización del objeto de notificación.
Aunque puede ser útil permitir una actualización del tiempo de vida o del tiempo activo para los objetos existentes, este no es un requerimiento esencial. Consiguientemente, la acción de actualización puede ser desencadenada directamente mediante un comando de actualización especial, o mediante la recepción de parámetros modificados para las acciones de recuperación y lanzamiento.
Según la definición indicada anteriormente, el estado del objeto de notificación puede alternar entre los estados ausente, cargado (almacenado) y activo.
Por ejemplo, un objeto, que ha estado en un estado ausente, pasa a un estado activo cuando es lanzado, y pasa a un estado cargado cuando es recuperado (o actualizado). El objeto, que está en un estado ausente, mantiene el estado ausente debido a una acción de cancelación o de eliminación.
Un objeto, que está en un estado activo, pasa a un estado cargado debido a una acción de cancelación, y pasa a un estado ausente debido a una acción de eliminación. El objeto, que está en un estado activo, mantiene el estado activo debido a una acción de recuperación, lanzamiento o actualización.
Un objeto, que está en un estado cargado, pasa a un estado activo debido a una acción de lanzamiento, y pasa a un estado ausente debido a una acción de cancelación. El objeto, que está en un estado cargado, mantiene el estado cargado debido a una acción de actualización, cancelación o recuperación.
La FIG. 15 es un diagrama que ilustra un ejemplo en el que se transmite una notificación.
En la FIG. 15, las marcas rectangulares en la primera línea indican una acción de recuperación (Fetch Msg, mensaje de recuperación), una acción de lanzamiento (Launch Msg, mensaje de lanzamiento), una acción de cancelación (Cancel Msg, mensaje de cancelación) y una acción de eliminación (Remove Msg, mensaje de eliminación) para un mensaje de notificación, respectivamente.
La segunda línea en la FIG. 15 ilustra una transición de estado del mensaje de notificación, en la que un receptor (terminal), que está en perfectas condiciones de recepción, recibe el mensaje de notificación. Por ejemplo, cuando el receptor recibe un mensaje de recuperación, el evento del mensaje de notificación pasa a un estado cargado. Cuando se recibe un mensaje de lanzamiento, el evento del mensaje de notificación es realizado bajo la condición en la que se proporciona un cierto margen. En este momento, el mensaje de notificación pasa a un estado activo. El mensaje de lanzamiento puede ser transmitido repetidamente para compensar las malas condiciones de recepción de señal o una conmutación de canal. El tiempo activo en este caso se ilustra en la línea más inferior en la FIG. 15, como un tiempo relativo.
Cuando se realiza una acción de cancelación para el mensaje de notificación, el evento del mensaje de notificación es cancelado, de manera que el mensaje de notificación pasa a un estado cargado. Cuando se realiza una acción de eliminación, el mensaje de notificación pasa a un estado ausente, y el evento del mensaje de notificación es descargado.
La tercera línea en la FIG. 15 ilustra una transición de estado del mensaje de notificación, en el que un receptor (terminal), que está en malas condiciones de recepción, recibe el mensaje de notificación. Cuando el receptor en malas condiciones de recepción recibe el mensaje de notificación, la recepción del mensaje de notificación es permitida solo durante un tiempo limitado (indicado en gris). Cuando el receptor recibe un mensaje de lanzamiento dentro del tiempo limitado, el mensaje de notificación pasa a un estado activo. Bajo malas condiciones de recepción de señal, el receptor mantiene el mensaje de notificación en el estado activo durante un tiempo suficiente, concretamente, un tiempo predeterminado. A continuación, el mensaje de notificación es desactivado. La desactivación puede ser desencadenada mediante un temporizador basado en información temporal. A continuación, el objeto es descargado.
El tiempo de vida de la notificación está indicado en la línea más inferior, concretamente, la última línea.
Tal como se ha indicado anteriormente, la entrega del mensaje de notificación puede conseguirse transmitiendo un objeto de notificación. El mensaje de notificación puede ser transferido junto con varias acciones, con el fin de definir acciones del objeto de notificación. El mensaje de notificación puede ser entregado usando un FLUTE o RTP. En adelante, se describirá una notificación en la que se definen una pluralidad de acciones.
La FIG.1 6 es una diagrama que ilustra un estado de una notificación según una acción. Según esta realización, un mensaje de notificación incluye una pluralidad de acciones, e información acerca de los tiempos en los que se realizan las acciones, respectivamente. El receptor puede recibir un mensaje de notificación que incluye información que define una pluralidad de acciones, y puede realizar las acciones respectivas en los tiempos asociados.
Por ejemplo, el receptor recibe un mensaje de notificación que incluye no solo todas las acciones, concretamente, acciones de búsqueda, lanzamiento, cancelación y eliminación, si no también información acerca de los tiempos en los que deben realizarse las acciones respectivas.
Cuando se realiza una acción de búsqueda para el mensaje de notificación en el tiempo asociado, el mensaje de notificación pasa a un estado cargado, de manera que se carga un evento según el mensaje de notificación. Cuando se realiza una acción de lanzamiento para el mensaje de notificación, el mensaje de notificación pasa a un estado activo, de manera que se realiza el evento. Cuando se realiza una acción de cancelación en un tiempo definido en un mensaje de notificación recibido previamente, el mensaje de notificación actual pasa a un estado cargado, de manera que su evento es cancelado. De manera similar, cuando se realiza una acción de eliminación en el tiempo de eliminación definido en el mensaje recibido previamente, el evento es descargado, y el mensaje de notificación actual es descargado también.
De esta manera, una vez transmitido un mensaje de notificación, es innecesario recibir repetidamente el mensaje de notificación para las acciones respectivas. Consiguientemente, los servicios de notificación pueden ser proporcionados incluso en malas condiciones de recepción de señal del receptor o sin una recepción repetida del mensaje de notificación por el receptor.
La FIG. 17 es un diagrama que ilustra un ejemplo en el que se describe un mensaje de notificación usando un FLUTE. “NotificationAggregateDescriptionType” de una FDT, implementada, por ejemplo, en un formato de lenguaje de anotación extensible (extensible markup language, XML), puede describir un mensaje de notificación.
Con el fin de permitir a la FDT describir el mensaje de notificación, puede definirse “NotificationAggregateDescriptionType” que incluye un elemento “FilterElementList” y un elemento “NotificationMessageDescription”. El elemento “FilterElementList” puede ser usado como un filtro de mensajes, mediante el cual un receptor filtra un mensaje de notificación preferente entre los mensajes de notificación equipados con el mismo tipo de notificación.
El elemento “NotificationMessageDescription” puede definirse según “NotificationMessageDescriptionType” definido como un tipo complejo. El “NotificationMessageDescriptionType” puede incluir un elemento “TimingInformation” que incluye información acerca de un tiempo en el que el estado del mensaje de notificación pasa a otro estado, un elemento “FilterElementList” que indica una referencia de filtrado para determinar si un mensaje transportado en el objeto de transporte de un FLUTE será recibido, y un elemento “SubscriptionInformation” que incluye información de abonado a servicios.
El elemento “NotificationMessageDescription” incluye, atributos del mismo, “MessageID” que indica el identificador del mensaje, “Version” que indica la versión del mensaje, “NotificationType” que indica el tipo de notificación del mensaje y “NotificationPayloadType” que indica el tipo de carga útil del mensaje.
“Action” representa una acción para el mensaje de notificación, y “ServiceRef” representa información de referencia de servicios asociados con el mensaje de notificación.
Tal como se ha indicado anteriormente, cuando un mensaje de notificación, que incluye acciones que causan una transición de estado del mensaje, e información acerca de los tiempos en los que las acciones respectivas deben ser realizadas, es transmitido, una transmisión frecuente del mensaje de notificación puede causar una carga adicional de transmisión. Sin embargo, cuando la información que define una pluralidad de acciones para un evento y la información que define los tiempos en los que las acciones deben ser realizadas, respectivamente, son transmitidas en un único mensaje, es innecesario recibir repetidamente el mensaje de notificación asociado.
La FIG. 18 ilustra “NotificationAggregateDescriptionType” que describe un mensaje de notificación que incluye una pluralidad de acciones e información temporal de las mismas. Cuando un mensaje de notificación es entregado, la información temporal asociada con las acciones que causan una transición de estado del mensaje de notificación puede ser incluida en los atributos de las acciones asociadas. La información de descripción del mensaje de notificación “NotificationAggregateDescriptionType” del FLUTE ilustrado puede incluir información que define una pluralidad de acciones e información que define tiempos en los cuales deben realizarse las acciones, respectivamente.
El tipo de descripción “NotificationAggregateDescriptionType” que describe el formato del mensaje de notificación puede incluir además una pluralidad de elementos “ActionTiming”, además de los elementos indicados anteriormente. Los elementos “ActionTiming” pueden ser definidos según “ActionTimingType” como un tipo que incluye una pluralidad de acciones para el objeto de notificación e información temporal asociada con cada acción.
El “ActionTimingType” puede incluir un elemento “TimingInformation” que incluye información temporal, y un elemento “Action” que incluye información de acción. Consiguientemente, cuando el objeto de notificación ilustrado es recibido, el receptor puede realizar una transición de estado del objeto de notificación según la información de acción y la información temporal incluida en el objeto de notificación. Cuando el mensaje de notificación descrito en la FIG. 18 es recibido, un evento transportado en el mensaje de notificación puede ser realizado o cancelado según la información temporal según el “ActionTimingType” y la información de acción asociada. Debido a que la información temporal y la información de acción pueden incluir una pluralidad de tiempos y una pluralidad de acciones, respectivamente, la transmisión y la recepción del mensaje de notificación puede conseguirse eficientemente sin un incremento del ancho de banda.
Un mensaje de notificación, que incluye información que define una pluralidad de acciones para una notificación e información temporal acerca de los tiempos en los cuales deben realizarse las acciones, respectivamente, puede ser entregado también usando un RTP.
Las FIGs. 19 y 20 son diagramas que ilustran información de notificación transportada en un RTP, cuando un mensaje de notificación que incluye múltiples informaciones temporales es entregado.
La FIG. 19 es un diagrama que ilustra una cabecera RTP PF. La cabecera RTP PF puede incluir un campo ID, campo VN, campo NT, campo ACT, campo NPT, campo T y campo HL. El tamaño de cada campo mostrado en la FIG. 19 es ilustrativo, de manera que pueden tener otros valores. Para la descripción de cada campo, puede hacerse referencia la descripción anterior.
Sin embargo, el campo ACT de la cabecera RTP PF se describirá en detalle. El campo ACT, que es un campo de 4 bits, puede tener información, tal como se describe en una tabla ilustrada en una porción inferior de la FIG. 9. Por ejemplo, cuando el campo ACT tiene un valor “0”, representa información relacionada con una acción para lanzar el mensaje de notificación en un sello temporal del RTP. Cuando el campo ACT tiene un valor de “1”, representa información relacionada con una acción para lanzar el mensaje de notificación en cuanto sea posible. Un valor del campo ACT de “2” indica una acción para cancelar el mensaje de notificación. Un valor del campo ACT de “3” indica una acción de eliminación. Un valor del campo ACT de “4” indica una acción de pre-búsqueda. Un valor del campo ACT de “5” indica una acción de actualización. Cuando el campo ACT tiene un valor de “6”, la acción representada por el campo ACT es determinada según una definición de la cabecera de extensión RTP. En este caso, la cabecera de extensión RTP puede incluir una pluralidad de acciones e información temporal asociada a cada acción.
La FIG. 20 es un diagrama que ilustra una cabecera de extensión de carga útil RTP. La cabecera de extensión de carga útil RTP puede incluir un campo tipo de cabecera de extensión (EHT), un campo longitud de cabecera de extensión (EHL) y un campo cabecera de extensión.
Cuando el campo EHT tiene un valor de “1”, la cabecera de extensión indica una lista de elementos filtro. La lista de elementos filtro representa información de filtrado para un mensaje de notificación. Según la información de filtrado, el filtrado y la agregación pueden ser realizados para el mensaje de notificación.
Cuando el campo EHT tiene un valor de “2”, la cabecera de extensión indica información de abonado a servicios, concretamente, información de subscripción. Cuando el campo EHT tiene un valor “3”, la cabecera de extensión indica una referencia a contenedor.
Por otra parte, cuando el campo EHT tiene un valor de “4”, la cabecera de extensión indica una pluralidad de acciones e información temporal asociada con cada acción.
La FIG. 21 es un diagrama de flujo que ilustra una realización del procedimiento de transmisión/recepción de mensajes de notificación, indicado anteriormente.
Una pluralidad de mensajes de notificación, a ser entregados sobre una red, son generados (S110). Cada mensaje de notificación puede incluir una parte genérica del mensaje de notificación y una carga útil del mensaje de notificación.
Un paquete RTP, que incluye una carga útil RTP que transporta las cargas útiles de los múltiples mensajes de notificación, (S120). En este momento, el paquete RTP incluye información que describe, en detalle, los mensajes de notificación en la carga útil RTP. La información de descripción de los mensajes de notificación puede incluir el tipo de notificación de cada uno de los mensajes de notificación.
Mientras, cuando es innecesario entregar los múltiples mensajes de notificación en sincronismo con sus objetos de medios, un FLUTE FDT objeto de transporte FLUTE pueden ser generados para entregar los mensajes de notificación según un FLUTE. Como alternativa, los mensajes de notificación pueden ser transformados en formatos de transporte según diferentes protocolos de transporte, concretamente, RTP y FLUTE, de manera que una parte de los mensajes de notificación sean entregados usando un paquete RTP, y la parte restante de los mensajes de notificación sean entregados usando un FLUTE.
El paquete RTP generado es encapsulado en IP y, a continuación, es entregado sobre la red (S130). Cuando los mensajes de notificación son entregados usando el FLUTE, el FLUTE es también encapsulado en IP. En este caso, cada unidad encapsulada puede ser modulada, de manera que pueda ser entregada sobre la red.
Cada mensaje de notificación puede ser entregado según la información que define una pluralidad de acciones e información temporal asociada con cada acción. Cuando cada mensaje de notificación puede ser entregado según la información que define una pluralidad de acciones e información temporal asociada con cada acción, la información de acción y la información temporal pueden ser fijadas en la FDT del FLUTE o la cabecera RTP PF y la cabecera de extensión del RTP. En este caso, el mensaje de notificación puede ser entregado sin una entrega repetida del mismo, para diferentes acciones, ya que los tiempos en los que el mensaje de notificación debe ser cargado, activado, cancelado y eliminado, respectivamente, están fijados en el FLUTE o RTP.
Para la recepción de los mensajes de notificación entregados, una señal recibida mediante la red es demultiplexada para adquirir el paquete RTP a partir del paquete IP que incluye los mensajes de notificación (S210).
Los mensajes de notificación pueden ser descubiertos en base a la información de anuncio de notificación. Cuando un mensaje de notificación transportado en una señal de difusión es recibido, la información de anuncio en relación al mensaje de notificación puede ser descubierta a partir de la información de descripción de servicio que describe la red asociada. Como alternativa, un paquete IP transmitido a una dirección IP específica es identificado a partir de la información de descripción de servicio. En este caso, es posible adquirir la información arranque de una ESG a partir del paquete IP identificado, y, a continuación, adquirir la información de anuncio a partir de la información de arranque. De otra manera, puede ser posible adquirir la información de anuncio en relación al mensaje de notificación a través de un canal descubierto a partir de la información de arranque adquirida como un canal, a partir de la cual puede adquirirse la ESG, o a través de un servicio específico de la ESG recibida desde el arranque asociado.
A continuación, el paquete RTP es decodificado para adquirir información que describe cada uno de entre una pluralidad de mensajes de notificación, cuando la pluralidad de mensajes de notificación está en la carga útil del paquete RTP. A continuación, los múltiples mensajes de notificación son extraídos de la carga útil RTP, usando la información adquirida. De esta manera, los mensajes de notificación son adquiridos (S220).
Mientras, cuando los múltiples mensajes de notificación no necesitan estar sincronizados con objetos de medios, los mismos pueden ser adquiridos desde un FLUTE que los transporta. De otra manera, una parte de los mensajes de notificación puede ser adquirida a partir de un paquete RTP, y la parte restante de los mensajes de notificación puede ser adquirida a partir de un FLUTE.
Los mensajes de notificación son analizados. Y, según la información de acción de cada mensaje de notificación, un evento de notificación es proporcionado a continuación (S230).
Cada mensaje de a continuación puede incluir información que define una pluralidad de acciones e información temporal asociada con cada acción. Cuando cada mensaje de a continuación puede incluir información que define una pluralidad de acciones e información temporal asociada con cada acción, la información de acción e información temporal pueden ser adquiridas a partir de la FDT del FLUTE o de la cabecera RTP PF y de la cabecera de extensión RTP. En este caso, es posible adquirir eventos provistos según las acciones y tiempos asociados definidos en el mensaje de notificación recibido, sin una recepción repetida del mensaje de notificación.
La FIG. 22 es un diagrama de bloques que ilustra una realización de un aparato de recepción de mensajes de notificación. El aparato receptor de mensajes de notificación en la realización ilustrada incluye un demultiplexador 110 de flujo de transporte, un desencapsulador 120 IP, un decodificador 130 UDP, un decodificador 140 RTP, un decodificador 151 de video, un decodificador 153 de audio, un primer analizador 155 de notificación, un decodificador 160 FLUTE, un segundo analizador 165 de notificación, un analizador 170 de contenedor, un analizador 180 de guía de servicios, un controlador 185 de información de guía de servicios, un decodificador 190 de información de descripción de servicios y una pantalla 200.
El aparato de recepción de mensajes de notificación puede estar conectado a un receptor de señales para recibir una señal que transporta un mensaje de notificación sobre una red. Por ejemplo, cuando se recibe una señal de difusión desde un sistema DVB sobre una red de difusión, el receptor de señales puede ser un receptor de señal DVB. Cuando se recibe una señal sobre una red interactiva, el aparato de recepción de mensajes de notificación puede estar conectado a un dispositivo de comunicación capaz de realizar una modulación y una demodulación de la señal.
El demultiplexador 110 de flujo de transporte puede demultiplexar un paquete IP incluido en un flujo de transporte. Cuando el aparato receptor de mensajes de notificación está conectado a un dispositivo de comunicación, el demultiplexador 110 de flujo de transporte puede carecer del mismo.
El desencapsulador 120 IP desencapsula el paquete IP multiplexado, para eliminar una cabecera IP que incluye las direcciones IP origen y destino.
El decodificador 130 UDP saca los datos obtenidos después de eliminar una cabecera UDP que incluye los puertos de origen y destino a partir de una carga útil desencapsulada mediante el desencapsulador 120 IP.
El decodificador 140 RTP puede sacar los datos codificados controlando una tasa de codificación según un protocolo de control RTP (RTCP). Los datos codificados pueden ser datos de contenido que incluyen al menos uno de entre datos de video, datos de audio y un mensaje de notificación. El decodificador 140 RTP puede decodificar la información que describe cada uno de los mensajes de notificación en la carga útil RTP. Por ejemplo, el decodificador 140 RTP puede decodificar información de descripción para los tipos de notificación de los mensajes de notificación en la carga útil RTP.
El decodificador 151 de video puede decodificar datos de video sacados desde el decodificador 140 RTP, para sacar los datos de video decodificados. Por ejemplo, el decodificador 151 de video puede decodificar datos de video codificados en un formato H.264. El decodificador 153 de audio puede decodificar los datos de audio sacados desde el decodificador 140 RTP, para sacar los datos de audio decodificados. Por ejemplo, el decodificador 153 de audio puede decodificar los datos de audio codificados en un formato AAC+.
El primer analizador 155 de notificación analiza un mensaje de notificación entregado usando un RTP, para sacar el mensaje de notificación analizado. La pantalla 200 puede proporcionar el mensaje de notificación sacado desde el primer analizador 155 de notificación al usuario. El mensaje NDN y el mensaje PDN analizados por el primer analizador 155 de notificación pueden ser proporcionados al usuario mediante la pantalla 200.
Mientras, el decodificador 160 FLUTE decodifica una FDT de los datos sacados desde el decodificador 130 UDP, para sacar los ficheros incluidos en el objeto de transporte de un FLUTE. El objeto de transporte puede sacar ficheros de datos binarios, datos de imágenes, datos de texto, etc. El decodificador 160 FLUTE puede sacar el mensaje de notificación incluido en el objeto de transporte del FLUTE.
El segundo analizador 165 de notificación analiza el mensaje de notificación entregado usando un FLUTE, para sacar el mensaje de notificación analizado.
El primer analizador 155 de notificación y el segundo analizador 165 de notificación pueden ser incorporados para constituir un único analizador.
Mientras, el analizador 170 de contenedor puede analizar un contenedor incluido en el objeto de transporte del FLUTE, para sacar información de guía de servicios.
El analizador 180 de guía de servicios analiza la información de guía de servicios sacada desde el analizador 170 de contenedor, para sacar la información de guía de servicios analizada.
El controlador 185 de información de guía de servicios puede recibir una información de guía de servicios sacada desde el analizador 180 de guía de servicios, y los mensajes de notificación sacados respectivamente del primer analizador 155 de notificación y el segundo analizador 165 de notificación, para sacar la información y los mensajes recibidos a la pantalla 200.
El controlador 185 de información de guía de servicios puede proporcionar información de guía de servicios desde el analizador 180 de guía de servicios y un mensaje de notificación desde el analizador 165 de notificación al usuario, mediante la pantalla 200.
El decodificador 190 de información de descripción de servicios puede decodificar la información de descripción de servicios demultiplexada por el demultiplexador 110 de flujo de transporte. Por ejemplo, el decodificador 190 de información de descripción de servicios puede decodificar información de descripción de servicios que incluye información de anuncio como mensajes de notificación (por ejemplo, información PSI/SI, tal como PAT, PMT o NIT). El decodificador 190 de información de descripción de servicios puede decodificar información de anuncio, tal como mensajes de notificación incluidos en una NIT, para permitir la recepción de un mensaje de notificación identificado en base a la información de anuncio decodificada.
Cuando una pluralidad de mensajes de notificación son entregados por medio de un RTP, el decodificador 140 RTP puede decodificar información incluida en un paquete RTP para describir, en detalle, la pluralidad de los mensajes de notificación. Según la información, el primer analizador 155 de notificación puede identificar y analizar cada uno de entre los múltiples mensajes de notificación incluidos en la carga útil RTP.
Cuando un mensaje de notificación es entregado usando un RTP, el decodificador 140 RTP puede decodificar el paquete RTP. Según la información decodificada, el primer analizador 155 de notificación puede sacar el mensaje de 5 notificación, que está incluido en la carga útil RTP del RTP, en base a las acciones y a la información temporal incluidos en la cabecera de formato de carga útil RTP.
Será evidente, para las personas con conocimientos en la materia, que pueden realizarse varias modificaciones y variaciones en la presente invención. De esta manera, se pretende que la presente invención incluya las modificaciones y las variaciones de esta invención, siempre que estén incluidas en el alcance de las reivindicaciones adjuntas y sus
10 equivalentes.
Claims (9)
- REIVINDICACIONES1.- Aparato de recepción de mensajes de notificación que comprende:un desencapsulador (120) de protocolo de internet (IP), configurado para desencapsular un paquete IP que transporta mensajes de notificación sobre una red:un decodificador (130) de protocolo datagrama de usuario (UDP), configurado:- para decodificar el paquete IP desencapsulado según un UDP; y-para sacar un paquete de protocolo de transporte en tiempo real (RTP); un decodificador (140) RTP, configurado:
- -
- para decodificar el paquete RTP;
- -
- para adquirir, desde el paquete RTP, una primera información que describe un tipo de notificación de cada uno de entre una pluralidad de mensajes de notificación y una segunda información que indica que los datos de la pluralidad de los mensajes de notificación están agregados dentro de una única carga útil en el paquete RTP; y
-para sacar la pluralidad de los mensajes de notificación según la información adquirida. - 2.- Aparato de recepción de mensajes de notificación según la reivindicación 1, en el que la segunda información es una cabecera de formato de carga útil RTP del paquete RTP. 3.- Aparato de recepción de mensajes de notificación según la reivindicación 1, en el que el paquete RTP incluyeademás al menos un mensaje de notificación a ser entregado con restricciones temporales. 4.- Aparato de recepción de mensajes de notificación según la reivindicación 3, que comprende además:un decodificador (150) de entrega de ficheros sobre transporte unidireccional (FLUTE), configurado para decodificar los datos obtenidos mediante la decodificación según el UDP, según un FLUTE; un analizador (165) de notificación, configurado para analizar mensajes de notificación desde un fichero obtenidomediante la decodificación según el FLUTE;un analizador (170) de contenedor, configurado para analizar un contenedor de datos incluido en el fichero decodificado según el FLUTE; un analizador (180) de guía de servicios, configurado para analizar la información de guía de servicios incluida en elcontenedor analizado; y un controlador (185) de información de guía de servicios, configurado para proporcionar los mensajes de notificación según la información de guía de servicios analizada. 5.- Aparato de recepción de mensajes de notificación según la reivindicación 5, en el que el paquete RTP incluye todoslos mensajes de notificación a ser entregados con restricciones temporales y los mensajes de notificación restantes son entregados según el FLUTE. 6.- Procedimiento de transmisión de mensajes de notificación, que comprende:generar (S110) una pluralidad de mensajes de notificación a ser entregados sobre una red; generar un paquete RTP que incluya una primera información que describe un tipo de notificación de cada uno de entre la pluralidad de mensajes de notificación en la carga útil RTP (S120) y una segunda información que indicaque los datos de la pluralidad de mensajes de notificación están agregados dentro de una única carga útil en el paquete RTP; y encapsular en protocolo de Internet (IP) el paquete RTP generado, y transmitir el paquete encapsulado en IP sobrela red (S130).
- 7.- Procedimiento de transmisión de mensajes de notificación según la reivindicación 6, en el que la segunda información es una cabecera de formato de carga útil RTP del paquete RTP. 8.- Procedimiento de transmisión de mensajes de notificación según la reivindicación 6, que comprende insertar en elpaquete RTP al menos un mensaje de notificación a ser entregado con restricciones temporales. 9.- Procedimiento de transmisión de mensajes de notificación según la reivindicación 8, que comprende además: insertar al menos uno de entre la pluralidad de mensajes de notificación generados en un objeto de transporte segúnuna entrega de ficheros sobre un transporte unidireccional (FLUTE);insertar información que describe la pluralidad de mensajes de notificación en una tabla de descripción de ficheros (FDT), generando de esta manera datos FLUTE; ytransmitir los datos FLUTE generados.
- 10.- Procedimiento de transmisión de mensajes de notificación según la reivindicación 9, que comprende insertar en el paquete RTP todos los mensajes de notificación a ser entregados con restricciones temporales e insertar en el FLUTE el resto de mensajes de notificación.
- 11.- Procedimiento de recepción de mensajes de notificación que comprende:desencapsular (S210) un paquete IP que transporta una pluralidad de mensajes de notificación sobre una red;decodificar (S210) una carga útil del paquete IP desencapsulado, según un UDP, y para sacar un paquete de protocolo de transporte en tiempo real (RTP);decodificar (S220) el paquete RTP para adquirir, desde el paquete RTP, una primera información que describe un tipo de notificación de cada uno de entre la pluralidad de mensajes de notificación y una segunda información que indica que los datos de la pluralidad de mensajes de notificación está agregada dentro de una única carga útil en el paquete RTP.
- 12.- Aparato de recepción de mensajes de notificación según la reivindicación 11, en el que la segunda información está en una cabecera de formato de carga útil RTP del paquete RTP.
- 13.- Aparato de recepción de mensajes de notificación según la reivindicación 11, en el que el paquete RTP incluye además al menos un mensaje de notificación a ser entregado con restricciones temporales.
- 14.- Procedimiento de recepción de mensajes de notificación según la reivindicación 11, que comprende además:decodificar al menos uno de entre la pluralidad de mensajes de notificación generados desde un objeto de transporte según una entrega de ficheros sobre un transporte unidireccional (FLUTE); ydecodificar los datos FLUTE que comprenden información que describe la pluralidad de mensajes de notificación desde una tabla de descripción de ficheros (FDT).
- 15.- Procedimiento de recepción de mensajes de notificación según la reivindicación 14, en el que el paquete RTP incluye todos los mensajes de notificación a ser entregados con restricciones temporales y FLUTE incluye todos los mensajes de notificación restantes.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US1717607P | 2007-12-28 | 2007-12-28 | |
| US17176P | 2007-12-28 | ||
| KR20080132234 | 2008-12-23 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2359762T3 true ES2359762T3 (es) | 2011-05-26 |
Family
ID=41376285
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08172936T Active ES2359762T3 (es) | 2007-12-28 | 2008-12-24 | Método para transmitir y recibir mensajes de notificación y aparato para ello. |
Country Status (7)
| Country | Link |
|---|---|
| EP (7) | EP2800337B1 (es) |
| KR (1) | KR101461973B1 (es) |
| AT (1) | ATE495619T1 (es) |
| DE (1) | DE602008004425D1 (es) |
| ES (1) | ES2359762T3 (es) |
| PL (1) | PL2081360T3 (es) |
| WO (1) | WO2009084863A2 (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107529090B (zh) | 2011-01-19 | 2021-01-26 | 三星电子株式会社 | 用于在广播系统中配置控制消息的装置 |
| US9451401B2 (en) | 2011-05-27 | 2016-09-20 | Qualcomm Incorporated | Application transport level location filtering of internet protocol multicast content delivery |
| KR101501344B1 (ko) | 2012-05-02 | 2015-03-10 | 삼성전자주식회사 | 멀티미디어 서비스 송수신 방법 및 장치 |
| CN110708148A (zh) | 2018-07-09 | 2020-01-17 | 华为技术有限公司 | 一种信令字段指示方法及装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7191242B1 (en) * | 2000-06-22 | 2007-03-13 | Apple, Inc. | Methods and apparatuses for transferring data |
| EP2894831B1 (en) * | 2005-06-27 | 2020-06-03 | Core Wireless Licensing S.a.r.l. | Transport mechanisms for dynamic rich media scenes |
| EP1941724B1 (en) | 2005-10-07 | 2013-11-20 | Nokia Corporation | Notification as a service or as an access to a service |
-
2008
- 2008-12-23 KR KR1020080132234A patent/KR101461973B1/ko not_active Expired - Fee Related
- 2008-12-24 WO PCT/KR2008/007673 patent/WO2009084863A2/en not_active Ceased
- 2008-12-24 ES ES08172936T patent/ES2359762T3/es active Active
- 2008-12-24 EP EP14179172.3A patent/EP2800337B1/en not_active Not-in-force
- 2008-12-24 EP EP12162565.1A patent/EP2472827B1/en not_active Not-in-force
- 2008-12-24 EP EP15192994.0A patent/EP3010204B1/en not_active Not-in-force
- 2008-12-24 DE DE602008004425T patent/DE602008004425D1/de active Active
- 2008-12-24 EP EP10171115.8A patent/EP2280523B1/en not_active Not-in-force
- 2008-12-24 EP EP10171119.0A patent/EP2259537B1/en not_active Not-in-force
- 2008-12-24 PL PL08172936T patent/PL2081360T3/pl unknown
- 2008-12-24 EP EP08172936A patent/EP2081360B1/en not_active Not-in-force
- 2008-12-24 AT AT08172936T patent/ATE495619T1/de not_active IP Right Cessation
- 2008-12-24 EP EP12162559.4A patent/EP2472826B1/en not_active Not-in-force
Also Published As
| Publication number | Publication date |
|---|---|
| ATE495619T1 (de) | 2011-01-15 |
| EP2472827B1 (en) | 2014-09-10 |
| EP2259537A1 (en) | 2010-12-08 |
| WO2009084863A2 (en) | 2009-07-09 |
| EP3010204B1 (en) | 2017-05-24 |
| EP2280523A1 (en) | 2011-02-02 |
| EP2472827A1 (en) | 2012-07-04 |
| KR20090072992A (ko) | 2009-07-02 |
| EP2081360A1 (en) | 2009-07-22 |
| EP3010204A1 (en) | 2016-04-20 |
| EP2800337A1 (en) | 2014-11-05 |
| KR101461973B1 (ko) | 2014-11-14 |
| EP2259537B1 (en) | 2013-08-28 |
| EP2800337B1 (en) | 2016-03-09 |
| PL2081360T3 (pl) | 2011-06-30 |
| EP2472826A1 (en) | 2012-07-04 |
| EP2472826B1 (en) | 2014-11-12 |
| WO2009084863A3 (en) | 2009-10-29 |
| EP2081360B1 (en) | 2011-01-12 |
| DE602008004425D1 (de) | 2011-02-24 |
| EP2280523B1 (en) | 2013-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100831657B1 (ko) | 통신 네트워크에서 버스트를 송신하기 위한 방법, 네트워크요소 및 시스템, 통신 네트워크에서 수신기기를 작동하는 방법, 이를 위한 컴퓨터 판독가능 매체 및 핸드셋 | |
| US8861526B2 (en) | Method for transmitting broadcast service, method for receiving the broadcasting service, and apparatus for receiving the broadcasting service | |
| US8726328B2 (en) | Method for transmitting a broadcast service, and method and apparatus for receiving same | |
| KR20110102349A (ko) | 방송 신호를 수신하는 방법 및 방송 수신기 | |
| 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 | |
| ES2359762T3 (es) | Método para transmitir y recibir mensajes de notificación y aparato para ello. | |
| KR101340935B1 (ko) | 디지털 비디오 서비스를 방송 또는 수신하기 위한 방법 및대응하는 디바이스 | |
| US9699487B2 (en) | Method for transmitting a broadcasting service, method for receiving a broadcast service, and apparatus for receiving a broadcast service | |
| JP5593193B2 (ja) | 放送サービスの送信装置、受信装置及びそのプログラム | |
| JP5622475B2 (ja) | 放送サービスの送信装置、受信装置及びそのプログラム | |
| JP5797958B2 (ja) | 放送サービスの送信装置 | |
| WO2008034376A1 (en) | Implementation method, system, server and user terminal for obtaining default notification message | |
| Hornsby et al. | Notification service for DVB-H mobile broadcast | |
| ES2372977T3 (es) | Procedimiento de notificación de cambio de un parámetro de emisión y emisor según el procedimiento. | |
| KR20170140067A (ko) | MBMS(Multimedia Broadcast/Multicast Service) 수신기 및 그의 멀티캐스트 신호 수신 방법 |