ES2364475T3

ES2364475T3 - Procedimiento para el análisis de las perturbaciones de un flujo de datos en tiempo real en una red de datos, sistema de comunicación y ordenador de control.

Info

Publication number: ES2364475T3
Application number: ES06778085T
Authority: ES
Inventors: Olaf ZÄNCKER
Original assignee: VoIPFuture GmbH; VOIPFUTURE Ltd
Current assignee: VoIPFuture GmbH; VOIPFUTURE Ltd
Priority date: 2005-08-18
Filing date: 2006-07-31
Publication date: 2011-09-05
Anticipated expiration: 2026-07-31
Also published as: ATE507672T1; EP1915849A1; US20080186872A1; DE502006009402D1; EP1915849B1; WO2007020182A1; DE102005039192A1; US8885485B2

Abstract

Procedimiento para el análisis de fallos de un flujo de datos en tiempo real, isócrono, en una red de datos (100) mediante una unidad de control (16) en la red de datos (100), que comprende las siguientes fases, que son realizadas por la unidad de control (16): recepción de paquetes de datos del flujo de datos en tiempo real isócrono, generación de una marca de tiempo para cada paquete de datos transmitido entre dos aparatos de comunicación (10, 12) de la red de datos (100), de manera que las marcas de tiempo caracterizan el punto de tiempo de la llegada de un correspondiente paquete de datos a la unidad de control (16), determinación de una distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos del flujo de datos en tiempo real isócrono que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono a partir de las marcas de tiempo del paquete de datos, comprobar la distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono, según un patrón, por comparación con un estado ideal del flujo de datos en tiempo real isócrono, de manera que los patrones permiten una identificación de fallos específicos en los aparatos de comunicación (10, 12) y en la red de transmisión de datos (14) que une los aparatos de comunicación, y determinación del lugar o de la causa del fallo en la transmisión del flujo de datos en tiempo real isócrono en la red de datos, basándose en el resultado de la comprobación de la distribución de frecuencias según un patrón.

Description

[001] Procedimiento para el análisis de las perturbaciones de un flujo de datos, en especial un flujo de datos en tiempo real en una red de datos, sistema de comunicación y ordenador de control.

[002] La invención se refiere a un procedimiento para el análisis de fallos de un flujo de datos, en especial un flujo de datos en tiempo real, en una red de datos. La invención se refiere además a un sistema de comunicación con un ordenador de control para el análisis de fallos de un flujo de datos, en especial un flujo de datos en tiempo real, entre dos aparatos de comunicación en una red de datos, refiriéndose también a un ordenador de control.

[003] La comunicación multimedia a través de redes de comunicación usando el Protocolo de Internet (IP), en la que se transportan en paralelo diferentes medios en tiempo real (datos, audio y vídeo), se va extendiendo progresivamente. Para la transmisión de datos en tiempo real (datos de audio y de vídeo) a través de las redes de comunicación IP no se pueden utilizar protocolos concebidos para la comunicación de datos, puesto que en base a la comunicación en tiempo real no es posible un control de fallos, por ejemplo, con comprobantes, tal como es posible en la comunicación de datos conocida hasta el momento. Además, con el procedimiento concebido para la comunicación de datos, no es posible determinar el isocronismo, que es importante para la comunicación en tiempo real, o las desviaciones con respecto al mismo.

[004] Los sistemas de comunicación, que comunican según la norma “Voice-Over-IP” (VoIP), son muy propensos a alteraciones en relación con la calidad de voz que se desea alcanzar, debido a su complejidad. La transmisión de datos entre dos aparatos de comunicación (IP-Soft-Clients, IP-Teléfonos, pasarelas, MCU, etc.) tiene lugar con el sistema de paquetes según el Protocolo de Transporte en Tiempo Real (RTP, ver RFC 3550/1). El RTP es un protocolo destinado, entre otros, a la trasmisión continua de datos audiovisuales (“streams” o flujos) a través de las redes basadas en IP. El RTP sirve además para transportar, a través de redes, flujos de datos multimedia, tales como, por ejemplo, audio, vídeo, texto, etc., y asimismo informaciones de señalización, es decir, codificar los datos, empaquetarlos y enviarlos de forma isócrona. La función de RTP se basa principalmente en la transferencia de datos más sensibles en tiempo real. Un paquete de datos RTP consiste principalmente en una cabecera con un número de versión y de secuencia del formato de datos (informaciones para el códec utilizado), el ID de remitente (SSRC), una marca de tiempo RTP, así como la parte de datos útiles.

[005] El RTP es un protocolo especialmente desarrollado para el caso de utilización de comunicación en tiempo real. El RTP facilita a los paquetes a transmitir en tiempo real un número de secuencia continuado para poder reconocer su sucesión adecuada, así como su carácter completo por parte del receptor. Los paquetes de datos en tiempo real contienen también una marca de tiempo RTP del lado del remitente para determinar el momento de tiempo en el que se generaron los bloques individuales de audio y de vídeo. Para el análisis del comportamiento temporal en el lugar de medición/lugar de recepción, no son, no obstante, adecuados por falta de suficiente exactitud y por el hecho de que solamente representan la situación en el momento de tiempo de la generación de los datos y no pueden tener en cuenta ni las influencias del lado del remitente, después de abandonar el apilamiento del RTP hasta el envío con intermedio de la red-interfaz, ni las influencias de la transferencia con intermedio de la red de transferencia de datos.

[006] Las alteraciones o fallos del sistema de comunicación se pueden producir en el aparato que envía la comunicación o en la red de transferencia de comunicación que transfiere el paquete de datos en tiempo real. Las causas para las alteraciones pueden ser, entre otras: el apilamiento RTP (RTP-Stack) en el aparato de comunicación que efectúa el envío, el sistema operativo del aparato de comunicación que efectúa el envío, la configuración del aparato de comunicación que efectúa el envío, la anchura de banda de la red de transferencia de datos que efectúa la transferencia del flujo de datos en tiempo real, el Buffer en los componentes de red activos de la red de transmisión de datos que efectúa la transmisión del flujo de datos en tiempo real, etc. En este caso, la superposición de varios de los fallos mencionados puede ser causa de una alteración. Los documentos “Measurement of Characteristics of Voice over IP in a Wireless LAN Environment” de Jeffrey Feigin y Kareh Pahlavan, así como US 2003/0128692, dan a conocer diferentes procedimientos para el análisis de fallos de un flujo de datos en tiempo real.

[007] El proceso de búsqueda de fallos, así como la supresión de los fallos, se muestra en la práctica muy costoso por el tiempo y los propios costes necesarios. En algunos casos, no es posible hallar el fallo, lo que puede producir, como última consecuencia, la incapacidad de utilización del sistema de comunicación.

[008] Los análisis de fallos utilizados actualmente se refieren habitualmente a la evaluación de los informes RTCP transferidos, por ejemplo, a intervalos de 5 segundos (Protocolo de Control de Transporte en Tiempo Real; ver también RFC 3550). Los informes son generados con intermedio del aparato de comunicación receptor y enviados como realimentación al aparato de comunicación remitente, lo que representa la agregación de datos de hasta 500 paquetes en tiempo real. Mediante esta reunión y evaluación de los parámetros transmitidos en los informes RTCP, que están condicionados por el procedimiento en la totalidad del periodo de 5 segundos considerado, los parámetros se desvían considerablemente de manera sensible de las circunstancias reales (por ejemplo, transcurso temporal real/variancia real del proceso temporal) en la red de transferencia de comunicaciones, o bien facilitan una imagen falseada. El análisis de fallos del flujo de datos en tiempo real en la red de datos es solamente posible de forma poco satisfactoria.

imagen1

[009] Por lo tanto, es un objetivo de la presente invención dar a conocer un procedimiento para el análisis de fallos de un flujo de datos, en especial, un flujo de datos en tiempo real, en una red de datos, que posibilite la determinación fiable de un fallo (tal como, por ejemplo, el tipo de fallo, lugar en el que se ha producido el fallo). Además, es un objetivo de la presente invención dar a conocer un sistema de comunicación, así como un ordenador de control, que posibilite el análisis de fallos del flujo de datos en una red de datos.

[0010] Estos objetivos se consiguen mediante el objeto de las reivindicaciones independientes. Otras formas de realización son el objeto de las reivindicaciones dependientes.

[0011] En el procedimiento objeto de la invención para el análisis de fallos de un flujo de datos isócrono en tiempo real en una red de datos, para conseguir estos objetivos se genera para cada paquete de datos transferidos entre dos aparatos de comunicación de la red de comunicaciones un sello o marca de tiempo en una unidad de control, que caracteriza el punto de tiempo de la entrada de un correspondiente paquete de datos en la unidad de control (marca de tiempo de medición). Se construirá una distribución de frecuencias (histograma) de la diferencia de tiempo de la marca de tiempo una después de otra en los paquetes de datos que entran, en la unidad de control del flujo de datos isócrono, que se determinará a base de las múltiples marcas de tiempo del paquete de datos del flujo de datos. Finalmente, se llevará a cabo un reconocimiento de patrón mediante la comprobación de la distribución de frecuencias para determinar el punto y/o la causa de un fallo en la transmisión del flujo de datos en la red de datos. En este caso, se identificarán los patrones por comparación con un estado ideal del flujo de datos en tiempo real isócrono.

[0012] Una unidad para análisis de fallos, de acuerdo con la invención, de un flujo de datos en tiempo real isócrono entre dos aparatos de comunicación de una red de datos, está constituida de forma tal que determina, a base de cada paquete de datos transmitido entre dos aparatos de comunicación de la red de datos, una marca de tiempo que caracteriza el punto de tiempo de la entrada de un correspondiente paquete de datos en la unidad de control (marca de tiempo de medición). La unidad de control está constituida además para constituir una distribución de frecuencias de la diferencia de la marca de tiempo de los paquetes de datos que entran, uno después de otro, en la unidad de control del flujo de datos en tiempo real isócrono, que es determinado a base de la multiplicidad de marcas de tiempo de los paquetes de datos del flujo de datos. Además, la unidad de control está constituida de manera tal que pueda realizar el reconocimiento de patrón de la distribución de frecuencias para determinar el lugar y/o la causa de un fallo en la transmisión del flujo de datos en la red de datos. En este caso, se reconoce el patrón por comparación con un estado ideal del flujo de datos en tiempo real isócrono.

[0013] Los objetivos propuestos se consiguen además mediante un producto de programa de ordenador que puede ser cargado de forma directa en la memoria interna de un ordenador digital y que comprende secciones de código de software con las que se llevan a cabo las etapas del procedimiento de la invención cuando el producto es utilizado en un ordenador.

[0014] El producto de programa de ordenador que está almacenado en un medio apropiado para el ordenador comprende medios de programa legibles por el ordenador que provocan que un ordenador lleve a cabo el procedimiento de análisis de fallos, según la invención.

[0015] Al contrario de los procedimientos de análisis de fallos conocidos en la técnica, la invención no se refiere a una reunión de múltiples datos contenidos en paquetes de datos, sino en la evaluación de la diferencia entre sí de los paquetes de datos que entran en la unidad de control de flujo de datos en tiempo real isócrono, que es evaluado mediante la consideración de la marca de tiempo de uno de cada uno de los paquetes de datos del flujo de datos. La representación de, como mínimo, un parámetro de transmisión de datos en una distribución de frecuencias posibilita la identificación de patrones característicos en el histograma. De esta manera, se posibilita un análisis de fallos muy exacto, que posibilita tanto la determinación del lugar del origen del fallo, por ejemplo, el aparato de comunicación emisor o la red de transmisión de datos que efectúa la transmisión del flujo de datos, como también la causa del fallo en la transmisión del flujo de datos.

[0016] Como marca de tiempo se toman en consideración principalmente la marca de tiempo RTP de un paquete de datos RTP (de acuerdo con RFC 3550/1), así como, según la invención, una marca de tiempo de medición que es constituida por el ordenador de control a la entrada de un paquete de datos en tiempo real. Este último caracteriza de esta manera (al contrario de la marca de datos RTP que caracteriza el estado de la generación del paquete de datos) el transcurso temporal en el lugar de la medición. En el lugar de la medición, un paquete de datos en tiempo real es sometido después de la generación en un apilamiento RTP a la influencia del sistema operativo del emisor, la red de transferencia de datos, etc. El reconocimiento de patrón, según la invención, posibilita con utilización de una marca de tiempo de medición una determinación de fallo teniendo en cuenta los componentes de la red de transmisión de datos.

[0017] La marca de tiempo RTP (RTP-Timestamp) sirve además para marcar el punto de tiempo de la generación/codificación de la carga útil del paquete de datos. El valor de la marca de tiempo puede depender del tipo de la carga útil. El valor de inicio puede ser escogido, por ejemplo, por un generador al azar.

[0018] El número de secuencia de un paquete de datos posibilita al aparato de comunicación receptor el comprobar la pérdida de unidades de datos, o bien generar nuevamente el orden apropiado de las unidades de datos en caso de que los paquetes de datos hayan llegado en una sucesión errónea. El valor inicial del número de secuencia será escogido, por ejemplo al azar, para dificultar una decodificación no permitida.

imagen2

[0019] El concepto utilizado en la presente solicitud de patente del aparato de comunicación debe ser comprendido de manera general. Como aparato de comunicación se puede comprender aparatos de envío de comunicaciones tales como, por ejemplo, teléfonos IP, ordenadores preparados para VoIP (por ejemplo, “Soft-Clients”), pasarelas, dispositivos de conferencias (MCU), etc.

[0020] La identificación del patrón de la distribución de frecuencias puede tener lugar con utilización de métodos conocidos. Esto puede tener lugar, por ejemplo, mediante una comparación con distribuciones de frecuencia temporales dispuestas en una memoria del correspondiente parámetro de transmisión de datos, de manera que se pueda detectar, por ejemplo, una desviación con respecto a uno o varios valores umbral predeterminados. La comparación puede tener lugar, por ejemplo, mediante la conversión de los valores de frecuencia del histograma del parámetro de transmisión de datos correspondiente en un vector de datos que puede ser manipulado adicionalmente mediante métodos matemáticos.

[0021] En el procedimiento objeto de la invención, se considerará como parámetro de transferencia de datos la diferencia de tiempo entre la marca de tiempo de medición de dos paquetes de datos sucesivos en una dirección de transferencia de datos (Interarrival Time, IAT). El parámetro de transferencia de datos puede ser influido en casos individuales también por otros parámetros de transferencia de datos. De este modo, el IAT será influenciado tanto por la pérdida del paquete de datos como también por la varianza del tiempo de latencia de los paquetes de datos. Esto significa que tanto los histogramas IAT como también los diagramas de tiempo IAT se caracterizan siempre por la superposición de la varianza del tiempo de latencia de los paquetes de datos y de la pérdida del paquete de datos. La diferencia de tiempo entre la marca de tiempo de medición de dos paquetes de datos en tiempo real sucesivos en una dirección de transferencia de datos proporciona, por lo tanto, de manera especialmente favorable una impresión resumida de la calidad de la conexión entre los dos aparatos de comunicación. En este caso, se utilizará entre otros factores el hecho de que los aparatos de comunicación de la red de datos presentan un apilamiento RTP (RTP-Stack) y, por lo tanto, están en situación de transmitir los paquetes de datos RTP en una trama casi isócrona. Por el contrario, los componentes de la red de transmisión de datos no contienen ningún apilamiento RTP. Si el fallo de la transmisión del flujo de datos ha sido provocado por la red de transmisión de datos, ésta no se encuentra ya en situación de reconstruir la separación temporal inicial de los paquetes de datos en tiempo real. Este reconocimiento se utilizará, de acuerdo con una disposición ventajosa de la invención, para la determinación de la causa del fallo.

[0022] En otra forma de realización, el flujo de datos contiene datos de audio, en especial, “Voice-over-IP” y/o “Comfort Noise” (RFC 3389, G.729, etc.). El “Comfort Noise”, o ruidos de confort, son ruidos generados artificialmente que son utilizados para el llenado de periodos de reposo en transmisiones móviles, así como en telefonía IP (VoIP), conjuntamente con una tecnología que reduce simultáneamente todos los ruidos por debajo de un determinado nivel de intensidad. Genera la impresión de una conexión adicional sin exigir para la transmisión del ruido la necesaria amplitud de banda en la red de transmisión de datos.

[0023] En otra realización adicional, en el procedimiento objeto de la invención tiene lugar la evaluación de la distribución de frecuencias con la utilización de un ordenador de control que determina y manipula adicionalmente los paquetes de datos transmitidos entre los aparatos de comunicación. El ordenador de control para la determinación de los paquetes de datos puede estar dispuesto en el lugar deseado entre los aparatos de comunicación. Mediante la elección del lugar en el que el ordenador de control determina los paquetes de datos transmitidos entre los aparatos de comunicación, se puede facilitar la localización de un eventual fallo que ha aparecido. En este caso, puede ser especialmente aconsejable prever en un sistema de comunicación, según la invención, múltiples ordenadores de control.

[0024] Una disposición alternativa o adicional prevé comprobar la imagen técnica de datos de la distribución de frecuencias como patrón para el reconocimiento de fallos específicos en los aparatos de comunicación y en la red de transmisión de datos que conectan los aparatos de comunicación. Como fallos específicos se pueden identificar, por ejemplo, la anchura de banda o una memoria Buffer de componentes de red activos de la red de transferencia de datos. No obstante, es posible también, de forma correspondiente, identificar fallos de configuración del aparato de comunicación emisor, la influencia del sistema operativo y también fallos del apilamiento RTP.

[0025] Otra realización prevé que las imágenes técnicas de datos de los patrones de histogramas sean utilizados para la diferenciación de un determinado estado normal (por ejemplo, operación regular VoIP, supresión de pausas de voz según uno de los procedimientos normalizados, utilización de aparatos de comunicación especiales, por ejemplo, Unidades de Respuesta de Voz) con respecto a un estado de fallo y que, en caso de existencia de fallos, éstos sean asociables al aparato de envío de comunicación o a la red de transmisión de datos. De esta manera se facilita la supresión de un fallo.

[0026] En otra forma de realización, en la determinación de un fallo en el aparato de comunicación de envío se puede determinar, en base al patrón de la distribución de frecuencias, una causa concreta del fallo. Como causa del fallo entran en consideración, en especial, el sistema operativo del aparato de comunicación, la configuración del aparato de comunicación, su apilamiento RTP o su implementación.

imagen3

[0027] En otra forma de realización, en la determinación de un fallo en la red de transmisión de datos se puede determinar, en base al patrón de la distribución de frecuencias, una causa concreta del fallo. Como causa del fallo se toman en consideración, en especial, la falta de amplitud de banda o el almacenamiento intermedio temporal (efecto Buffer) en componentes activos de la red de transferencia de datos.

[0028] Para la determinación de un fallo en la red de datos es suficiente, según una realización preferente adicional, que se proceda al análisis de fallos del flujo de datos del flujo de datos entre los dos aparatos de comunicación en una dirección, o en ambas direcciones, en uno o varios puntos de medición.

[0029] La invención se explicará a continuación en base a las figuras a título de ejemplo. En ellas se muestra:

Figura 1, constitución esquemática de un sistema de comunicación, según la invención,

Figuras 2-4, dos diagramas IAT, así como un histograma IAT de una transmisión ideal VoIP,

Figuras 5-7, dos diagramas IAT, así como un histograma IAT de una transmisión VoIP real,

Figuras 8-10, un diagrama IAT, así como dos histogramas IAT de una transmisión real VoIP sin pérdida de paquete de datos, tratándose en un aparato de comunicación una de las llamadas unidades de respuesta de voz (“Voice Response Unit”) que muestra un comportamiento alterado,

Figuras 11-13, dos diagramas IAT, así como un histograma IAT de una transmisión VoIP real sin pérdida de paquetes de datos, pero con reducción de pausa de voz,

Figuras 14, 15, un diagrama IAT, así como un histograma IAT de una transmisión real VoIP (casi ideal) sin pérdida de paquete de datos y con muy poca variancia del tiempo de latencia de paquetes de datos (“Jitter”), pero, no obstante, con un fallo de configuración en uno de los aparatos de comunicación,

Figuras 16-18, dos diagramas IAT, así como un histograma IAT de una transmisión real VoIP sin pérdida de paquetes de datos y con variancia sensiblemente acentuada del tiempo de latencia de los paquetes de datos (Jitter),

Figuras 19,20, un diagrama IAT, así como un histograma IAT de una transmisión real VoIP sin pérdida de paquetes de datos y con Jitter cíclico puntual notablemente acentuado de un aparato de comunicación,

Figuras 21,22 un diagrama IAT, así como un histograma IAT de una transmisión real VoIP sin pérdida de paquetes de datos y con IAT notablemente aumentado, y

Figuras 23-25, un diagrama IAT, un histograma IAT, así como un diagrama de pérdida de paquete de datos de una transmisión real VoIP, en la que aparecen elevados valores de IAT frecuentemente condicionados por pérdida de paquete de datos.

[0030] En la figura 1 se ha mostrado esquemáticamente la disposición de un sistema de comunicación (100),según la invención. Éste comprende solamente, a título de ejemplo, dos aparatos de comunicación (10, 12) que pueden comunicar entre sí a través de una red de transmisión de datos (14). La red de transmisión de datos (14) puede presentar una serie de componentes de red con intermedio de los cuales se puede conseguir conexión entre los aparatos de comunicación (10, 12).

[0031] Los aparatos de comunicación (10, 12), tal como se ha mostrado a título de ejemplo en la figura 1, pueden presentar aparatos de comunicación que están constituidos para la comunicación según una norma de Voiceover-IP (Voz por IP). Los aparatos de comunicación (10, 12) presentan para ello un apilamiento RTP, de manera que se puede constituir un flujo de datos que fluye entre los aparatos de comunicación (10, 12) desde una serie de paquetes de datos RTP.

[0032] En base al apilamiento RTP, los aparatos de comunicación (10, 12) están en situación de transmitir los paquetes de datos RTP en una trama casi isócrona. Los componentes de red de la red de transmisión de datos (15), que no se han mostrado de manera detallada en la figura 1, no presentan, por el contrario, ningún apilamiento RTP. En caso de aparición de una alteración de la transmisión de uno o varios paquetes de datos RTP, la red de transmisión de datos (14), es decir, los componentes de red que participan en la transmisión, no se encuentran en la situación de reconstruir la separación temporal inicial de los aparatos de comunicación emisores (10) ó (12) del paquete de datos RTP. Este reconocimiento es de ayuda para el análisis de la situación del fallo mediante un ordenador de control (16), que en la figura 1 se ha mostrado a título de ejemplo en la red de transmisión de datos (14).

[0033] El ordenador de control (16) puede estar dispuesto en el lugar deseado de una conducción de conexión entre los aparatos de comunicación (10, 12). Es especialmente ventajoso que se prevea una serie de ordenadores de control, puesto que de este modo permite una localización más precisa de un fallo en partes significativas de la red detransmisión de datos (14) (por ejemplo, Red de Área Ancha (Wide Área Network), Enlace ascendente (Uplink), Conexión principal (Backbone), Enlace descendente (Downlink), Extremo a extremo (Ende-zu-Ende)). En principio es suficiente cuando el flujo de datos es controlado en una dirección de comunicación entre los aparatos de comunicación (10, 12) mediante el ordenador de control (16), de manera que el procedimiento, según la invención, puede ser utilizado solamente en esta dirección.

imagen4

[0034] De modo representativo, el ordenador de control puede ser considerado como conectado en paralelo con uno de los aparatos de comunicación (10, 12) que determina tanto el paquete de datos enviado por un aparato de comunicación con intermedio de la red de transmisión de datos como también el paquete de datos recibido, es decir, enviado por otro aparato de comunicación. En particular, el ordenador de control (16) determina de cada paquete de datos en tiempo real la marca de tiempo de envío (RTP-Timestamp), el número de secuencia RTP y facilita una marca de tiempo propia que caracteriza el momento de tiempo de la entrada en el ordenador de control (marca de tiempo de medición). En base a estos tres parámetros, se pondrá al ordenador de control (16) en situación de determinar el comportamiento del parámetro en el lado del emisor, así como la influencia de la transmisión de datos a la conexión de datos entre los aparatos de comunicación (10, 12).

[0035] En ese caso, es de especial interés la diferencia de tiempo entre dos paquetes de datos sucesivos en una dirección de transferencia de datos, el llamado “Interarrival Time” (IAT) (Tiempo intermedio de llegada). Puesto que el IAT depende tanto de la pérdida de un paquete de datos que se puede determinar en base al número de secuencia como también por la varianza del tiempo de latencia de paquetes de datos (el llamado Jitter), que se puede determinar a base de la marca de tiempo, el parámetro de transmisión de datos IAT facilita ya una eficaz información sobre la calidad de voz de una conexión de datos entre los aparatos de comunicación (10, 12). En este caso, es de especial significación el IAT de la marca de tiempo de medición, puesto que representa el comportamiento temporal en el lugar de la medición, es decir, bajo la influencia de una red de transmisión de datos.

[0036] A partir de los parámetros determinados por el ordenador de control (16), se constituye una distribución de frecuencias de los valores individuales de los parámetros de transferencia de datos. En la siguiente descripción, bajo el concepto de diagrama se comprende el transcurso temporal y bajo el concepto de histograma se comprende la distribución de frecuencias de los parámetros de transmisión de datos de los paquetes de datos en tiempo real. En base al histograma de uno o varios parámetros de transmisión de datos, es posible diferenciar la situación normal de una conexión de datos en tiempo real (en especial, una conexión de voz) con respecto a situaciones de fallo. Con este objeto, los datos que se encuentran en el histograma son sometidos a un reconocimiento de patrón. Esto se puede llevar a cabo con utilización de métodos de evaluación conocidos mediante el propio ordenador de control o mediante otro ordenador de la red de datos (100).

[0037] El procedimiento para el análisis de fallos de un flujo de datos intercambiado entre los aparatos de comunicación (10, 12) se describirá a continuación en base a varios ejemplos, de manera que se tomará en consideración la diferencia de tiempo entre dos paquetes de datos sucesivos en una dirección de transmisión de datos en el lugar de medición (IAT de la marca de tiempo de medición) en los histogramas.

[0038] La figura 2 muestra el diagrama IAT de una transmisión ideal VoIP. Todos los paquetes de datos RTP intercambiados entre los aparatos de comunicación (10, 12) serán isócronos, es decir, transmitidos en el mismo intervalo de tiempo. El intervalo de tiempo que representa la diferencia de tiempo entre dos paquetes de datos en tiempo real sucesivos en una dirección de transmisión de datos asciende para un aparato de comunicación que a continuación, se designará como participante (A) y para un aparato de comunicación designado como participante (B) igualmente a 30 ms. Los puntos representativos de los paquetes de datos RTP presentan, por lo tanto, el mismo IAT que se ha llevado sobre el eje y. Mediante la escala escogida se muestran en la figura 2 como líneas horizontales continuas. La figura 3 muestra la misma transmisión ideal VoIP en la que, no obstante, se ha escogido una escala mayor sobre el eje de los tiempos (eje x). De esta manera, son visibles, a parte de los valores IAT de los paquetes RTP individuales, también las correspondientes marcas de tiempo de medición (eje x).

[0039] La figura 4 muestra el histograma correspondiente, de manera que la distribución de frecuencias de los valores individuales del IAT corresponde a la transmisión ideal VoIP. Dado que todos los paquetes de datos RTP serán transmitidos entre los participantes (A, B) de forma isócrona, también son idénticos todos los intervalos de tiempo entre dos paquetes de datos RTP sucesivos (IAT). De esta manera, se produce para el IAT de 30 ms reconocible en los diagramas de las figuras 2 y 3 para ambos aparatos de comunicación una línea vertical con un valor de frecuencia de 100%.

[0040] Este estado ideal mostrado en las figuras 2-4 se conseguirá en la práctica, como máximo, de forma aproximada. Actúa como referencia para la evaluación de situaciones de fallo concretas que se explicarán de manera más detallada en las figuras siguientes. Si el histograma IAT presenta solamente una línea vertical con una altura d (casi) 100% de la frecuencia, se tratará de una transmisión VoIP con una calidad de voz VoIP (casi) ideal, que no muestra ningún Jitter ni pérdida alguna de paquetes de datos.

[0041] La figura 5 muestra el diagrama IAT de una transmisión real VoIP (sin pérdida de paquete de datos ni Jitter crítico) entre dos aparatos de comunicación con capacidad IP, que están acoplados mediante un conmutador en la red de transmisión de datos. La diferenciación de ambos participantes técnicamente similares (A, B) resalta la influencia de un conmutador individual en la red de transmisión de datos. El participante (A) (en la figura superior) presenta, según la transmisión con intermedio de un conmutador, una elevada variancia del IAT que en el caso del participante (B) (en la figura inferior). Esto significa que en el participante (A) se produce un Jitter claramente identificable como resultado de la transmisión de datos. Para el participante (B) se puede observar por el contrario el comportamiento normal (Jitter) del aparato de comunicación con capacidad IP. La aparición de un patrón simétrico viene producida por la escala de tiempos del eje x. La figura 6 muestra la misma transmisión real VoIP, habiéndose escogido, no obstante, una escala mayor del tiempo sobre el eje de las x. Se pueden observar claramente los valores individuales IAT de los paquetes de datos RTP, de manera que en el participante (A) es visible una desviación con respecto al valor ideal del IAT de 30 ms.

imagen5

[0042] La figura 7 muestra el histograma IAT, es decir, la distribución de frecuencia de los valores individuales de IAT de la transmisión VoIP en base a las figuras 5 y 6. Para el participante (A), es reconocible sin problema alguno la variancia ya reconocible en el diagrama IAT (Jitter) en la correspondiente distribución de frecuencia. El histograma posibilita, en comparación con la representación temporal de los valores IAT, una representación más compacta para llegar a un resultado de análisis similar. Independiente de la duración de una transmisión VoIP se puede llevar a cabo, teniendo en cuenta la totalidad de valores IAT de todos los paquetes de datos, un análisis en un gráfico único de dimensiones casi iguales. El patrón visible en la figura 7 caracteriza el estado normal sin pérdida de paquete de datos y sin Jitter crítico. El desplazamiento lateral de las distribuciones de frecuencias de los participantes (A) y (B) se debe atribuir a que ambos aparatos de comunicación con capacidad IP (también designados como puntos finales) transmiten con un intervalo distinto (30 ms y 40 ms). Este comportamiento se puede identificar también sin problema alguno en los diagramas IAT de las figuras 5 y 6.

[0043] Un estado normal de una transmisión real VoIP se puede reconocer sin problema alguno en un histograma IAT, de manera que éste existe cuando el histograma IAT presenta un máximo notablemente acentuado (estado nominal o teórico del intervalo del paquete en el envío) sin que la variancia de los valores de frecuencia (Jitter = ensanchamiento lateral de la distribución de frecuencia en comparación con el estado actual) sea demasiado elevada y sin que aparezcan otros valores fuera de la distribución de frecuencias. El máximo debe aparecer, en este caso, en el valor del intervalo del envío de los paquetes RTP de los aparatos de comunicación correspondientes.

[0044] La figura 8 muestra el diagrama IAT de una transmisión VoIP real sin pérdida de paquetes de datos. En la misma, se tiene un caso especial, en el que uno de los aparatos de comunicación está constituido con una llamada Unidad de Respuesta de Voz (Voice Response Unit) (ordenador de voz) con supresión de silencio (supresión de intervalo de voz), de acuerdo con RFC 3550. En el diagrama IAT de la figura 8 se pueden reconocer la transmisión discontinua y la fuerte variancia temporal (Jitter) durante la transmisión en el aparato de comunicación (A), así como en los paquetes individuales de ambos aparatos de comunicación (A, B) con IAT elevado en el borde superior o bien en el borde inferior del gráfico. La transmisión discontinua resulta de una supresión de pausa de voz. La discontinuidad de la transmisión con un paquete de datos RTP individual resultante que presenta un IAT elevado y un bit de marcado definido, caracterizado por una continuidad creciente sin intersticio de los números de secuencia RTP (es decir, sin pérdida de paquetes de datos) una supresión de pausa de voz, según RFC 3550. La variancia temporal de igual altura (Jitter) de los paquetes de datos en tiempo real del aparato de comunicación (A) durante la transmisión resulta de la capacidad final del ordenador, a base del cual se ha realizado la máquina de voz de la Unidad de Respuesta de Voz (Voice-Response-Unit). La variancia temporal igualmente elevada (Jitter), en conexión con las discontinuidades (supresión de pausas de voz) permite identificar debidamente la Unidad de Respuesta de Voz. Esta determinación quedará reforzada por el número reducido de paquetes de datos RTP del participante (B) con IAT más elevado, que contienen tonos DTMF (señalización) en los paquetes de datos RTP para el control de la Unidad de Respuesta de Voz. La duración de las pausas de voz corresponde al tiempo de reacción de un usuario del aparato de comunicación en la emisión DTMF.

[0045] La figura 9 muestra el correspondiente histograma IAT. Éste presenta una gran variancia sin máximo significativo para el participante (A). La figura 10 muestra el mismo histograma IAT con una escala modificada. En este caso, son visibles también los valores extremos IAT para el participante (A) (condicionado por las pausas de voz caracterizadas por un bit marcador) y para el participante (B) (condicionado por las emisiones DTMF). Para ambos participante no se trata de valores críticos, sino de una consecuencia deseada de una función estándar de un sistema de comunicación VoIP.

[0046] En las figuras 8 a 10, se ha mostrado un estado normal, que no muestra ni pérdida de paquetes de datos ni Jitter crítico. La transmisión discontinua (intervalos en el transcurso temporal) no se generan por una pérdida de paquetes de datos, sino por el funcionamiento regular de una Unidad de Respuesta de Voz (espera de una emisión). La variancia temporal igualmente elevada (Jitter) de la señal de participante (A) no se debe designar, por lo tanto, como crítica, puesto que no se trata de un punto final regular VoIP, sino de un ordenador de voz con comportamiento final.

[0047] Por lo tanto, si el histograma IAT presenta elevados valores IAT sin que exista pérdida de paquetes de datos se trata, para estos paquetes de datos RTP, de un Jitter extremo. Si estos paquetes de datos con Jitter presentan un bit marcador determinado, no se trata de Jitter, sino de pausas de voz. Si en un diagrama IAT al final de las pausas de voz se pueden revelar en el lado opuesto emisiones DTMF, se trata del diálogo regular con una Unidad de Respuesta de Voz.

[0048] En las figuras 11 a 13, se ha mostrado el estado normal de una transmisión real VoIP en la que existe una supresión de pausa de voz (Silence-Suppression (silencio-supresión)) con Comfort-Noise (RFC 3389). La figura 11 muestra el diagrama IAT de la transmisión real VoIP sin pérdida de paquetes de datos ni Jitter crítico, no obstante, con supresión de pausas de voz activada. En la supresión de pausas de voz, según RFC 3389, se trata de un procedimiento entre varios procedimientos alternativos para que, en caso de pausas de voz (el micrófono del emisor no facilita ninguna señal) se ahorre capacidad de transmisión (anchura de banda) en las redes de transmisión de datos. Es ventajoso en el diagrama IAT que los paquetes de datos RTP no adopten valores variables, sino que, de manera similar a las capas de electrones en un modelo de átomo, solamente presenten algunos valores individuales de IAT. Los paquetes de datos RTP se forman según líneas que discurren horizontales, paralelas al estado ideal que pueden recibir la superposición adicional de un Jitter (en este ejemplo, casi no apreciable). Estos paquetes de datos RTP, que se muestran sobre líneas paralelas, no transportan en su sección de carga útil datos de voz, sino ruidos (Comfort Noise). Presentan, por lo tanto, también un correspondiente tipo de carga útil RTP (Payloadtype 13), que define este procedimiento como supresión de pausa de voz. Un procedimiento similar, pero no obstante, sin tipo de carga útil RTP propio, es definido también para el códec G.729.

imagen6

[0049] La figura 12 muestra la misma transmisión real VoIP, no obstante, con representación de tiempo modificada sobre el eje de las x. La disposición de los paquetes de datos RTP individuales sobre líneas que discurren paralelas al estado ideal, es visible en este caso.

[0050] La figura 13 muestra el correspondiente histograma IAT. De manera correspondiente, tal como en los diagramas de tiempo, según las figuras 11 y 12, constituyen en este caso líneas de frecuencia correspondientes para múltiplos enteros del estado ideal (intervalo de los paquetes RTP en el envío sin supresión de pausas de voz).

[0051] Se trata, en este caso, de modo correspondiente, de un estado normal que no presenta ni pérdida de paquetes ni Jitter crítico. La distribución casi arbitraria de los paquetes de datos RTP con el tipo de carga útil (13) en valores IAT discretos caracteriza debidamente una supresión de pausas de voz.

[0052] Por lo tanto, si un histograma IAT presenta valores discretos con gran distribución de múltiplos enteros sin que exista pérdida de paquetes de datos (lo cual se puede comprobar en base al número de secuencia), se trata de una supresión de pausas de voz con Comfort Noise. Los correspondientes paquetes RTP presentan simultáneamente o bien un tipo de carga útil especial con el número (13) (RFC 3389) o longitudes especiales de la carga útil RTP (G.729). Estas informaciones pueden ser transmitidas de manera correspondiente a través del ordenador de control.

[0053] En las figuras 14 y 15, se ha mostrado un estado normal de una transmisión VoIP real con un fallo de configuración de uno de ambos aparatos de comunicación. La figura 14 muestra el diagrama IAT de una transmisión VoIP real (casi ideal), sin pérdida de paquetes de datos y muy poco Jitter. Mientras que la calidad de voz VoIP para ambos aparatos de comunicación (A, B) se puede evaluar teniendo en cuenta la transmisión VoIP como extraordinaria, se produce para el aparato de comunicación (B) un valor de IAT muy elevado de 90 ms. El IAT será configurado en el lado emisor y se encuentra sensiblemente por encima del valor normalmente utilizado de, por ejemplo, 20 ms, lo que se puede atribuir a un fallo de comunicación. Para garantizar una recepción libre de alteraciones, la magnitud del Buffer receptor debe ser escogido de manera correspondiente en los aparatos de comunicación receptores (>90 ms). Puesto que la magnitud del Buffer receptor resulta siempre aditiva en el presupuesto general del retraso de tiempo entre los aparatos de comunicación (retraso extremo a extremo (End-to-End)) se operará incluso con 90 ms cerca del valor límite permisible. No obstante, y de manera habitual, los tampones de receptor están organizados para la compensación de desviaciones mayores (por ejemplo, 4 paquetes de datos = 4*90 ms = 360 ms). En este caso, no se puede llevar a cabo el diálogo telefónico entre los aparatos de comunicación.

[0054] La figura 15 muestra el correspondiente histograma IAT. El histograma para el aparato de comunicación

(B) muestra el patrón horizontal desplazado sobre el valor 90 ms de una transmisión real.

[0055] En las figuras 14 y 15 se ha mostrado, por lo tanto, un estado normal que no presenta ni pérdida de paquetes de datos ni Jitter crítico. Se trata, por lo tanto, de una transmisión VoIP cualitativamente de alto valor, en la que existe un fallo de configuración en el lado del aparato de comunicación emisor, el cual conduce a problemas en la calidad de voz (comprensión).

[0056] Si un histograma IAT presenta en un sistema configurado, por lo demás de manera similar, (por ejemplo 30 ms) un patrón que por lo demás no está alterado, desplazado sobre el eje de las x de modo completo en la dirección de valores más elevados (>60 ms), existe un fallo de configuración en el lado del aparato de comunicación emisor.

[0057] Las figuras 16 a 18 muestran una transmisión VoIP real en la que existe Jitter. La figura 16 muestra el diagrama IAT de la transmisión VoIP sin pérdida de paquetes de datos y con un Jitter notablemente acentuado para el aparato de comunicación (A). El estado normal IAT de 30 ms puede ser solamente supuesto, variando el IAT de los paquetes de datos RTP de modo arbitrario alrededor del estado normal. Este patrón caracteriza un tramo de transmisión de datos VoIP inestable. La figura 17 muestra la misma transmisión VoIP real de manera que se ha escogido una escala de tiempo mayor del eje x. La fuerte variancia de los paquetes de datos RTP individuales para el aparato de comunicación (A) es claramente reconocible en este caso. La figura 18 muestra el histograma IAT correspondiente. La fuerte variancia para el participante (A) puede ser observada sin problema alguno en el histograma. El máximo significativo (estado normal) para 30 ms se puede reconocer debidamente, no obstante, los valores varían muy fuertemente alrededor del valor indicado.

[0058] En las figuras 16 a 18 se ha mostrado, por lo tanto, un fallo por el que se trata de Jitter sin pérdida de paquetes de datos. Esta situación se puede reconocer de un histograma IAT, en el que existe un máximo significativo como característica del estado normal, y en el que simultáneamente el patrón muestra una elevada variancia (Jitter), de manera que no obstante, no se superan valores máximos críticos. Estos indicarían, por otra parte, una posible pérdida de paquetes de datos o en caso preciso una supresión de pausas de voz. El patrón se puede asociar, por lo tanto, debidamente a Jitter.

imagen7

[0059] Las figuras 19 y 20 muestran una transmisión real VoIP en la que existe una alteración en forma de Jitter cíclico (Cyclic Jitter). La figura 19 muestra el diagrama IAT de la transmisión real VoIP sin pérdida de paquetes de datos y con Jitter sensiblemente marcado, puntual, para el aparato de comunicación (A). En comparación con el Jitter que aparece de forma continuada, según el ejemplo anterior de las figuras 16 a 18, se aprecia claramente en este caso desviaciones cíclicas (con igual intervalo de tiempo, en este caso, aproximadamente cada 16 segundos) de paquetes de datos individuales con respecto al estado normal. Este ciclo es siempre constante (en este caso unos 16 segundos), no obstante, su valor puede variar fuertemente de manera que la variación puede ascender entre algunos milisegundos y algunos segundos. En especial, en clientes que se basan en software (por ejemplo, clientes VoIP que operan con ordenadores) este efecto puede ser fuertemente marcado y corresponde, por ejemplo, a la longitud de ciclo de las interrupciones del sistema operativo. Esto puede ser comprobado, por ejemplo, en una disposición del ordenador de control directamente por detrás del cliente basado en software correspondiente, es decir, antes de la trasmisión del paquete de datos mediante la red de transmisión de datos, no obstante, es también reconocible en especial en el lado del aparato de comunicación receptor de igual manera. Puesto que además no se puede ignorar que existe una componente en la red de transmisión de datos que está en condiciones de generar alteraciones cíclicas, en la aparición de alteraciones cíclicas con elevada probabilidad se puede deducir que se trata de alteraciones en el lado del aparato de comunicación del emisor. La amplitud de las alteraciones cíclicas puede ser igual que en este ejemplo casi constante

o bien dependiendo de circunstancias (entero o no entero) del ciclo de la alteración con respecto al estado normal del envío RTP, pueden debilitarse lentamente (el llamado Fading) y aparecer nuevamente. En todo caso, el comportamiento cíclico es de observar en el lado del aparato de comunicación de recepción.

[0060] La figura 20 muestra el correspondiente histograma IAT. En este histograma IAT se pueden reconocer los valores notablemente elevados del IAT, no obstante, no aparece su carácter cíclico.

[0061] En este ejemplo de realización, se trata, por lo tanto, básicamente (hasta unas pocas excepciones) de una transmisión VoIP sin alteraciones. El comportamiento cíclico-puntual del Jitter significa con elevada probabilidad que la causa no se encuentra en la red de transmisión de datos, sino en el lado del aparato de comunicación emisor. Esto puede ser producido, por ejemplo, por una interrupción (Interrupt) del sistema operativo o por otro proceso interno que se realiza de forma cíclica del emisor.

[0062] En caso de que el histograma IAT muestre valores clínicamente elevados (Jitter), que se caracterizan de manera separada con respecto al resto del patrón, se puede tratar de alteraciones cíclicas. Para ello, se debe comprobar como criterio adicional en un diagrama IAT si es reconocible un comportamiento cíclico (igual intervalo de las marcas de tiempo de medición de las alteraciones, es decir, igual intervalo sobre el eje de las x) del Jitter. Si el comportamiento cíclico se reconoce especialmente en los paquetes de datos RTP individuales, la alteración se encuentra con elevada probabilidad en el lado del emisor.

[0063] En las figuras 21 y 22 se ha mostrado una transmisión real VoIP, en la que existe una alteración de la forma que se llama un Jitter singular. La figura 21 muestra un diagrama IAT de la transmisión VoIP real sin pérdida de paquetes de datos, sin supresión de pausas de voz y con IAT sustancialmente elevado, en el que se trata, por lo tanto, de Jitter. Este Jitter aparece en una transmisión VoIP que, por lo demás, no presenta alteraciones con un IAT de 20 ms como estado normal en el aparato de comunicación (A) de forma repentina. El paquete de datos RTP que aparece en el intersticio que se genera por el Jitter (designado en la figura con a)) tiene como consecuencia un IAT correspondientemente elevado. Después del paquete de datos a) se registrarán varios paquetes de datos RTP (comparar b)) con un IAT que se acerca a cero (designado como NZ-IAT, Near Zero-IAT (IAT cerca de cero)). A causa del intervalo temporal extremadamente reducido, los paquetes de datos RTP se muestran en esta representación como un paquete. Finalmente, continúa el envío normal (comparar c)) con 20 ms. Los NZ-IAT b)) son la consecuencia de un efecto Buffer aparecido en la red de transmisión de datos, por ejemplo, a causa de una sobrecarga. Dado que la red de transmisión de datos no dispone de apilamiento RTP alguno (RTP-Stack) y, por lo tanto, no está en condiciones de reconstruir nuevamente después del efecto Buffer el IAT normal inicial de 20 ms, se enviarán lo más rápidamente posible al receptor todos los paquetes de datos RTP hasta el vaciado del Buffer. El NZ-IAT es, por lo tanto, una característica clara de efecto Buffer en los componentes de una red de transmisión de datos IAT.

[0064] La figura 22 muestra el correspondiente histograma IAT. En este caso, se observan claramente además del estado normal (comparar c) en la figura 22) y valores extremos (comparar a) en la figura 22) los NZ-IAT (comparar b) en la figura 22).

[0065] En este ejemplo de realización, se trata, por lo tanto, claramente de una alteración provocada por la red de transmisión de datos mediante un efecto Buffer de un flujo de datos RTP con envío final muy rápido del paquete de datos sin reconstrucción del IAT normal. Por lo tanto, en caso de que el histograma IAT presente valores IAT próximos a cero (NZ-IAT), ésta es una indicación clara de un efecto Buffer del paquete de datos en la red de transmisión de datos. Este caso es claramente diferenciable, de los pequeños valores IAT que de todos modos no se acercan a cero, del ejemplo de realización anterior, según las figuras 19 y 20. Para el reconocimiento de fallo se podría utilizar como criterio adicional también el diagrama IAT, el cual presenta varios paquetes NZ-IAT sucesivos.

imagen8

[0066] Las figuras 23 a 25 muestran como ejemplo de realización adicional, una transmisión real VoIP en la que existe como alteración una pérdida del paquete de datos. La figura 23 muestra el diagrama IAT de una transmisión real VoIP en la que se presentan frecuentemente elevados valores IAT. En este caso, inicialmente no se puede observar si se trata de una pérdida de un paquete de datos (pérdida de uno o varios paquetes RTP) o bien de Jitter. La figura 24 muestra el correspondiente histograma IAT. En este caso, se pueden reconocer además del patrón normal para 20 ms de manera clara otros patrones adicionales más pequeños que se encuentran distribuidos para múltiplos enteros del estado normal (40 ms, 60 ms, etc.), distribuidos en “ondas superpuestas”. Todos los patrones muestran en este caso el mismo ensanchamiento condicionado por el Jitter normal. En este caso, no obstante, se presenta la sospecha de una pérdida de paquetes de datos. La comprobación correspondiente tiene lugar en base a la evaluación de un diagrama de pérdida de paquetes de datos (figura 25) que confirma la pérdida de paquetes de datos.

[0067] En este ejemplo de realización, existe, por lo tanto, una pérdida de paquetes de datos combinada con un ligero Jitter.

[0068] Por lo tanto, si un histograma IAT presenta además de un patrón para el estado normal otras dos ondas superpuestas adicionales similares para múltiplos enteros del estado normal, se presenta la sospecha de una pérdida de paquetes de datos. La confirmación tiene lugar mediante la comparación del diagrama IAT con un diagrama de pérdida de paquetes de datos, o bien un histograma de pérdida de paquetes de datos.

[0069] El reconocimiento de patrón y, por lo tanto, el análisis de fallos, puede ser automatizado mediante la evaluación del histograma o bien mediante patrones de datos matemáticos correspondientes a dichos histogramas. Un histograma puede ser, por ejemplo, descrito en base a datos técnicos mediante un vector de datos con un número correspondiente de registros. Además, existen algoritmos para el reconocimiento de patrones y el ordenador necesario para ello.

[0070] La invención posibilita, por lo tanto, un análisis de fallos que permite determinar la causa del fallo, (por ejemplo IAT, Jitter, pérdida de paquetes de datos, etc.) como también el lugar del fallo (componentes de la red de transmisión de datos, apilamiento RTP del emisor, configuración del emisor, etc.). De esta manera, es posible clasificar fallos (por ejemplo, fallos en un aparato de comunicación, emisor o fallos en una red de transmisión de datos). El patrón de comparación necesario para el reconocimiento del patrón, relaciones y/o valores umbral y similares puede ser dispuesto previamente en el ordenador de control. El patrón de comparación y/o valores umbral pueden ser determinados, por ejemplo, de manera experimental.

imagen9

Claims

REIVINDICACIONES

1. Procedimiento para el análisis de fallos de un flujo de datos en tiempo real, isócrono, en una red de datos (100) mediante una unidad de control (16) en la red de datos (100), que comprende las siguientes fases, que son realizadas por la unidad de control (16):

recepción de paquetes de datos del flujo de datos en tiempo real isócrono,

generación de una marca de tiempo para cada paquete de datos transmitido entre dos aparatos de comunicación (10, 12) de la red de datos (100), de manera que las marcas de tiempo caracterizan el punto de tiempo de la llegada de un correspondiente paquete de datos a la unidad de control (16),

determinación de una distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos del flujo de datos en tiempo real isócrono que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono a partir de las marcas de tiempo del paquete de datos,

comprobar la distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono, según un patrón, por comparación con un estado ideal del flujo de datos en tiempo real isócrono, de manera que los patrones permiten una identificación de fallos específicos en los aparatos de comunicación (10, 12) y en la red de transmisión de datos (14) que une los aparatos de comunicación, y

determinación del lugar o de la causa del fallo en la transmisión del flujo de datos en tiempo real isócrono en la red de datos, basándose en el resultado de la comprobación de la distribución de frecuencias según un patrón.
2.

Procedimiento, según la reivindicación 1, en el que el estado ideal del flujo de datos en tiempo real isócrono es el estado ideal de la diferencia de tiempo entre dos paquetes de datos sucesivos del flujo de datos en tiempo real isócrono.
3.

Procedimiento, según la reivindicación 1 ó 2, en el que los paquetes de datos son paquetes de datos del RTP protocolo de transporte en tiempo real.
4.

Procedimiento, según una de las reivindicaciones 1 a 3, en el que el flujo de datos en tiempo real contiene datos de audio, de voz por IP o “Comfort Noise”.
5.

Procedimiento, según una de las reivindicaciones 1 a 4, en el que como causa del fallo son determinables la anchura de banda o un almacenamiento Buffer de componentes de red activos de la red de transmisión de datos (14).
6.

Procedimiento, según una de las reivindicaciones 1 a 5, en el que en la evaluación de la distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo sucesivas en los paquetes de datos que entran en la unidad de control (16) del flujo de datos en tiempo real isócrono se recurre a representaciones de datos técnicos del patrón para la diferenciación de un estado normal arbitrario con respecto a un estado de fallo y en caso de existencia de fallos, éstos son asociables al aparato de comunicación emisor (10, 12) o a la red de transmisión de datos (14).
7.

Procedimiento, según una de las reivindicaciones 1 a 6, en el que en la comprobación de un fallo en el aparato de comunicación emisor (10, 20), en base al patrón de la distribución de frecuencias, se puede determinar una causa concreta del fallo en el aparato de comunicación emisor.
8.

Procedimiento, según la reivindicación 7, en el que como causa del fallo se pueden determinar el sistema operativo del aparato de comunicación, la configuración del aparato de comunicación, su apilamiento o su implementación.
9.

Procedimiento, según una de las reivindicaciones 1 a 8, en el que para la evaluación de la causa del fallo se considerará si los componentes que participan en la transmisión de datos del flujo de datos en tiempo real son capaces o no de elaborar un paquete de datos según el RTP protocolo de transporte en tiempo real.
10.

Procedimiento, según una de las reivindicaciones 1 a 9, en el que para el análisis de fallos del flujo de datos en tiempo real isócrono del flujo de datos en tiempo real se analizará el flujo de datos en tiempo real entre ambos aparatos de comunicación (10, 12) en una o ambas direcciones en uno o varios puntos.
11.

Medio, que puede ser leído por ordenador, que comprende secciones de código de software que cuando son procesadas en un procesador de una unidad de control (16) en una red de datos (100), hacen que la unidad de control (16) genere un análisis de fallos de un flujo de datos en tiempo real isócrono en una red de datos (100), donde:

se reciben paquetes de datos del flujo de datos en tiempo real isócrono,

imagen1

se genera una marca de tiempo para cada paquete de datos transmitido entre los dos aparatos de comunicación (10, 12) de la red de datos (100), de manera que las marcas de tiempo caracterizan el punto de tiempo de la llegada de un correspondiente paquete de datos en la unidad de control (16),

se determina una distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo de manera sucesiva en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono a partir de las marcas de tiempo del paquete de datos del flujo de datos en tiempo real isócrono,

se lleva a cabo una comprobación de la distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo sucesivas en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono en la unidad de control (16) en base a un patrón, de manera que la comprobación en base al patrón tiene lugar por comparación de la distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono con una situación ideal del flujo de datos en tiempo real isócrono y los patrones posibilitan un reconocimiento de fallos específicos en los aparatos de comunicación (10, 12) y en la red de transmisión de datos (14) que une los aparatos de comunicación, y

se determina el lugar o la causa del fallo en la transmisión del flujo de datos en tiempo real isócrono en la red de datos basándose en el resultado de la comprobación de la distribución de frecuencias en base a un patrón.
12.

Medio, que puede ser leído por ordenador, según la reivindicación 11, que comprende secciones de código de software que cuando son procesadas en el procesador de la unidad de control (16), hacen que la unidad de control (16) origine el procedimiento según una de las reivindicaciones 2 a 10.
13.

Unidad de control para el análisis de fallos de un flujo de datos en tiempo real isócrono entre dos aparatos de comunicación (10, 12) de una red de datos, que está dispuesta para:

recibir paquetes de datos del flujo de datos en tiempo real isócrono,

generar una marca de tiempo para cada paquete de datos transmitido entre dos aparatos de comunicación (10, 12) de la red de datos (100), de manera que las marcas de tiempo caracterizan el punto de tiempo de la llegada de un correspondiente paquete de datos a la unidad de control (16).

determinar una distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono a partir de las marcas de tiempo del paquete de datos del flujo de datos en tiempo real isócrono,

comprobar por evaluación la distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono en la unidad de control (16) en base a un patrón, de manera que la comprobación en base a un patrón se lleva a cabo por comparación de la distribución de frecuencias de la diferencia de tiempo de las marcas de tiempo entre si en los paquetes de datos que llegan a la unidad de control (16) del flujo de datos en tiempo real isócrono con una situación ideal del flujo de datos en tiempo real, y los patrones posibilitan el reconocimiento de fallos específicos en los aparatos de comunicación (10, 12) y la red de transmisión de datos (14) que une los aparatos de comunicación, y,

determinar el lugar o la causa de un fallo en la transmisión del flujo de datos en tiempo real isócrono en la red de datos basándose en el resultado de la comprobación de la distribución de frecuencias según un patrón.
14. Sistema de comunicación con una unidad de control según la reivindicación 13.
15.

Sistema de comunicación, según la reivindicación 14, en el que la unidad de control (16) está dispuesta para la determinación de los paquetes de datos en un lugar arbitrario entre los aparatos de comunicación (10, 12).
16.

Sistema de comunicación, según las reivindicaciones 14 ó 15, que comprende una serie de unidades de control según la reivindicación 13.