ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.

Un router multicast (260) que tiene una o más interfaces de red "downstream" y situado en una red de datos entre fuentes (295,

296,297,298,299) que transmiten paquetes multicast dirigidos a por lo menos una dirección de grupo multicast y uno o más hosts (200,220,225,230) que solicitan, de al menos una de las fuentes, los datos multicast enviados a por lo menos una dirección de grupo multicast, el router multicast (260) caracterizado porque está adaptado para: - almacenar para una interfaz de red "downstream" y dirección de grupo multicast un registro de fuentes INCLUDE que contiene información acerca de las listas de fuentes INCLUDE derivada de las solicitudes de datos realizadas por los uno o más hosts (200,220,225,230) y un registro de fuentes EXCLUDE que contiene información acerca de las listas de fuentes EXCLUDE derivadas de las solicitudes de datos realizadas por los uno o más hosts (200,220,225,230), - usar un protocolo de enrutamiento multicast host-router basado en el protocolo IGMP, "Internet Group Management Protocol", o el protocolo MLD, "Multicast Listener Discovery" para comunicarse con los uno o más hosts (200,220,225,230) y un protocolo de ruteo multicast router-router para comunicarse con por lo menos otro router multicast (261,262,263,264,265,266,267) situado entre él mismo y las fuentes (295,296,297,298,299), el router multicast (260) incluyendo un "source-timer" para cada una de las fuentes en la lista de fuentes INCLUDE y en la listas de fuentes EXCLUDE y EXCLUDE incluyendo una "Requested List" que contiene una lista de fuentes que tienen un "source-timer" con valor mayor que cero y una "Exclude List" que contiene una lista de fuentes que tienen un "source-timer" de valor cero, - transmitir para la interfaz de red y para cada dirección de grupo multicast, paquetes multicast a los hosts (200,220,225,230) basados en la información del registro de fuentes INCLUDE y del registro de fuentes EXCLUDE, - transmitir para cada fuente INCLUDE de una dirección de grupo multicast que tiene un "source-timer" con valor mayor que cero paquetes multicast a través de la interfaz de red, y - cuando existe un registro de fuentes EXCLUDE transmitir también paquetes multicast de las fuentes restantes de las direcciones de grupo multicast a través de la interfaz de red excepto las fuentes EXCLUDE de la "Exclude List"

Tipo: Patente Internacional (Tratado de Cooperación de Patentes). Resumen de patente/invención. Número de Solicitud: PCT/EP2007/008655.

Solicitante: MEDIA PATENTS, S. L.

Nacionalidad solicitante: España.

Inventor/es: FERNANDEZ GUTIERREZ,ALVARO.

Fecha de Publicación: .

Fecha Solicitud PCT: 5 de Octubre de 2007.

Clasificación Internacional de Patentes:

  • H04L12/18M

Clasificación PCT:

  • H04L12/18 ELECTRICIDAD.H04 TECNICA DE LAS COMUNICACIONES ELECTRICAS.H04L TRANSMISION DE INFORMACION DIGITAL, p. ej. COMUNICACION TELEGRAFICA (disposiciones comunes a las comunicaciones telegráficas y telefónicas H04M). › H04L 12/00 Redes de datos de conmutación (interconexión o transferencia de información o de otras señales entre memorias, dispositivos de entrada/salida o unidades de tratamiento G06F 13/00). › para la difusión o las conferencias.

Países PCT: Austria, Bélgica, Suiza, Alemania, Dinamarca, España, Francia, Reino Unido, Grecia, Italia, Liechtensein, Luxemburgo, Países Bajos, Suecia, Mónaco, Portugal, Irlanda, Eslovenia, Finlandia, Rumania, Chipre, Lituania, Letonia.

PDF original: ES-2358546_T3.pdf

 

Ilustración 1 de ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.
Ilustración 2 de ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.
Ilustración 3 de ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.
Ilustración 4 de ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.
Ilustración 5 de ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.
Ilustración 6 de ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.
ROUTER PARA ADMINISTRAR GRUPOS MULTICAST.

Fragmento de la descripción:

Campo de la invención

[001] La invención se sitúa en el campo de la tecnología multidifusión o "multicast" en redes de datos. Más concretamente, la invención se refiere a un procedimiento de gestión de tráfico multicast en una red de datos, donde unas fuentes emiten datos dirigidos a por lo menos un grupo multicast y una pluralidad de hosts reciben de un router los datos emitidos por una o varias de dichas fuentes que emiten en dicho grupo multicast, dichos hosts y dicho router comunicándose mediante un protocolo de comunicaciones, como por ejemplo el protocolo IGMP (Internet Group Management Protocol) o el protocolo MLD (Multicast Listener Discovery), que permite unas comunicaciones multicast host-router a través de las cuales dicho host puede definir, para dicho grupo multicast, una lista de fuentes incluidas para indicar que desea recibir los datos emitidos por las fuentes de dicha lista y una lista de fuentes excluidas para indicar que desea recibir el tráfico de todas las fuentes de dicho grupo multicast excepto las fuentes de dicha lista.

[002] La invención también se refiere a unos dispositivos que aplican dicho procedimiento.

Estado de la técnica

[003] La tecnología multicast hace posible enviar datos desde una única fuente a muchos destinatarios a través de una red de datos, sin que sea necesario establecer una comunicación unicast, es decir una comunicación individual uno a uno entre la fuente y cada uno de los destinatarios. Para ello, la fuente envía datos, en forma de paquetes de datos, a una única dirección asociada a un grupo multicast al que pueden suscribirse los equipos interesados en ser destinatarios de dicha emisión de datos. Esta dirección, denominada dirección multicast o también dirección de grupo multicast, es una dirección IP (Internet Protocol) escogida dentro de un rango que está reservado para las aplicaciones multicast. Los paquetes de datos que han sido enviados por la fuente a la dirección multicast son entonces replicados en los diferentes routers de la red para que lleguen a los destinatarios que se han unido al grupo multicast.

[004] Normalmente, los destinatarios de las emisiones de datos en un grupo multicast son equipos conectados a la red de datos mediante un proxy o un router. En adelante, se utilizará el término habitual "host" para denominar a dichos equipos destinatarios. Un host puede ser, por ejemplo, un ordenador o un "set top box" conectado a un televisor.

[005] Cuando un host quiere recibir la información emitida por una o varias fuentes de un grupo multicast, envía al router más cercano, o a un proxy intermedio, un mensaje de suscripción a dicho grupo para que el router le transmita los datos que llegan a través de la red de datos y que han sido emitidos por las fuentes del grupo multicast. Asimismo, cuando un host desea dejar de recibir las emisiones de datos en el grupo multicast, envía al router o al proxy un mensaje de baja para dejar de recibirlas.

[006] Los mensajes intercambiados entre un host y el router más cercano para gestionar la pertenencia a un grupo multicast utilizan el protocolo IGMP (Internet Group Management Protocol) o bien el protocolo MLD (Multicast Listener Discovery), según si el router funciona con la versión 4 (IPv4) o con la versión 6 (IPv6) del protocolo IP (Internet Protocol), respectivamente.

[007] Cuando hay un proxy entre el host y el router, el proxy también utiliza los protocolos IGMP/MLD para intercambiar con el host, el router más cercano u otro proxy intermedio los mensajes de pertenencia al grupo multicast. En estos casos, el proxy puede recibir de distintos hosts peticiones de suscripción o de baja a un grupo multicast, y las agrupa para reducir así el tráfico de mensajes IGMP/MLD que envía al router.

[008] Por otra parte, los routers intercambian entre ellos unos mensajes con la finalidad de definir el ruteo que permita encaminar de forma eficiente los datos desde las fuentes hasta los hosts que se han suscrito a un grupo muilticast. Para ello, los routers utilizan unos protocolos específicos, entre los cuales el más extendido es el PIM-SM (Protocol Independent Muticast - Sparse Mode).

[009] En resumen, los routers reciben de los hosts, en forma de mensajes IGMP/MLD, una información que especifica de qué grupos multicast quieren recibir el tráfico, y se comunican con otros routers, por ejemplo mediante el protocolo PIM-SM, con el fin de establecer un ruteo que haga llegar hasta los hosts el tráfico solicitado por éstos.

[010] Todos los protocolos mencionados están definidos y documentados por la Internet Engineering Task Force (IETF).

[011] La versión del protocolo IGMP que se utiliza actualmente es la IGMPv3, que está descrita en las especificaciones RFC 3376 editadas en línea por la IETF (B. Cain et al., Engineering Task Force, Network Working Group, Request for Comments 3376, octubre de 2002; actualmente disponibles en la dirección Internet http://tools.ietf.org/html/rfc3376).

[012] En cuanto al protocolo MDL, la versión que se utiliza actualmente es la MDLv2, que está descrita en las especificaciones RFC 3810 editadas en línea por la IETF (R. Vida et al., Engineering Task Force, Network Working Group, Request for Comments 3810, junio de 2004; actualmente disponibles en la dirección Internet http://tools.ietf.org/html/rfc3810).

[013] El funcionamiento de un proxy IGMP que utiliza los protocolos IGMP/MLD está descrito en las especificaciones RFC 4605 editadas en línea por la IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4605, agosto de 2006; actualmente disponibles en la dirección Internet http://tools.ietf.org/html/rfc4605).

[014] El protocolo PIM-SM utilizado para la comunicación entre los routers está descrito en las especificaciones RFC 4601 editadas en línea por la IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4601, agosto de 2006; actualmente disponibles en la dirección Internet http://tools.ietf.org/html/rfc4601).

[015] Inicialmente, la tecnología multicast se implementó principalmente para aplicarla al modelo de comunicación muchos-a-muchos, conocido como ASM (“Any Source Multicast”), en el cual muchos usuarios se comunican entre sí y cualquiera de ellos puede emitir datos y también recibir datos de todos los demás. Una aplicación típica de ASM es la multiconferencia a través de Internet.

[016] Posteriormente, la tecnología musticast se implementó para aplicarla al modelo de comunicación uno-amuchos, conocido como SSM (“Source Specific Multicast”), en el cual una sola fuente emite datos para muchos destinatarios. La radio y la televisión a través de Internet son aplicaciones de SSM. Por esta razón, el SSM presenta actualmente un gran interés.

[017] En las primeras versiones del protocolo IGMP un host no podía elegir las fuentes emisoras de datos a las que quería suscribirse dentro de un grupo multicast, si no que sólo podía suscribirse o darse de baja al grupo para todas las fuentes. Los mensajes que enviaba un host a un router eran muy sencillos: Join(G) para recibir tráfico del grupo multicast G y Leave (G) para dejar de recibirlo. Por lo tanto, las primeras versiones del protocolo IGMP no permitían el SSM.

[018] Para permitir el SSM, en la versión IGMPv3 del protocolo IGMP se introdujo la posibilidad de que los hosts pudieran escoger las fuentes dentro de un grupo multicast. Para ello, un host puede enviar dos tipos de menajes IGMP:

- Un mensaje INCLUDE, que consiste en indicar las direcciones IP de las fuentes de las cuales sí desea recibir la emisión de datos. A las direcciones IP de las fuentes elegidas, siguiendo la terminología de las especificaciones RFC 3376, se las denomina fuentes INCLUDE.

- Un mensaje EXCLUDE, que consiste en indicar las direcciones IP de las fuentes de las cuales no desea recibir la emisión de datos. En este caso, se interpreta que el host desea recibir los datos emitidos por todas las fuentes menos las fuentes indicadas como excluidas en el mensaje. A las direcciones IP de las fuentes excluidas, siguiendo asimismo la terminología de las especificaciones RFC 3376, se las denomina fuentes EXCLUDE.

[019] Para ahorrar memoria, tráfico de datos o por otros motivos, en la versión IGMPv3 se decidió que cada interfaz de red y grupo multicast podría funcionar sólo en uno de los dos modos siguientes, pudiendo pasar de uno a otro: un modo... [Seguir leyendo]

 


Reivindicaciones:

1. Un router multicast (260) que tiene una o más interfaces de red “downstream” y situado en una red de datos entre fuentes (295,296,297,298,299) que transmiten paquetes multicast dirigidos a por lo menos una dirección de grupo multicast y uno o más hosts (200,220,225,230) que solicitan, de al menos una de las fuentes, los datos multicast enviados a por lo menos una dirección de grupo multicast,

el router multicast (260) caracterizado porque está adaptado para:

- almacenar para una interfaz de red “downstream” y dirección de grupo multicast un registro de fuentes INCLUDE que contiene información acerca de las listas de fuentes INCLUDE derivada de las solicitudes de datos realizadas por los uno o más hosts (200,220,225,230) y un registro de fuentes EXCLUDE que contiene información acerca de las listas de fuentes EXCLUDE derivadas de las solicitudes de datos realizadas por los uno o más hosts (200,220,225,230),

- usar un protocolo de enrutamiento multicast host-router basado en el protocolo IGMP, “Internet Group Management Protocol”, o el protocolo MLD, “Multicast Listener Discovery” para comunicarse con los uno o más hosts (200,220,225,230) y un protocolo de ruteo multicast router-router para comunicarse con por lo menos otro router multicast (261,262,263,264,265,266,267) situado entre él mismo y las fuentes (295,296,297,298,299), el router multicast

(260) incluyendo un “source-timer” para cada una de las fuentes en la lista de fuentes INCLUDE y en la listas de fuentes EXCLUDE y EXCLUDE incluyendo una “Requested List” que contiene una lista de fuentes que tienen un “source-timer” con valor mayor que cero y una “Exclude List” que contiene una lista de fuentes que tienen un “source-timer” de valor cero,

- transmitir para la interfaz de red y para cada dirección de grupo multicast, paquetes multicast a los hosts (200,220,225,230) basados en la información del registro de fuentes INCLUDE y del registro de fuentes EXCLUDE,

- transmitir para cada fuente INCLUDE de una dirección de grupo multicast que tiene un “source-timer” con valor mayor que cero paquetes multicast a través de la interfaz de red, y

- cuando existe un registro de fuentes EXCLUDE transmitir también paquetes multicast de las fuentes restantes de las direcciones de grupo multicast a través de la interfaz de red excepto las fuentes EXCLUDE de la “Exclude List”.

2. Un router multicast según la reivindicación 1, donde el registro de fuentes INCLUDE almacenado en el router multicast

(260) contiene la unión de todas las listas de fuentes INCLUDE solicitadas desde los hosts (200,220,225,230).

3. Un router multicast según la reivindicación 1, donde el registro de fuentes EXCLUDE almacenado en el router multicast (260) contiene la intersección de todas las listas de fuentes EXCLUDE solicitadas desde los hosts (200,220,225,230).

4. Un router multicast según la reivindicación 1, donde el router multicast (260) está adaptado para almacenar para la interfaz de red y dirección de grupo multicast sólo un registro de fuentes INCLUDE y solo un registro de fuentes EXCLUDE, el registro de fuentes INCLUDE contiene la unión de todas las listas de fuentes INCLUDE solicitadas desde los hosts (200,220,225,230) y el registro de fuentes EXCLUDE contiene la intersección de todas las listas de fuentes EXCLUDE solicitadas desde los hosts (200,220,225,230).

5. Un router multicast según la reivindicación 1, donde por lo menos un registro de fuentes INCLUDE para una interfaz de red y dirección de grupo multicast comprende (multicast-address, INCLUDE,{source list and timers}), y por lo menos un registro de fuentes EXCLUDE comprende (multicast-address,EXCLUDE,{source list and timers}), donde {source list and timers} comprende una lista de elementos {source-address y source-timer}, y donde source-address comprende la dirección IP de la fuente, y donde source-timer comprende un timer asociado a la fuente.

6. Un router multicast según la reivindicación 1, donde el router multicast (260) contiene instrucciones ejecutables para actualizar por lo menos un registro de fuentes INCLUDE y por lo menos un registro de fuentes EXCLUDE sobre la recepción desde los uno o más hosts (200,220,225,230) un mensaje de estado el cual contiene información acerca de una lista de fuentes INCLUDE y/o sobre una lista de fuentes EXCLUDE o un mensaje de cambio de estado que contiene información acerca de modificaciones de una lista de fuentes INCLUDE y/o información sobre modificaciones de una lista de fuentes EXCLUDE.

7. Un router multicast según la reivindicación 1, donde el router multicast (260) está adaptado para recibir un mensaje de estado originado desde uno o más hosts (200,220,225,230) que incluye instrucciones acerca del método que el router multicast (260) debe utilizar para establecer los árboles de ruteo desde las fuentes (295,296,297,298,299) hacia el router multicast (260).

8. Un router multicast según la reivindicación 1, donde el router multicast (260) almacena instrucciones ejecutables para

(1) mantener, para cada interfaz de red “downstream” y dirección de grupo multicast el registro de fuentes INCLUDE y el registro de fuentes EXCLUDE, y (2) actualizar el registro de fuentes INCLUDE y el registro de fuentes EXCLUDE, para cada dirección de grupo multicast, cuando el router multicast recibe, a través de su propia interfaz de red “downstream”, un mensaje que contiene información acerca de una lista de fuentes INCLUDE e información acerca de una lista de fuentes EXCLUDE originarias de uno o más de los hosts (200,220,225,230).

9. Un router multicast según la reivindicación 1, donde para una dirección de grupo multicast el router multicast (260) incluye una interfaz de red “upstream” la cual está adaptada para solicitar los datos provenientes de las fuentes (295,296,297,298,299) vía de al menos otro router multicast (261,262,263,264,265,266,267) situado dentro del árbol de ruteo entre las fuentes (295,296,297,298,299) y el router multicast (260), la interfaz de red “upstream” adaptada para comunicarse con por lo menos otro router multicast (261,262,263,264,265,266,267) vía el protocolo de ruteo multicast de router-router para solicitar los datos provenientes de las fuentes (295,296,297,298,299) usando la información en el registro de fuentes INCLUDE y la información en el registro de fuentes EXCLUDE para permitir una conexión directa con las fuentes (295,296,297,298,299) a través del árbol de ruteo de tipo “shortest path tree”.

10. Un router multicast según la reivindicación 1, donde para una dirección de grupo multicast el router multicast (260) incluye una interfaz de red “upstream” la cual está adaptada para solicitar los datos provenientes de las fuentes (295,296,297,298,299) a través de una pluralidad de routers multicast (261,262,263,264,265,266,267) los cuales incluyen un “Rendezvous Point Router” (264), la pluralidad de routers multicast (261,262,263,264,265,266,267) situada dentro de un árbol de ruteo entre las fuentes (295,296,297,298,299) y el router multicast (260), el árbol de ruteo incluye el “rendezvous point tree”, RPT (281,282), y “shortest path trees” SPT (291,292), para las fuentes (295,296,297,298,299), la interfaz de red “upstream” adaptada para comunicarse con la pluralidad de routers multicast (261,262,263,264,265,266,267) a través del protocolo de ruteo multicast de router-a-router para solicitar los datos desde las fuentes (295,296,297,298,299) utilizando la información en el registro de fuentes INCLUDE y la información en el registro de fuentes EXCLUDE para permitir una conexión directa con las fuentes (295,296,297,298,299) a través de los “shortest path trees” (291,292) sin necesidad de usar los “rendezvous point trees” (281,282).

11. Un router multicast según la reivindicación 1, que está adaptado en respuesta a la recepción de una interfaz de red “downstream” de un mensaje de tipo IS_IN (x) para una dirección de grupo multicast para no modificar ningún registro de fuentes EXCLUDE para el grupo multicast.

12. Un router multicast según la reivindicación 1, que está adaptado en respuesta a la recepción de una interfaz de red “downstream” de un mensaje de tipo IS_EX (x) para una dirección de grupo multicast no modifique ningún registro de fuentes INCLUDE.

13. Un router multicast según la reivindicación 1, donde para cada interfaz de red “downstream” y dirección de grupo multicast el router multicast (260) está adaptado para transmitir a los hosts (200,220,225,230) datos desde las fuentes (295,296,297,298,299) en la lista de fuentes INCLUDE y transmitir también a los hosts (200,220,225,230) datos provenientes de todas las fuentes restantes (295,296,297,298,299) excepto aquellas fuentes de la “Exclude List” cuando existe un registro de fuentes EXCLUDE para dicha dirección de grupo multicast.

14. Un router multicast según la reivindicación 1, donde el router multicast (260) está configurado para recibir mensajes originando desde los uno o más hosts (200,220,225,230) solicitando al router multicast (260) que detenga el envío de datos desde una fuente (295,296,297,298,299) en una dirección de grupo multicast, el router multicast (260) también configurado para enviar mensajes del tipo “Group-And-Source-Specific Query” a los uno o más hosts (200,220,225,230), el router multicast (260) almacena unas instrucciones ejecutables para determinar si uno o otros más hosts (200,220,225,230) están recibiendo datos desde la fuente (295,296,297,298,299) en la dirección de grupo multicast sobre la recepción de la petición de parada utilizando el registro de fuentes INCLUDE y el registro de fuentes EXCLUDE y de continuar enviando datos desde la fuente (295,296,297,298,299) en la dirección de grupo multicast en la dirección de grupo multicast a los otros uno o más hosts (200,220,225,230) sin enviar mensajes del tipo “Group-And-Source-Specific Query” a los otros uno o más hosts (200,220,225,230), recibiendo datos desde la fuente (295,296,297,298,299) en la dirección de grupo multicast.

15. Un router multicast según las reivindicaciones 9 o 10, donde el protocolo de ruteo multicast de router-a-router es una versión de un protocolo PIM-SM, Protocol Independent Multicast – Sparse Mode.

 

Patentes similares o relacionadas:

CONTROL DE ACCESO PARA PETICIONES DE CANAL MULTIFUSIÓN, del 19 de Septiembre de 2011, de TELEFONAKTIEBOLAGET L M ERICSSON (PUBL): El método para el control de acceso en un sistema de multidifusión cuando la distribución de los datos desde una fuente (VS) en un enlace común (L3) […]

Imagen de 'PROCEDIMIENTO Y SISTEMA DE MENSAJERÍA INSTANTÁNEA PARA TERMINALES…'PROCEDIMIENTO Y SISTEMA DE MENSAJERÍA INSTANTÁNEA PARA TERMINALES MÓVILES EQUIPADOS CON UN SERVIDOR DE PRESENCIA VIRTUAL CONFIGURADO PARA GESTIONAR DIFERENTES LISTAS DE CONTACTOS DE UN MISMO USUARIO, del 26 de Mayo de 2011, de MIYOWA: Sistema de mensajería instantánea para terminales móviles, que comprende: - uno o varios servidores de mensajería instantánea (S1, S2) aptos para suministrar servicios de […]

Imagen de 'PROCEDIMIENTO PARA TRANSMITIR LA IDENTIDAD DE UN MENSAJE DE MULTIDIFUSIÓN,…'PROCEDIMIENTO PARA TRANSMITIR LA IDENTIDAD DE UN MENSAJE DE MULTIDIFUSIÓN, PROCEDIMIENTO Y DISPOSITIVO PARA TRANSMITIR UN MENSAJE DE MULTIDIFUSIÓN, ASÍ COMO DISPOSITIVO PARA RECIBIR UN MENSAJE DE MULTIDIFUSIÓN, del 21 de Enero de 2011, de NOKIA SIEMENS NETWORKS GMBH & CO. KG: Procedimiento para transmitir una identidad de un mensaje de multidifusión desde un emisor a varios receptores conectados con el emisor a través de un medio de transmisión […]

Imagen de 'ASIGNACION DE NSAPI (IDENTIFICADOR DE ACCESO DEL SERVICIO DE…'ASIGNACION DE NSAPI (IDENTIFICADOR DE ACCESO DEL SERVICIO DE CAPA DE RED) PARA MBMS (SERVICIOS DE DIFUSION Y MULTIDIFUSION DE MULTIMEDIA), del 21 de Octubre de 2010, de TELEFONAKTIEBOLAGET LM ERICSSON (PUBL): Procedimiento de transmisión de datos multidifusión asociados con un servicio multidifusión desde una red inalámbrica a una estación móvil suscriptora en […]

Procesamiento de contenido y servicios de redes para dispositivos móviles o fijos, del 8 de Julio de 2020, de AMIKA MOBILE CORPORATION: Un sistema para suministrar contenido de red a un dispositivo, comprendiendo el sistema : una primera interfaz para comunicarse con una pluralidad […]

Reparación de archivo completo usando fragmento de descripción de programa en eMBMS, del 1 de Julio de 2020, de QUALCOMM INCORPORATED: Un procedimiento de comunicación inalámbrica de un equipo de usuario, UE, que comprende: recibir una descripción de programa de radiodifusión […]

Procedimiento y aparato de comunicación de grupo en un sistema de comunicación inalámbrica, del 13 de Mayo de 2020, de SAMSUNG ELECTRONICS CO., LTD.: Un procedimiento de una estación base en un sistema de comunicación móvil, comprendiendo el procedimiento: recibir (S720) un primer mensaje que incluye información […]

Procedimientos y aparatos para señalizar parámetros de acceso mejorado a canales distribuidos para subconjuntos de dispositivos inalámbricos, del 29 de Abril de 2020, de QUALCOMM INCORPORATED: Un procedimiento para configurar parámetros de acceso a canal en un sistema de comunicación inalámbrica , comprendiendo el procedimiento: […]

Utilizamos cookies para mejorar nuestros servicios y mostrarle publicidad relevante. Si continua navegando, consideramos que acepta su uso. Puede obtener más información aquí. .