Método para medir la calidad de servicio, método de transmisión , dispositivo y sistema de mensajes.

Un dispositivo para reenviar un mensaje de informe de expedidor con Protocolo de Control en Tiempo Real,

RTCPSR, caracterizado por comprender:

una unidad de recepción de mensaje, configurada para recibir un primer mensaje RTCP SR desde un expedidor demensaje o desde un monitor en sentido ascendente adyacente;

una unidad de cálculo de parámetros de calidad de servicio, QoS, configurada para calcular parámetros QoS de un flujode datos con Protocolo en Tiempo Real, RTP, correspondiente al mensaje RTCP SR entre el expedidor de mensajes y eldispositivo;

una unidad generadora de nuevo mensaje, configurada para generar un segundo mensaje RTCP SR, en función delprimer mensaje RTCP SR recibido por la unidad de recepción de mensajes y los parámetros QoS calculados por launidad de cálculo de parámetros QoS y

una unidad de suministro de mensajes, configurada para suministrar el segundo mensaje RTCP SR generado por launidad generadora de nuevo mensaje a un monitor de flujo descendente adyacente.

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

Solicitante: HUAWEI TECHNOLOGIES CO., LTD..

Nacionalidad solicitante: China.

Dirección: HUAWEI ADMINISTRATION BUILDING BANTIAN LONGGANG DISTRICT SHENZHEN GUANGDONG PROVINCE 518129 CHINA.

Inventor/es: LIU, YING.

Fecha de Publicación: .

Clasificación Internacional de Patentes:

  • H04L12/00 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). › 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).

PDF original: ES-2383109_T3.pdf

 

Método para medir la calidad de servicio, método de transmisión , dispositivo y sistema de mensajes.

Fragmento de la descripción:

Método para medir la calidad de servicio, método de transmisión, dispositivo y sistema de mensajes CAMPO DE LA TECNOLOGÍA

La presente invención se refiere al campo de la tecnología de redes y más en particular, a un método, dispositivo y sistema para medir la calidad de servicio (QoS) .

ANTECEDENTES DE LA INVENCIÓN

Junto con el incremento de la demanda de servicio y el desarrollo de la tecnología de redes de protocolo de Internet (IP) , cada vez se transmiten más servicios en tiempo real a través de la red IP. Servicios de voz, vídeo, multimedia, teleconferencia y otros servicios en tiempo real establecen un nuevo reto para la red IP y recientemente se ha convertido en una cuestión clave para garantizar la calidad de los servicios en tiempo real. Un Protocolo en Tiempo Real (RTP) es un protocolo de transmisión extremo a extremo y está configurado para transmitir datos de los servicios en tiempo real y números de secuencia (SNs) , estampillas temporales y otra información suministrada por el RTP con referencias a un extremo de destino del mensaje para la reestructuración del mensaje. Sin embargo, el propio protocolo RTP no proporciona ninguna garantía sobre la calidad de servicio QoS de un flujo de datos del servicio en tiempo real ni garantiza la transmisión en tiempo real ni calcula los parámetros de QoS con un Protocolo de Control en Tiempo Real (RTCP) , en cuanto a proporcionar las referencias para el control de la transmisión en el extremo origen del flujo de datos. El protocolo RTCP realiza una realimentación de los parámetros QoS de la capa de red extremo a extremo, por ejemplo, retardo de red, fluctuación del retardo y fracción perdida.

La calidad de servicio QoS se suele garantizar a partir de dos aspectos. Cuando la QoS es normal, se realiza una inspección de rutina sobre la QoS para tomar precauciones. Cuando la QoS tiene problemas, los problemas son planteados lo antes posible y se averiguan los motivos del cambio de la QoS, con el fin de tomar las medidas de modificación correspondientes. En un método de posicionamiento común, se miden los cambios del rendimiento de QoS durante el procedimiento de transmisión de servicio y los problemas se posicionan en función de índices del rendimiento establecidos, por ejemplo, el retardo de red, la fluctuación del retardo, la fracción perdida y un umbral de cada índice. Los atributos del RTP/RTCP determinan que el RTP/RTCP se puede configurar para medir los parámetros de QoS de los servicios en tiempo real en la red. Los resultados de la medición reflejan las situaciones de la calidad de servicio QoS de los servicios y se proporcionan, además, para otras entidades, tales como una entidad de control de admisión de recursos (RAC) a utilizar.

Recientemente, el método común para medir QoS a través de RTP/RTCP incluye principalmente una medición activa y una medición pasiva.

En la medición activa de la QoS, se supone que un equipo de las instalaciones del cliente remitente (CPE) CPE-A es un expedidor de mensajes, un CPE-B receptor es un receptor de mensajes y tres monitores, esto es, monitor 1, monitor 2 y monitor 3 se establecen entre el expedidor CPE-A y el receptor CPE-B. El expedidor CPE-A envía un flujo de datos de RTP/RTCP SR al receptor CPE-B y tres monitores, esto es, monitor 1, monitor 2 y monitor 3 en secuencia se establecen en una ruta a través de la cual pasa el flujo de datos de RTP/RTCP SR. En la medición activa, cuando se controla el flujo de datos RTP, extremo a extremo, el monitor necesita generar, además, un mensaje de informe del expedidor de RTCP SR (RTCP SR) /mensaje de informe de receptor de RTCP (RTCP RR) correspondiente a los datos de RTP e interacciona con otros monitores utilizando mensajes RTCP SR/RTCP RR extras, con el fin de obtener los parámetros de QoS entre el monitor y otros monitores.

En la medición activa, aunque el resultado de la medición a través de segmentos de la red se puede proporcionar, el resultado de la medición tiene una relación directa con los monitores establecidos entre los segmentos de la red. Cuantos más monitores se hayan establecido, tanto más valioso será el resultado de la medición. Sin embargo, además de reenviar el mensaje de RTP/RTCP los monitores tienen que generar el mensaje RTCP SR/RR extra para interaccionar entre sí, con el consiguiente aumento de la carga de trabajo de la red.

Haciendo referencia a la Figura 1, se ilustra una vista esquemática de un método para la medición pasiva de QoS a través de RTP/RTCP en la técnica anterior. En la medición pasiva, un monitor controla un flujo de datos de RTP/RTCP que pasa a través del monitor actual y calcula, respectivamente, los parámetros de QoS del flujo de datos de RTP/RTCP entre un expedidor del mensaje y el monitor actual y entre el monitor actual y un receptor de mensajes. En particular, según se ilustra en la Figura 1, dos monitores, esto es, monitor 1 y monitor 2, se establecen entre un expedidor CPE-A y un receptor CPE-B, pasando el flujo de datos de RTP/RTCP enviado por el remitente CPE-A al receptor CPE-B, a través del monitor 1 y del monitor 2 en secuencia. El método incluye, en particular, las etapas siguientes:

En la etapa 101, el expedidor CPE-A envía el mensaje de RTP/RTCP SR.

En la etapa 102 y en la etapa 102', el monitor 1 y el monitor 2 registran la información del mensaje RTP recibido en secuencia, en donde la información incluye un número y un retardo de transmisión de los mensajes RTP.

En la etapa 103, cuando el mensaje RTCP SR alcanza el monitor 1, el monitor 1 registra un tiempo de alcance del mensaje RTCP SR y extrae la información del expedidor CPE-A, en donde la información incluye un identificador fuente de sincronización del expedidor (SSRC) y un número máximo de los mensajes enviados. A continuación, una fracción perdida, una fluctuación del retardo, un número acumulativo de paquetes perdidos y otros parámetros del rendimiento de QoS de los datos RTP, en dos periodos de tiempo de mensajes RTCP SR sucesivos, se calculan durante el procedimiento de transmisión de los datos RTP entre el expedidor CPE-A y el monitor actual (es decir, el monitor 1) .

En la etapa 104, el monitor 1 reenvía continuamente el mensaje RTCP SR a un monitor siguiente (es decir, monitor 2) .

En la etapa 105, el procedimiento de procesamiento es similar al de la etapa 103. Después de recibir el mensaje RTCP SR, el monitor 2 calcula la fracción perdida, la fluctuación del retardo, el número acumulativo de paquetes perdidos y otros parámetros del rendimiento de QoS de los datos RTP en los dos periodos de tiempo de mensajes RTCP SR sucesivos, durante el procedimiento de transmisión de los datos RTP entre el expedidor CPE-A y el monitor actual (es decir, monitor 2) .

En la etapa 106, el mensaje RTCP SR se reenvía continuamente al receptor CPE-B.

En la etapa 107, el receptor CPE-B calcula los parámetros de QoS, extremo a extremo, incluyendo la fracción perdida, la fluctuación del retardo, el número acumulativo de paquetes perdidos y un tiempo dedicado a generar el mensaje RTCP RR, en función de la información del mensaje RTP/RTCP SR y luego, genera el mensaje RTCP RR.

En la etapa 108, el mensaje RTCP RR generado se reenvía al expedidor CPE-A.

En la etapa 109, cuando se detecta el mensaje RTCP RR generado reenviado por el receptor CPE-B, el monitor 2 extrae los parámetros QoS, extremo a extremo, y compara los parámetros QoS con los parámetros QoS calculados por el monitor actual (es decir, monitor 2) , con el fin de obtener los parámetros de rendimiento de QoS del flujo de datos RTP entre el monitor actual y el receptor CPE-B.

En la etapa 110, se reenvía continuamente el mensaje RTCP RR generado.

En la etapa 111, cuando el monitor 1 controla también el mensaje RTCP RR generado, el monitor 1 calcula los parámetros del rendimiento de QoS del flujo de datos RTP entre el monitor actual (monitor 1) y el monitor CPE-B, en función del método de cálculo que es el mismo que el del monitor 2.

En la etapa 112, el monitor 1 reenvía continuamente el mensaje RTCP RR generado.

En la etapa 113, el expedidor CPE-A recibe finalmente el mensaje RTCP RR, obtiene los parámetros del rendimiento de QoS, extremo a extremo, y calcula un tiempo de ida y vuelta (RTT) , extremo a extremo.

Puede deducirse del procedimiento anterior que en la medición pasiva, aunque no se introduce ningún nuevo mensaje RTCP, en la medición pasiva el monitor... [Seguir leyendo]

 


Reivindicaciones:

1. Un dispositivo para reenviar un mensaje de informe de expedidor con Protocolo de Control en Tiempo Real, RTCP SR, caracterizado por comprender:

una unidad de recepción de mensaje, configurada para recibir un primer mensaje RTCP SR desde un expedidor de mensaje o desde un monitor en sentido ascendente adyacente;

una unidad de cálculo de parámetros de calidad de servicio, QoS, configurada para calcular parámetros QoS de un flujo de datos con Protocolo en Tiempo Real, RTP, correspondiente al mensaje RTCP SR entre el expedidor de mensajes y el dispositivo;

una unidad generadora de nuevo mensaje, configurada para generar un segundo mensaje RTCP SR, en función del primer mensaje RTCP SR recibido por la unidad de recepción de mensajes y los parámetros QoS calculados por la unidad de cálculo de parámetros QoS y una unidad de suministro de mensajes, configurada para suministrar el segundo mensaje RTCP SR generado por la unidad generadora de nuevo mensaje a un monitor de flujo descendente adyacente.

2. El dispositivo según la reivindicación 1, caracterizado porque:

la unidad de recepción de mensajes está configurada, además, para recibir un mensaje RTP, y para proporcionar el mensaje RTP a la unidad de cálculo de parámetros QoS;

la unidad de cálculo de parámetros QoS está configurada, además, para extraer un número de secuencia, SN, en el mensaje RTP con el fin de calcular una fracción perdida y extraer una estampilla temporal para calcular un retardo de transmisión y una fluctuación del retardo.

3. El dispositivo según la reivindicación 1 o la reivindicación 2, caracterizado porque: la unidad generadora de nuevo mensaje genera el segundo mensaje RTCP SR en la manera siguiente: generando un informe de recepción en función de los parámetros QoS calculados del flujo de datos RTP entre el

expedidor del mensaje y el dispositivo e insertando el informe de recepción en el Bloque de Informe de Recepción, RRB, del primer mensaje RTCP SR para poder generar el segundo mensaje RTCP SR.

4. Un método para reenviar un informe de expedidor del Protocolo de Control en Tiempo Real, RTCP SR, caracterizado porque comprende:

la recepción (1201) , por un primer monitor, de un primer mensaje RTCP SR desde un expedidor de mensaje o desde un monitor de flujo ascendente adyacente;

el cálculo (1201) , por el primer monitor, de parámetros de calidad de servicio, QoS, de un flujo de datos de Protocolo en Tiempo Real, RTP, correspondiente al mensaje RTCP SR entre el expedidor del mensaje y el primer monitor;

la generación (1202) , por el primer monitor, de un segundo mensaje RTCP SR en función del primer mensaje RTCP SR y de los parámetros de QoS calculados;

el suministro (1203) del segundo mensaje RTCP SR a un monitor de flujo descendente adyacente.

5. El método según la reivindicación 4, caracterizado porque el método comprende, además: la recepción, por el primer monitor, de un mensaje RTP; la extracción de un número de secuencia, SN, en el mensaje RTP para calcular una fracción perdida y la extracción de una estampilla temporal para calcular un retardo de transmisión y una fluctuación de retardo.

6. El método según la reivindicación 4 o la reivindicación 5, en donde la generación de un segundo mensaje RTCP SR en función del primer mensaje RTCP SR y de los parámetros QoS calculados comprende:

la generación, por el primer monitor, de un informe de recepción en función de los parámetros QoS calculados entre el expedidor del mensaje y el primer monitor y la inserción, por el primer monitor, del informe de recepción, en un bloque de informe de recepción, RRB, del primer mensaje RTCP SR, de forma que se genere el segundo mensaje RTCP SR.

Receptor CPE-B

Expedidor CPE-A Monitor 1Monitor 2

Enviar un mensaje RTP/RTCP SR101. 102'. Registrar la información del Registrar información del 102. mensaje RTP

mensaje RP

Registrar un tiempo de alcance del mensaje RTCP103.

SR, extraer información de un expedidor CPE-A ycalcular parámetros QoS

Enviar el mensaje RTCP SR104.

Registrar un tiempo de alcance del mensaje RTCP105.

SR, extraer información del expedidor CPE-A y calcularparámetros QoS

Enviar el mensaje RTCP SR106.

El receptor CPE-B calcula107.

parámetros QoS, extremo a extremo, en función de la información del mensaje RTP/RTCP SR y luego, construye un mensaje RTCP RR

Reenviar el mensaje RTCP RR 108.

Figura 1A

CONT. DESDECONT. DESDECONT. DESDECONT. DESDEFIG. 1A FIG. 1A FIG. 1A FIG. 1A

Extraer los parámetros QoS, extremo a 109.extremo, en el mensaje RTCP RR y compararlos parámetros QoS con los parámetros QoScalculados por el monitor actual, con el fin de obtener los parámetros de rendimiento QoS delflujo RTP entre el monitor actual y el receptorCPE-B

Enviar el mensaje RTCP RR110.

Extraer los parámetros QoS, extremo a 111.extremo, en el mensaje RTCP RR y comparar los parámetros QoS con los parámetros QoScalculados por el monitor actual, con el fin de obtener los parámetros de rendimiento QoS del flujo RTP entre el monitor actual y el receptorCPE-B

Enviar el mensaje RTCP RR110.

Obtener los parámetros de 113.rendimiento QoS extremo a

extremo y calcular un RTT extremo a extremo

Figura 1B

Un primer monitor envía un mensaje RTCP SR recibido a un segundo monitor

El primer monitor recibe un mensaje RTCP RR extra enviado por el segundo monitor

El primer monitor calcula parámetros QoS entre el monitor actual y el segundo monitor en función del mensaje RTCP RR extra Figura 2

Un segundo monitor genera un mensaje RTCP RR cuando se reenvía el mensaje RTCP SR recibido, en donde el mensaje RTCP RR incluye un SSRC del expedidor, parámetros QoS calculados por el monitor actual y una estampilla temporal NTP cuando un expedidor genera el mensaje RTCP SR

El mensaje RTCP RR extra se envía en un dominio de SP, para calcular QoS entre monitores

Figura 3 Figura 4

Expedidor CPE-A Monitor 1 Monitor 3 Receptor CPE-B

501. Enviar un mensaje RTP/RTCP SR

502. Registrar información de 503. Registrar la información un mensaje RTP de un mensaje RTP

504. Registrar tiempo alcance delmensaje RTCP SR, extraer información de un expedidor CPE-A y calcular parámetros QoS

505. Reenviar el mensaje RTCP SR

506. Extraer el SSRC del expedidor del mensaje RTCP SR y calcular los parámetros QoS del flujo de datos RTP que alcanza el monitor actual

507. Enviar el mensaje RTCP RR extra al dominio de SP

508. Reenviar el mensaje RTCP SR

509. Extraer el SSRC del CPE-A y 510. Calcular los

determinar si el SSRC de CPE-A coincide con el SSRC registrado en el monitor parámetros QoS extremo a extremo en función del actual o no mensaje RTCP RR extra y generar un mensaje RTCP RR extremo a extremo

511. Enviar un mensaje RTCP RR extremo a extremo

Figura 5 Figura 6

ExpedidorReceptor CPE-B

CPE-A Enviar el mensaje RTP/RTCP SR701.

Registrar la702.703. Registrar la704. Registrar lainformación del información del información del mensaje RTP mensaje RTP mensaje RTP

Registrar el tiempo alcance del 705.mensaje RTCP SR, extraer la

información del expedidor CPE-A y calcular los parámetros QoS

Reenviar el mensaje RTCP SR706.

Extraer un SSRC del expedidor707.del mensaje RTCP SR y calcular los parámetros QoS del flujo de datosRTP que alcanza el monitor actual Enviar un mensaje RTCP RR extra en el708.dominio de SP en una manera de unidifusión A FIG. 7B A FIG. 7B A FIG. 7B A FIG. 7B A FIG. 7B

Figura 7A

CONT. DESDE CONT. DESDE FIG. 7A FIG. 7A

Extraer un SSRC en el 709.mensaje RTCP RR extra y determinar si el SSRC coincidecon el SSRC registrado en el monitor actual o no CONT. DESDE CONT. DESDE CONT. DESDE FIG. 7A FIG. 7A FIG. 7A

Reenviar el mensaje RTCP SR710.

Extraer el SSRC del 711.expedidor del mensaje RTCP SRy calcular los parámetros QoS del flujo de datos RTP que alcanza elmonitor actual Enviar el mensaje RTCP RR712.extra en el dominio de SP en la

Figura 7B

manera de unidifusión

Reenviar el 714.mensaje RTCP SR

Extraer un SSRC en el 713.mensaje RTCP RR extra y determinar si el SSRC coincidecon el SSRC registrado en el 715. Calcular parámetros monitor actual o no QoS extremo a extremoen función del mensaje RTCP SR extra y generar

un mensaje RTCP RRextremo a extremo

Enviar mensaje RTCP RR716.extremo a extremo Un primer monitor calcula y memoriza parámetros QoS de un flujo de datos RTP que alcanza el monitor actual, en función de un mensaje RTCP SR correspondiente al flujo de datos RTP y reenvía el mensaje RTCP SR a un segundo monitor

El segundo monitor genera un mensaje RTCP RR extra cuando se reenvía el mensaje RTCP y envía el mensaje RTCP RR extra en el dominio de SP

El primer monitor calcula parámetros QoS entre el monitor actual y el segundo monitor en función del mensaje RTCP RR extra recibido Figura 8

Primera unidad de Unidad recepción envío de mensajes mensajes

Unidad cálculo Sub-unidad de QoS segmento determinación red

Sub-unidad de comparación

Figura 9

Segunda unidad envío mensajes Unidad generadora mensajes Sub-unidad envío unidifusión Sub-unidad envío multidifusión

Figura 10

Primera unidad Unidad envío mensajes generadora mensajes Unidad recepción Segunda unidad mensajes envío mensajes Segundo dispositivo de mediciónUnidad de cálculo QoS segmento red

Primer dispositivo de medición

Figura 11

Recibir un mensaje RTCP SR y calcular parámetros QoS de un flujo de datos RTP entre un expedidor de mensajes y un monitor actual

Generar un nuevo mensaje RTCP SR enfunción del mensaje RTCP SR y los parámetros QoS calculados

Proporcionar el nuevo mensaje RTCP SR a un monitor de flujo descendente adyacente Figura 12 Figura 13

Figura 14

Recibir un mensaje RTCP SR que transmita parámetros QoS de un flujo de datos RTP entre un expedidor de mensajes y un monitor de flujo ascendente adyacente y calcular parámetros QoS del flujo de datos RTP correspondiente al mensaje RTCP SR entre el expedidor de mensajes y el monitor actual

Obtener parámetros QoS del flujo de datos RTP entre el monitor de flujo ascendente adyacente y el monitor actual, en función de los parámetros QoS del flujo de datos RTP entre el expedidor de mensajes y el monitor de flujo ascendente adyacente y los parámetros QoS entre el expedidor de mensajes y el monitor actual Figura 15

ExpedidorReceptormensajes mensajes 1601. Mensaje RTP/RTCP SR

1602. Registrar la información del flujode datos RTP y el tiempo de alcance del mensaje RTCP SR y calcular los parámetros QoS del flujo de datos RTPentre el expedidor de mensajes y el monitor actual 1603. El mensaje RTCP SR que transmite el informe de recepción

1604. Registrar la información del flujo de

datos RTP y el tiempo de alcance del mensaje RTCP SR, calcular los parámetros QoS del flujo de datos RTP entre el expedidor de

mensajes y el monitor actual e insertar el informe de recepción generado en la posición

original del informe de recepción generado

por el monitor 1 en el mensaje RTCP SR

enviado por el expedidor de mensajes o

memorizar el informe de recepción generado

en un mensaje RTCP SR independiente del mensaje RTCP SR enviado por el expedidor

de mensajes

Figura 16A

A FIG. 16B A FIG. 16B A FIG. 16B A FIG. 16B A FIG. 16B

CONT. DESDECONT. DESDECONT. DESDECONT. DESDECONT. DESDEFIG. 16A FIG. 16A FIG. 16A FIG. 16A FIG. 16A

1605. El mensaje RTCP SR que transmite el informe derecepción generado por el monitor 2

1606. Registrar la información del flujo dedatos RTP y el tiempo de alcance del mensaje RTCP SR, calcular los parámetros QoS del flujo de datos RTPentre el expedidor de mensajes y el monitor actual y eliminar el informe derecepción generado por el monitor 2 en el mensaje RTCP SR enviado por el monitor2 o eliminar otro mensaje RTCP SR que transmite el informe de recepcióngenerado por el monitor 2 eindependiente del mensaje RTCP SRenviado por el expedidor de mensajes

1607. El mensaje RTCP SRoriginal enviado por el expedidor de mensajes

1608. Calcularparámetros QoS, extremo a extremo, y generar unmensaje RTCP RRextremo a extremo

1608. Mensaje RTCP RR

Figura 16B

Longitud SSRC de expedidor

Fracción perdida Número acumulativo de paquetes perdidos Número de la más alta secuencia extendida recibida Fluctuación inter-llegada

Extensiones específicas del perfil Figura 17


 

Patentes similares o relacionadas:

Unidad de control para un sistema de alarma para un edificio y sistema de alarma, del 16 de Enero de 2020, de Verisure Sàrl: Unidad de control para un sistema de alarma para un edificio y sistema de alarma. Una unidad de control para un sistema de alarma para […]

DISPOSITIVO DE AUTOMATIZACIÓN DE EDIFICIOS EMPOTRABLE EN UNA CAJA ELÉCTRICA, del 5 de Diciembre de 2019, de ROBOT, S.A: Dispositivo de automatización de edificios empotrable en una caja eléctrica que se adapta a los diferentes requerimientos de comunicaciones, que comprende un módulo de comunicación […]

DISPOSITIVO DE AUTOMATIZACIÓN DE EDIFICIOS, del 21 de Noviembre de 2019, de ROBOT, S.A: Dispositivo de automatización de edificios que se adapta a los requerimientos de espacio y comunicaciones, comprende un módulo de comunicación […]

DISPOSITIVO DE AUTOMATIZACIÓN DE EDIFICIOS PARA SU DISPOSICIÓN EN UN CARRIL, del 21 de Noviembre de 2019, de ROBOT, S.A: Dispositivo de automatización de edificios para su disposición en un carril que se adapta a los requerimientos de espacio y comunicaciones, comprende […]

Aparato de cocción para procesamiento y elaboración de alimentos con interfaz de usuario externa, del 9 de Julio de 2019, de COMPAÑIA ESPAÑOLA DE ELECTROMENAJE, SA: Aparato de cocción para procesamiento y elaboración de alimentos con interfaz de usuario externa, del tipo que comprende: una estructura base […]

Sistema y procedimiento para el control y/o el análisis de un proceso industrial, del 20 de Marzo de 2019, de SIEMENS AKTIENGESELLSCHAFT: Sistema para el control y/o el análisis de un proceso industrial , el cual, del lado de la instalación, presenta al menos una unidad de automatización […]

Sistema de control, método de control y tablero de extensión, del 16 de Octubre de 2018, de YAMAHA HATSUDOKI KABUSHIKI KAISHA: Un sistema de control, comprendiendo: un dispositivo de control maestro configurado para controlar un primer objeto (RB1) controlado en base a información […]

RED DE CABINAS DE FOTOMATÓN, del 14 de Marzo de 2018, de DEDEM S.P.A: 1. Red de cabinas de fotomatón, caracterizada por el hecho de que comprende una pluralidad de terminales conectados entre sí a través de una red de telecomunicaciones, […]

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í. .