Procedimiento y dispositivo para medir tráfico de datos.

Procedimiento para determinar el tráfico de datos de una conexión de comunicación orientada a la conexión entre al menos un cliente y al menos un servidor,

mediante un trayecto de transmisión bidireccional en una primera dirección de transmisión, donde para determinar el tráfico de la conexión se determina la cantidad de datos de usuario transmitidos en la primera dirección dentro de un intervalo de tiempo definido, y donde el intervalo de tiempo es definido a través de un momento de inicio fijo o dinámico y de un momento de finalización dinámico, caracterizado porque la transmisión de datos de usuario en la segunda dirección de transmisión determina el momento de finalización del intervalo de tiempo.

Procedimiento y dispositivo para medir tráfico de datos La presente invención hace referencia a un procedimiento para determinar el tráfico de datos de una conexión de comunicaciones orientada a la conexión entre un cliente y al menos un servidor, mediante un trayecto de transmisión bidireccional en una primera dirección de transmisión, donde para determinar el tráfico de la conexión se determina la cantidad de datos de usuario transmitidos en la primera dirección dentro de un intervalo de tiempo definido, y donde el intervalo de tiempo es definido a través de un momento de inicio fijo o dinámico y de un momento de finalización dinámico.

Los proveedores de redes tienen gran interés en la posibilidad de registrar parámetros específicos de la red del modo más preciso posible durante el funcionamiento de la red. Esa información debe considerarse ante todo para el mantenimiento y la optimización de la infraestructura de la red, así como para futuros dimensionamientos de la red. La medición del tráfico de datos que alcanza el cliente individual al utilizar un servicio de datos desempeña al respecto un papel fundamental.

Un acceso directo al cliente o al servidor de una conexión de datos para medir el tráfico de datos no se considera deseable, así como por lo general tampoco es posible. Por consiguiente, la medición del tráfico de datos debe tener lugar fuera de la red, registrando y evaluando los mensajes transmitidos entre los extremos.

Para medir el tráfico de datos que un cliente percibe al utilizar un servicio de datos, debe por tanto aclararse previamente qué tipo de datos deben considerarse para la medición del tráfico, y a lo largo de qué tiempo deben considerarse dichos datos. La precisión de la medición y, por tanto, la validez de los resultados de la medición, dependen por lo tanto del tipo de datos seleccionados, así como del tiempo definido.

Una primera posibilidad consiste en definir de forma fija el momento de inicio y el momento de finalización para un intervalo de medición. Todos los datos registrados que se transmiten dentro de ese intervalo de medición son contados a través del procedimiento y se utilizan para determinar el tráfico de datos. El tráfico resulta del volumen de datos a lo largo de un tiempo determinado.

La precisión del procedimiento de medición antes mencionado depende en gran medida del tipo de trasmisión de datos. Por ejemplo, este procedimiento de medición obtiene un resultado lo suficientemente preciso para el tráfico de datos en el caso de una conexión continua (streaming) , puesto que los datos a ser contados se transmiten de forma continua y sin interrupciones desde el emisor hacia el receptor, es decir desde el servidor hacia el cliente.

Una desventaja de los procedimientos de medición que se han propuesto se presenta en el caso de utilizarse en el así llamado tráfico a ráfagas (burst traffic) . Los paquetes de datos individuales se transmiten de forma intermitente en el tiempo de medición indicado. Entre los datos individuales se producen tiempos de inactividad en los cuales no se transmiten datos en el trayecto de transmisión y los cuales eventualmente indican una inactividad del emisor y del receptor en el tiempo indicado. Estos tiempos de inactividad probablemente pueden alterar el resultado de la medición de modo considerable.

Las pausas de inactividad entre las transmisiones de tipo ráfaga individuales pueden clasificarse en dos categorías separadas. Las comunicaciones entre el emisor y el receptor tienen lugar mediante un protocolo de comunicaciones orientado a la conexión. Después del establecimiento de la conexión son transmitidos paquetes de datos desde el emisor hacia el receptor hasta que hayan sido transmitidos todos los datos colocados en el búfer del emisor. La conexión entre el emisor y el receptor se mantiene sin embargo, independientemente del nivel de llenado del búfer del emisor. De este modo resulta una pausa de inactividad del emisor que continúa hasta un nuevo llenado del búfer del emisor. Esta clase de pausas de inactividad se denominará a continuación con el término "pausas de inactividad buenas". Estas pausas de inactividad son intencionadas, puesto que por ejemplo no se realiza ninguna petición de datos por parte del usuario.

A diferencia de éstas, las "pausas de inactividad malas" son las que se producen debido a diversos eventos o influencias en el trayecto de transmisión, así como a latencias en los trayectos de transmisión. Como ejemplos para problemas de transmisión de ese tipo pueden mencionarse el almacenamiento intermedio de paquetes de datos por parte de la red, el cual conduce a latencias en el trayecto de transmisión; la transmisión repetida de paquetes de datos individuales; mensajes de confirmación duplicados; así como a una configuración de parámetros errónea o noóptima del protocolo de transmisión utilizado. Las "pausas de inactividad malas" perjudican directamente la calidad de la transmisión, así como el tráfico de datos que puede lograrse entre el servidor y el cliente. Si se acumula la cantidad de paquetes de datos a transmitirse de forma repetida, esto reduce considerablemente el tráfico efectivo de la conexión de datos. Por lo tanto, esos tiempos de inactividad deben ser considerados necesariamente en la medición del tráfico para obtener resultados de medición lo suficientemente precisos.

Los procedimientos de medición antes mencionados prevén medidas para rechazar todos los tiempos de inactividad que se presenten al producirse la transmisión de paquetes de datos. Conforme a esto no tiene lugar una diferenciación entre tiempos de inactividad buenos y malos. Por lo tanto, la precisión de los resultados de medición es suficiente para las conexiones de datos de este tipo, en las cuales no se presentan tiempos de inactividad o se presentan mayormente tiempos de inactividad buenos. En el caso de conexiones de datos con tiempos de inactividad malos el resultado de medición se ve alterado en gran medida al no considerarse los tiempos de inactividad malos. En estos casos, el tráfico de datos medido se ubica por encima del tráfico de datos que realmente se produce, es decir que el resultado se muestra mejor de lo que es, no reflejando lo que el usuario en realidad percibe.

En la solicitud EP 1 746 788 A2 se revela un procedimiento para determinar la tasa de ráfaga de bits (burst bit rate) entre un servidor y un cliente durante un intervalo de tiempo definido. El momento de inicio del intervalo de cálculo se determina en el momento en el cual el primer paquete de datos llega a la pasarela del nodo soporte GPRS (Gateway GPRS Support Node) . La llegada del último paquete de datos al nodo mencionado define el momento de finalización del intervalo de cálculo.

Por la solicitud US 2001/0021176 A1 se conoce un procedimiento para el análisis estadístico de una conexión entre un primer y un segundo terminal. Los elementos individuales de la red registran la cantidad de paquetes que pertenecen a una conexión entre los terminales e informan sobre los mismos a una estación central de evaluación. El tiempo de medición se inicia al llegar el primer paquete y finaliza al detectarse un tiempo de inactividad determinado.

Por la solicitud WO 02/103630 A2 se conoce otro procedimiento para calcular la tasa de datos. En este documento se propone que sólo se registre la cantidad de bits transmitidos durante la transmisión de un par de mensajes correspondientes y que se consideren para calcular la tasa de datos.

Considerando estos antecedentes, es objeto de la presente invención indicar un procedimiento que posibilite un procedimiento mejorado para medir el tráfico de datos de una conexión de comunicaciones.

Este objeto se alcanzará a través de un procedimiento según la combinación de las características de la reivindicación 1. Otros perfeccionamientos ventajosos de la invención son objeto de las reivindicaciones dependientes.

Según la reivindicación 1 se sugiere un procedimiento para determinar el tráfico de datos de una conexión orientada a la conexión entre un cliente y al menos un servidor, sobre un trayecto de transmisión bidireccional en una primera dirección de transmisión, donde para determinar el tráfico se determina la cantidad de datos de usuario transmitidos en la primera dirección dentro de un intervalo de tiempo definido, y donde el intervalo de tiempo es definido a través de un momento de inicio fijo o dinámico y de un momento de finalización dinámico. El procedimiento se desarrolla independientemente de la dirección de transmisión a ser medida.

A continuación se abordará principalmente la medición del tráfico de datos en una primera dirección de transmisión que, a modo... [Seguir leyendo]

1. Procedimiento para determinar el tráfico de datos de una conexión de comunicación orientada a la conexión entre al menos un cliente y al menos un servidor, mediante un trayecto de transmisión bidireccional en una primera dirección de transmisión, donde para determinar el tráfico de la conexión se determina la cantidad de datos de usuario transmitidos en la primera dirección dentro de un intervalo de tiempo definido, y donde el intervalo de tiempo es definido a través de un momento de inicio fijo o dinámico y de un momento de finalización dinámico, caracterizado porque la transmisión de datos de usuario en la segunda dirección de transmisión determina el momento de finalización del intervalo de tiempo.

2. Procedimiento según la reivindicación 1, caracterizado porque el momento de inicio es definido a través de la transmisión de primeros datos de usuario en la primera dirección.

3. Procedimiento según la reivindicación 1, caracterizado porque el momento de inicio es definido a través del confirmación de primeros datos de usuario en la primera dirección.

4. Procedimiento según la reivindicación 3, caracterizado porque el momento de inicio es definido a través de N confirmaciones de primeros datos de usuario en la primera dirección.

5. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque los datos de usuario son contados en la primera dirección durante el intervalo de tiempo mediante los datos de usuario confirmados en la primera dirección.

6. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque todos los datos de usuario a ser asignados a la conexión establecida del protocolo de transmisión orientado de la conexión y/o una parte o todos los datos de usuario de otras conexiones, o una parte o todos los datos de usuario en la primera dirección que no se asignan a ninguna conexión, son contados durante el intervalo de tiempo.

7. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque el momento de finalización del intervalo de tiempo es definido a través de la transmisión de un mensaje de señalización en la primera y/o en la segunda dirección, donde preferentemente el mensaje de señalización señaliza la interrupción y/o la finalización de la conexión.

8. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque el momento de finalización del intervalo de tiempo es definido a través de una expiración del tiempo de la conexión y/o a través de la finalización de la conexión en otra capa de transmisión.

9. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque el momento de finalización real es definido a través del tiempo de la última confirmación antes de un evento que define el momento de finalización.

10. Dispositivo para ejecutar el procedimiento según una de las reivindicaciones 1 a 9.

11. Sistema de comunicaciones, en particular sistema de telecomunicaciones, con al menos un cliente, en particular con un equipo terminal móvil o fijo, y al menos con un servidor, así como con un dispositivo según la reivindicación

10.

12. Código de programa almacenado en un medio que puede ser leído por un ordenador para ejecutar el procedimiento según una de las reivindicaciones 1 a 9 en un dispositivo según la reivindicación 11.