ES2278760T3 - Emulacion de flujo de informacion. - Google Patents

Emulacion de flujo de informacion. Download PDF

Info

Publication number
ES2278760T3
ES2278760T3 ES01951195T ES01951195T ES2278760T3 ES 2278760 T3 ES2278760 T3 ES 2278760T3 ES 01951195 T ES01951195 T ES 01951195T ES 01951195 T ES01951195 T ES 01951195T ES 2278760 T3 ES2278760 T3 ES 2278760T3
Authority
ES
Spain
Prior art keywords
network element
network
packet
packets
call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES01951195T
Other languages
English (en)
Inventor
Vilho Raisanen
Pekka Pessi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Application granted granted Critical
Publication of ES2278760T3 publication Critical patent/ES2278760T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164Adaptation or special uses of UDP protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems

Abstract

Método para emular el flujo de información bidireccional de una aplicación real en un sistema, el cual comprende un primer elemento de red (101) y un segundo elemento de red (102), así como una red por paquetes (103) entre dicho primer elemento de red y dicho segundo elemento de red, comprendiendo dicho método: transmitir un conjunto de paquetes (300) desde el primer elemento de red a través de la red por paquetes al segundo elemento de red; recibir por lo menos parte de los paquetes transmitidos en el segundo elemento de red; transmitir los paquetes recibidos desde el segundo elemento de red a través de la red de paquetes de regreso al primer elemento de red en respuesta a la recepción de los paquetes en el segundo elemento de red, caracterizado porque el método comprende transmitir un paquete que ha llegado al segundo elemento de red de regreso al primer elemento de red solamente después de un retardo con respecto a la recepción del paquete en el segundo elemento de red.

Description

Emulación de flujo de información.
La presente invención se refiere a la emulación del flujo de información bidireccional de una aplicación real. Particularmente, aunque no de forma necesaria, la invención se refiere a la emulación del flujo de información de una llamada VoIP (Protocolo de Voz por Internet) para determinar la Calidad de Servicio (QoS) en un nivel de aplicación VoIP.
Tradicionalmente, cuando se realizan llamadas telefónicas la voz se transfiere en redes por conmutación de circuitos, tales como una Red Telefónica Conmutada Pública (PSTN). Cuando se realizan llamadas telefónicas en una red digital por conmutación de circuitos, se establece una conexión permanente de 64 kbps (kilobits por segundo) por cada llamada. La banda normalizada de la conexión, 64 kbps, es debida a la velocidad de bits requerida en el muestreo de voz analógica cuando se usa Modulación por Codificación de Impulsos (PCM) de 8 bits a una frecuencia de muestreo de 8 kHz, procedimiento que permite la transmisión de voz analógica con una frecuencia de 300 a 3400 Hz en un formato digital.
No obstante, la red telefónica digital descrita anteriormente que en la actualidad se usa de forma habitual es muy ineficaz y consume por lo tanto una cantidad importante de recursos de la red. En la red telefónica, se reserva también la banda para una conexión cuando no se usa activamente la conexión, es decir ninguna parte de la conexión está transfiriendo información, tal como voz o datos, a lo largo de la conexión. El tipo de uso de una banda estática consume muchos recursos de transmisión de datos y como consecuencia de ello se deben realizar inversiones en capacidad adicional a medida que aumenta el número de usuarios. El tipo de ineficacia descrito anteriormente causa problemas especialmente en llamadas entre continentes, en las que el aumento de la capacidad de transmisión de datos no resulta tan sencillo como en otros casos. El problema también se pone parcialmente de manifiesto en los precios de las llamadas; las inversiones costosas en capacidad se deben cubrir con tarifas de usuario elevadas.
Para compensar y complementar llamadas que usan una reserva de banda estática en una red telefónica, se han comenzado a comercializar las denominadas llamadas VoIP, es decir, llamadas IP. Típicamente, la información transmitida en una llamada IP, tal como conversación, voz y/o vídeo, se convierte en primer lugar de un formato analógico a un formato digital, y a continuación se comprime y se convierte a paquetes IP que son transportados sobre una red por conmutación de paquetes basada en el IP, tal como la red de Internet, compartiendo la banda con otro tráfico IP. En llamadas IP, se puede usar una banda de una manera considerablemente más eficaz que en llamadas que reservan una banda estática, lo cual se refleja también en los precios de las llamadas. Además, también se pueden usar esquemas de codificación nuevos más eficaces, tales como, por ejemplo, la codificación G.723.1.
El tiempo de llegada de los paquetes IP transmitidos a un receptor no se conoce antes de que lleguen los paquetes. Además, puesto que el IP encamina el flujo de información paquete a paquete, el tiempo de propagación de los paquetes de un emisor a un receptor puede variar notablemente y puede cambiar el orden de los paquetes. Además, se pueden perder paquetes, por ejemplo, como consecuencia de los desbordamientos de datos entrantes que tienen lugar en las memorias intermedias de los encaminadores. Usando un protocolo fiable sobre IP, por ejemplo, se pueden identificar automáticamente pérdidas de paquetes a un nivel de protocolo y se pueden retransmitir los paquetes perdidos. Uno de dichos protocolos es el TCP (Protocolo de Control de Transmisión).
No obstante, las retransmisiones en cuestión provocarían un retardo variable adicional en la transmisión de información sobre la red IP. Además, puesto que varias aplicaciones usadas en la repetición de voz y/o imágenes transferidas en tiempo real no funcionan a la perfección si, por ejemplo, se produce un retardo demasiado grande en la transmisión de información, el TCP no resulta adecuado para su uso como protocolo a usar sobre el IP en llamadas IP. Por lo tanto, en llamadas IP se usa normalmente el UDP (Protocolo de Datagrama de Usuario), en el que no se producen retransmisiones. En cambio, en un establecimiento de llamada, el uso del TCP es recomendable de manera que el establecimiento de la llamada tenga lugar de la forma más fiable posible.
Por ejemplo, simplemente por la razón de que las aplicaciones usadas en la repetición de información en tiempo real transmitida sobre una red IP presentan requisitos de tiempo real exigentes con el fin de funcionar perfectamente, se necesita por lo menos algún tipo de disposición para garantizar la Calidad de Servicio (QoS) deseada para la llamada IP en cuestión. El IP como tal no proporciona soporte de la QoS en una forma tal que proporcione una Calidad de Servicio garantizada. No obstante, existen varias técnicas diferentes con las cuales se puede proporcionar una QoS garantizada en una red IP. Estas son, entre otras, técnicas DiffServ (Servicios Diferenciados) e IntServ (Servicios Integrados). Independientemente de qué técnica de QoS se use, es importante que se pueda medir la QoS con el fin de averiguar si es realmente posible proporcionar una QoS garantizada para cada llamada IP.
Habitualmente se requieren varios parámetros QoS para describir una QoS. Así, resulta adecuado medir valores para un conjunto de diferentes parámetros QoS, los cuales en relación con el VoIP son, por ejemplo, los siguientes: retardo de extremo a extremo, fluctuación de retardo de extremo a extremo, pérdidas de paquetes y correlación de pérdidas de paquetes. De entre dichos parámetros, el retardo de extremo a extremo significa el tiempo que se requiere para que un paquete IP pase a través de una red IP de un emisor a un receptor. El retardo de extremo a extremo también se puede medir como una medición de ida y vuelta, con lo cual se mide el tiempo que se requiere para que un paquete IP pase de un emisor a un receptor y vuelva. La fluctuación de extremo a extremo se puede indicar, por ejemplo, como una varianza o desviación estándar. Las pérdidas de paquetes indican cuántos de los paquetes IP transmitidos no consiguen ser recibidos en el lado receptor, es decir cuántos paquetes IP se pierden en el camino. En cuanto al rendimiento del sistema, es sumamente significativo si los paquetes IP desaparecen o se pierden uno aquí y otro allá (ninguna correlación de pérdidas de paquetes) o si se pierden varios paquetes IP sucesivos (alta correlación de pérdidas de paquetes).
La Figura 1 muestra un principio de desarrollo de una medición de la QoS según la técnica anterior. En dicha figura se transmite un flujo continuo de paquetes IP desde un primer ordenador central 101 a través de una red IP 103 a un segundo ordenador central. Antes de realizar la transmisión, el primer ordenador central 101 añade una primera información a cada paquete IP a transmitir. El flujo continuo de paquetes IP transmitido por el primer ordenador central 101 es recibido en el segundo ordenador central 102, el cual añade una segunda información a los paquetes IP y los devuelve a través de la red IP 103 de regreso al primer ordenador central 101, el cual añade una tercera información a los paquetes IP recibidos.
La Figura 2 ilustra la estructura de un paquete IP, cuyo uso es bien conocido en la disposición de mediciones de la QoS ilustrada en la Figura 1. Un paquete IP 200 comprende varios tipos de campos para almacenar la información añadida por ordenadores centrales al paquete IP. Por ejemplo, en los campos 201 y 202, el primer ordenador central 101 almacena, justo antes de transmitir el paquete IP, como dicha primera información, unos datos de indicación de tiempo TS_{1} y unos datos de número de secuencia del paquete SEC_{1}, respectivamente. En los campos 203 y 204, el segundo ordenador central 102 almacena como dicha segunda información al recibir el paquete IP unos datos de indicación de tiempo TS_{2} y unos datos de número de secuencia del paquete SEC_{2}, respectivamente. Después de recibir el paquete IP, el segundo ordenador central 102 devuelve el paquete IP inmediatamente de regreso al primer ordenador central 101 el cual almacena, en un campo 205, como dicha tercera información, unos datos de indicación de tiempo TS_{3} al recibir el paquete IP. A continuación, de entre los parámetros QoS, se puede determinar por ejemplo el retardo de extremo a extremo d_{rt} mediante la ecuación d_{rt} = TS_{3} - TS_{1}.
Además de los campos 201 a 205, el paquete IP 200 de la Figura 2 comprende un tramo ficticio 206. El tramo ficticio 206 es una parte de datos de una longitud específica con la cual la longitud del paquete IP se puede adaptar al tamaño de los paquetes de un códec realista, tal como G.711. Si los paquetes IP 200 ya se transmiten como un flujo continuo típicamente uniforme de paquetes IP tal como el formado por un códec realista, se puede emular una llamada IP real y sus mediciones de la QoS con la disposición presentada anteriormente.
No obstante, la disposición según la técnica anterior antes descrita presenta problemas propios. Supóngase que se envía un flujo continuo de paquetes IP 200 desde el primer ordenador central 101 a través de la red IP 103 al segundo ordenador central 102 y que la transmisión de los paquetes IP desde el primer ordenador central al segundo tiene lugar de manera uniforme. En un caso ideal, el tiempo de transmisión de todos los paquetes IP (retardo de extremo a extremo) del primer ordenador central al segundo es el mismo, con lo cual los paquetes IP enviados desde el primer ordenador central llegarían también al segundo ordenador central de manera uniforme. No obstante, en realidad, la situación es típicamente tal que, por ejemplo, debido a una carga variable de la red IP, los paquetes no llegan al segundo ordenador central uniformemente, sino por ráfagas. Con esto se quiere decir que el flujo continuo de paquetes IP que llega al segundo ordenador central comprende densidades (agrupaciones de paquetes IP) y espaciamientos (se produce una pausa excepcionalmente larga entre los paquetes IP) en lugar de un flujo continuo constante.
Cuando el segundo ordenador central devuelve a continuación cada paquete IP que ha recibido, de regreso al primer ordenador central, el flujo continuo de paquetes IP devueltos ya está preparado para salir del segundo ordenador central por ráfagas y no uniformemente tal como se produciría en el caso de una llamada IP realista. En este caso, la QoS experimentada por el flujo continuo de paquetes IP por ráfagas que regresa del segundo ordenador central al primer ordenador central es normalmente peor que la QoS experimentada por el flujo continuo de paquetes IP transmitido uniformemente del primer ordenador central al segundo ordenador central. Esta asimetría no es característica de una llamada IP real y distorsiona la medición de los valores de los parámetros QoS. Además, si se pierden paquetes IP enviados por el primer ordenador central en su camino al segundo ordenador central, el flujo continuo de paquetes IP devueltos del segundo ordenador central al primero tiene menos paquetes IP que el flujo continuo original de paquetes IP enviados del primer ordenador central al segundo. En este caso, se forman automáticamente más espaciamientos adicionales en el flujo continuo de paquetes IP devueltos del segundo ordenador central al primero, lo cual hace que aumente nuevamente la asimetría.
El sistema de prueba de redes del documento EP0910194A2 se usa para monitorizar y simular una red.
Así, la disposición de mediciones según la técnica anterior antes presentada no resulta adecuada de la mejor manera posible para las mediciones de la QoS de una llamada IP. Llegado este momento, se ha inventado una nueva solución, la cual resulta adecuada para realizar mediciones de la QoS de una llamada IP. Según un primer aspecto de la invención, se implementa un método para emular el flujo de información bidireccional de una aplicación real en un sistema, el cual comprende un primer elemento de red y un segundo elemento de red, así como una red de paquetes entre dicho primer elemento de red y dicho segundo elemento de red, comprendiendo dicho método:
transmitir un conjunto de paquetes desde el primer elemento de red a través de la red de paquetes al segundo elemento de red;
recibir por lo menos parte de los paquetes transmitidos en el segundo elemento de red;
transmitir los paquetes recibidos, desde el segundo elemento de red a través de la red de paquetes de regreso al primer elemento de red en respuesta a la recepción de los paquetes en el segundo elemento de red.
Es característico del método que comprenda:
transmitir un paquete que ha llegado al segundo elemento de red de regreso al primer elemento de red solamente después de un retardo con respecto a la recepción del paquete en el segundo elemento de red.
De acuerdo con un segundo aspecto de la invención, se implementa un sistema para emular el flujo de información bidireccional de una aplicación real, comprendiendo dicho sistema un primer elemento de red y un segundo elemento de red, así como una red de paquetes entre dicho primer elemento de red y dicho segundo elemento de red, comprendiendo dicho primer elemento de red:
unos medios para transmitir un conjunto de paquetes desde el primer elemento de red a través de la red de paquetes al segundo elemento de red, y el segundo elemento de red comprende:
unos medios para recibir por lo menos parte de los paquetes transmitidos en el segundo elemento de red;
unos medios para transmitir los paquetes recibidos, desde el segundo elemento de red a través de la red de paquetes de regreso al primer elemento de red en respuesta a la recepción de los paquetes en el segundo elemento de red.
Es característico del sistema que el segundo elemento de red comprenda además:
unos medios para transmitir un paquete que ha llegado al segundo elemento de red de regreso al primer elemento de red solamente después de un retardo con respecto a la recepción del paquete en el segundo elemento de red.
Según un tercer aspecto de la invención, se implementa un elemento de red para emular el flujo de información bidireccional de una aplicación real en un sistema, el cual además de dicho elemento de red comprende un primer elemento de red específico y una red de paquetes entre el elemento de red y dicho primer elemento de red, comprendiendo dicho elemento de red:
unos medios que reciben paquetes transmitidos desde dicho primer elemento de red a través de la red de paquetes;
unos medios para transmitir los paquetes recibidos a través de la red de paquetes de regreso al primer elemento de red en respuesta a la recepción de los paquetes en el elemento de red.
Es característico del elemento de red que el elemento de red comprenda además:
unos medios para transmitir un paquete que ha llegado al elemento de red de regreso al primer elemento de red solamente después de un retardo con respecto a la recepción del paquete en el elemento de red.
Según un cuarto aspecto de la invención, se implementa un producto de programa de ordenador ejecutable en un elemento de red para emular el flujo de información de una aplicación real en un sistema, el cual además de dicho elemento de red comprende un primer elemento de red específico y una red de paquetes entre el elemento de red y dicho primer elemento de red, comprendiendo dicho producto de programa de ordenador un código de programa:
para recibir en el elemento de red paquetes transmitidos desde el primer elemento de red a través de la red de paquetes;
para transmitir los paquetes recibidos, a través de la red de paquetes de regreso al primer elemento de red en respuesta a la recepción de los paquetes en el elemento de red.
Es característico del producto de programa de ordenador que el producto de programa de ordenador comprenda un código de programa:
para transmitir un paquete que ha llegado al elemento de red de regreso al primer elemento de red solamente después de un retardo con respecto a la recepción del paquete en el elemento de red.
En una forma de realización preferida de la invención, dichos elementos de red son ordenadores, tales como ordenadores PC (Ordenador Personal), ordenadores de estación de trabajo u ordenadores servidores de red, y dichos paquetes son paquetes de comunicación, tales como paquetes IP. La presente invención permite una emulación del flujo de información bidireccional de una aplicación real, tal como el flujo de información de una llamada IP, a un nivel de aplicación con flujos continuos uniformes de paquetes IP y señalización, que es mejor que la que se conoce a partir de la técnica anterior y, por lo tanto, permite la realización de mediciones de la QoS más fiables que las soluciones conocidas. La invención se puede usar, entre otras opciones, en el diseño de redes y para realizar pruebas sobre el rendimiento de una red desde el punto de vista del VoIP.
Con la expresión red IP se da a entender, en la presente descripción, además de redes basadas en el IP, tales como redes de Internet e Intranet, también otras redes de paquetes similares, tales como la red X.25. Con la expresión llamada IP, se da a entender una llamada en la que se transfiere información, preferentemente conversación, voz, vídeo o multimedia, a través de este tipo de red típicamente para implementar un servicio en tiempo real. Así, la invención se puede usar también para emular una videoconferencia.
A continuación, se describirá con detalle la invención, haciendo referencia a los dibujos adjuntos, en los cuales
la Figura 1 muestra el principio de funcionamiento de una medición de la QoS según la técnica anterior;
la Figura 2 muestra la estructura de un paquete IP usado en una medición de la QoS según la técnica anterior;
la Figura 3 ilustra la estructura de un paquete IP adecuado para la implementación de una forma de realización de la invención;
la Figura 4 muestra un caso ilustrativo con la ayuda del cual se ilustra una forma de realización de la invención;
la Figura 5 es un diagrama de un dominio en el tiempo que muestra el caso ilustrativo mostrado en la Figura 4; y
la Figura 6 ilustra un hardware para implementar la invención.
Las Figuras 1 y 2 ya se han explicado anteriormente en relación con la descripción de la técnica anterior. A continuación, se explicará una forma de realización preferida de la invención en la que se emula una llamada IP entre un primer ordenador central y un segundo ordenador central y se realizan mediciones de la QoS. La Figura 1 también puede ilustrar de forma aproximada una disposición de mediciones según la invención. En una forma de realización preferida de la invención, un primer ordenador central 101 transmite a través de una red IP 103 a un segundo ordenador central 102 un flujo continuo uniforme similar de paquetes IP como el formado por un códec realista, tal como el G.711, en el que el tamaño de los paquetes IP se corresponde con el tamaño de los paquetes formados por el códec real. Los paquetes IP se transmiten preferiblemente usando el UDP sobre IP. La Figura 3 ilustra la estructura de un paquete IP, el cual se usa en la forma de realización preferida de la invención. Un paquete IP 300 comprende varios tipos de campos para almacenar la información añadida por los ordenadores centrales a cada paquete IP en momentos específicos de tiempo. En los campos 301 y 302 de cada paquete IP, el primer ordenador central 101 almacena como primera información, justo antes de transmitir cada paquete IP 300, unos datos de indicación de tiempo TS_{1} y unos datos de número de secuencia de paquete SEC_{1}, respectivamente. Por ejemplo, cuando se transmite un primer paquete IP, el primer ordenador central almacena como datos de indicación de tiempo TS_{1} del paquete IP en cuestión el tiempo de transmisión del paquete IP en cuestión y como datos del número de secuencia SEC_{1}, el número 1. De forma correspondiente, como datos de indicación de tiempo TS_{1} de un segundo paquete IP se almacena el tiempo de transmisión del segundo paquete IP y como número de secuencia SEC_{1}, el número 2, y así sucesivamente.
A medida que los paquetes IP del flujo continuo de paquetes IP llegan al segundo ordenador central 102, el segundo ordenador central almacena en los campos 303 y 304 de cada paquete IP como segunda información unos datos de indicación de tiempo TS_{2} y unos datos de número de secuencia del paquete SEC_{2}, respectivamente. Cuando en el primer paquete IP (el cual no es necesariamente el paquete IP que transmitió en primer lugar el primer ordenador central) del flujo continuo de paquetes IP llega al segundo ordenador central, a continuación el segundo ordenador central almacena el tiempo de llegada del paquete IP en cuestión en el segundo ordenador central como datos de indicación de tiempo TS_{2} del paquete IP en cuestión y el número 1 como datos de número de secuencia SEC_{2}. De forma correspondiente, el tiempo de llegada del segundo paquete IP al segundo ordenador central se almacena como datos de indicación de tiempo TS_{2} del paquete IP en cuestión y el número 2 como número de secuencia SEC_{2}, y así sucesivamente.
No obstante, según la invención, los paquetes IP que han llegado al segundo ordenador central no se devuelven inmediatamente al primer ordenador central, sino que los mismos (o sus datos) se guían a una memoria intermedia en el segundo ordenador central desde la cual a continuación se transmiten en el orden de llegada de regreso al primer ordenador central como un flujo continuo uniforme similar de paquetes IP como el formado por un códec realista usado en una llamada IP. De esta manera, se puede eliminar la asimetría en la transmisión de paquetes IP de una forma mejor que en soluciones conocidas a partir de la técnica anterior. Cuando se transmite cada paquete IP almacenado en la memoria intermedia de regreso al primer ordenador central, el segundo ordenador central almacena en un campo 305 de cada paquete IP como tercera información unos datos de indicación de tiempo TS_{3}. El tiempo de transmisión de cada paquete IP se almacena como datos de indicación de tiempo TS_{3}.
A medida que los paquetes IP del flujo continuo de paquetes IP devueltos desde el segundo ordenador central al primer ordenador central llegan al primer ordenador central, el primer ordenador central almacena en un campo 306 de cada paquete IP como cuarta información unos datos de indicación de tiempo TS_{4}. El tiempo de llegada de cada paquete IP al primer ordenador central se almacena como datos de indicación de tiempo TS_{4}. Preferiblemente, para indicar la secuencia en la cual los paquetes IP regresan al primer ordenador central, no se requiere un nuevo indicador de número de secuencia (por ejemplo SEC_{3}), si los paquetes IP recibidos (o los datos que comprenden los mismos) se almacenan en la misma secuencia con la que llegaron al primer ordenador central. No obstante, naturalmente es posible usar el indicador de número de secuencia SEC_{3} en relación con la invención.
Además de los campos 301 a 306, el paquete IP 300 de la Figura 3 comprende un tramo ficticio 307. El tramo ficticio 307 es una parte de datos de una longitud específica que no presenta necesariamente ningún otro significado mas que con dicho tramo la longitud de un paquete IP se puede adaptar al tamaño de los paquetes de un códec realista, tal como el G.711. Además de los campos mostrados en la Figura 3, el paquete IP 300 comprende típicamente encabezamientos IP y UDP, entre otros elementos, para la información de dirección y los números de puerto de un emisor y un receptor. El contenido de los campos 301 a 307 se puede designar con la expresión carga útil.
A continuación, de entre los parámetros QoS, se puede determinar un retardo de extremo a extremo de ida y vuelta d_{rt} mediante la ecuación d_{rt,nuevo} = TS_{4} - TS_{1} -(TS_{3} - TS_{2}). Si se han sincronizado los relojes del primer y el segundo ordenadores centrales, los retardos de extremo a extremo en un sentido se pueden calcular usando las ecuaciones d_{us,1} = TS_{2} - TS_{1} (el trayecto del segundo ordenador central al primero) y d_{us,2} = TS_{4} - TS_{3} (el trayecto de vuelta del segundo ordenador central al primero). En la sincronización de los ordenadores centrales, se puede usar por ejemplo el GPS (Sistema Global de Determinación de la Posición).
Se obtiene material para calcular la fluctuación de retardo de extremo a extremo, por ejemplo, calculando las diferencias entre las indicaciones de tiempo TS_{2} de paquetes IP sucesivos que han llegado al segundo ordenador central. A continuación, sobre la base de las diferencias, por ejemplo, se puede calcular la varianza y/o la desviación estándar de la fluctuación de retardo de extremo a extremo (del primer ordenador central al segundo ordenador central).
Se pueden descubrir pérdidas de paquetes cuando se conoce el número de paquetes IP transmitidos. En este caso, cuando el flujo continuo de paquetes IP ha realizado el trayecto de ida y vuelta entre el primer y el segundo ordenadores centrales, el número de paquetes perdidos durante la primera parte se puede hallar, por ejemplo, restando del número de paquetes transmitidos el número de paquetes IP que han llegado al segundo ordenador central.
Se puede revisar la correlación de pérdidas de paquetes (en este caso desde el primer ordenador central al segundo ordenador central) estudiando los números de secuencia SEC_{1} de los paquetes IP recibidos en el segundo ordenador central y viendo qué números de secuencia faltan.
A continuación, se presentará más detalladamente la implementación de la forma de realización preferida de la invención con ayuda de un caso ilustrativo, haciendo referencia a las Figuras 4 y 5 de entre las cuales la Figura 4 muestra la disposición básica en el caso ilustrativo y la Figura 5 es el diagrama de un dominio en el tiempo para ilustrar el caso ilustrativo. En la Figura 5, el eje de tiempos izquierdo muestra el tiempo según el reloj del primer ordenador central y el eje de tiempos derecho muestra el tiempo según el reloj del segundo ordenador central. Se pueden sincronizar entre sí los relojes del primer y el segundo ordenadores centrales.
Supóngase que el número de paquetes IP a transmitir N = 4. En la transmisión de los paquetes IP, se emula el intervalo de transmisión de paquetes IP formados por un códec realista, de manera que sea por ejemplo \Deltat_{ti}. Antes de las mediciones de la QoS, se envía un mensaje del primer ordenador central al segundo ordenador central, en el que al segundo ordenador central se le indican los valores de los parámetros N, \Deltat_{ti} y el retardo de memoria intermedia \Deltat_{mem}. Se debe indicar en este momento que aunque por razones de simplicidad en este caso ilustrativo el número de paquetes IP transmitidos N = 4, en realidad el número de paquetes IP transmitidos puede ser considerablemente mayor, por ejemplo varios cientos o miles.
Llegado este momento, del primer ordenador central 101 al segundo ordenador central 102 a través de la red IP 103, se transmite un flujo continuo de paquetes IP en el que, en un primer paquete IP (paquete A), se almacenan el número de secuencia SEC_{1} = 1 y la indicación de tiempo TS_{1} justo antes de transmitir el paquete IP en cuestión en el instante de tiempo t_{1}, en un segundo paquete IP (paquete B), se almacenan el número de secuencia SEC_{1} = 2 y la indicación de tiempo TS_{1} en el instante de tiempo t_{2}, en un tercer paquete IP (paquete C), se almacenan el número de secuencia SEC_{1} = 3 y la indicación de tiempo TS_{1} en el instante de tiempo t_{3}, y en un cuarto paquete IP (paquete D), se almacenan el número de secuencia SEC_{1} = 4 y la indicación de tiempo TS_{1} en el instante de tiempo t_{4}. Los paquetes IP se transmiten a intervalos de \Deltat_{ti}, con lo cual t_{2} - t_{1} = \Deltat_{ti}, t_{3} - t_{2} = \Deltat_{ti} y t_{4} - t_{3} = \Deltat_{ti}. Dichos instantes de tiempo t_{1}, t_{2}, t_{3} y t_{4} se producen en concordancia con el reloj del primer ordenador central.
Después de obtener el mensaje del primer ordenador central, mensaje en el cual se indica que el número de los paquetes IP transmitidos N es cuatro, el segundo ordenador central almacena en una memoria intermedia específica (de transmisión) cuatro paquetes IP cuyos números de secuencia son SEC_{2} = -1 (el primer paquete IP a transmitir desde la memoria intermedia (paquete E)), SEC_{2} = -2 (el segundo paquete (paquete F)), SEC_{2} = -3 (el tercer paquete (paquete G)), SEC_{2} = -4 (el cuarto paquete (paquete H)).
Después de recibir, en el instante de tiempo t_{5}, el primero de los paquetes IP transmitidos por el primer ordenador central, el cual en este caso es el paquete IP (paquete A) que se transmitió también en primer lugar (esto no siempre es así, por ejemplo si en el camino se pierde el primer paquete IP), el segundo ordenador central almacena en el paquete IP en cuestión (paquete A) la indicación de tiempo TS_{2} y almacena como número de secuencia SEC_{2} = 1. Después de esto, el segundo ordenador central copia los datos de indicación de tiempo y de número de secuencia (TS_{1}, SEC_{1} = 1, TS_{2} y SEC_{2} = 1) del paquete IP en cuestión (paquete A) en el paquete IP (paquete E) que es en la memoria intermedia el primero en orden secuencial a transmitir tras lo cual, entre otros aspectos, en el paquete IP que es en la memoria intermedia el primero en orden secuencial a transmitir, el número de secuencia (paquete E) SEC_{2} = -1 se sustituye por el número 1. A continuación el paquete E se transmite desde el segundo ordenador central al primer ordenador central después del retardo de memoria intermedia \Deltat_{mem}, en el instante de tiempo t_{11} = t_{5} + \Deltat_{mem}. Justo antes de la transmisión, el segundo ordenador central almacena, en el paquete E, la indicación de tiempo TS_{3}. Esta operación tiene lugar aproximadamente en el instante de tiempo t_{11}.
Cuando a continuación se ha dado inicio al flujo continuo de paquetes IP a devolver, los otros tres paquetes IP (paquetes F, G y H) esperan a ser transmitidos en la memoria intermedia del segundo ordenador central a intervalos de \Deltat_{ti} en los instantes de tiempo t_{12} (paquete F), t_{13} (paquete G) y t_{14} (paquete H), con lo cual, si para los paquetes E, F, G y H, se usan respectivamente los números de índice j = 1, 2, 3, 4, se obtiene el tiempo de transmisión \Deltat_{1j} de cada paquete de acuerdo con el reloj del segundo ordenador central a partir de la ecuación \Deltat_{1j} = t_{5} + \Deltat_{mem} + (j -1) \Deltat_{ti}.
De forma correspondiente, cuando se recibe algún otro paquete IP (que no sea el paquete A descrito anteriormente) que pertenezca a un flujo continuo de paquetes IP enviados desde el primer ordenador central al segundo ordenador central, el segundo ordenador central almacena en el paquete recibido la indicación de tiempo TS_{2} y el número de secuencia SEC_{2}, después de lo cual el segundo ordenador central copia los datos del paquete IP recibido en un paquete IP, de la memoria intermedia de transmisión del segundo ordenador central, tal que es el siguiente en orden secuencial a ser transmitido, en el que no se han copiado todavía los datos de algún paquete IP que haya llegado. Antes de transmitir cada paquete IP, el segundo ordenador central ya almacena en cada paquete a transmitir la indicación de tiempo TS_{3}. Así, en la situación ilustrada por las Figuras 4 y 5, después de recibir el paquete B, el segundo ordenador central almacena en el mismo la indicación de tiempo TS_{2} en el instante de tiempo t_{6} y el número de secuencia
SEC_{2} = 2 ya que el paquete B es el segundo paquete IP que llega al segundo ordenador central. Los datos del paquete B se copian en el paquete F que espera a ser transmitido en la memoria intermedia, con lo cual, entre otras opciones, el número de secuencia del paquete F SEC_{2} = - 2 se sustituye por el número 2. En el instante de tiempo t_{12} se transmite el paquete F. Justo antes de la transmisión, en el paquete F se almacena la indicación de tiempo TS_{3}.
A continuación, se revisará una situación en la que tiene lugar una pérdida de paquetes en el caso ilustrativo mostrado en las Figuras 4 y 5. Supóngase que el paquete C desaparece y no consigue llegar al segundo ordenador central. No obstante, puesto que el retardo de la memoria intermedia \Deltat_{mem} en este caso es tan grande que el paquete (paquete D) transmitido a continuación logra llegar al segundo ordenador central en el instante de tiempo t_{8}, el cual es anterior al tiempo de transmisión del paquete G t_{13} = t_{5} + \Deltat_{mem} + 2 \Deltat_{ti} (el paquete G es el paquete en el que se deberían copiar los datos del paquete C para la transmisión de retorno), en lugar del paquete C perdido, en el paquete G se copian los datos del paquete D (TS_{1}, SEC_{1} = 4, TS_{2} y SEC_{2} = 3), con lo cual, entre otras opciones, el número de secuencia del paquete G SEC_{2} = -3 se sustituye por el número 3. El paquete G se transmite en el instante de tiempo t_{13}. La indicación de tiempo TS_{3} se almacena en el paquete G justo antes de la transmisión.
Puesto que el paquete C no consigue llegar al segundo ordenador central, no se dispone de un paquete IP que haya llegado al segundo ordenador central tal que desde el mismo no se hayan copiado ya datos en algún paquete, con lo cual no hay nada que copiar en el paquete H. No obstante, con el fin de que se pueda mantener un flujo continuo uniforme de paquetes IP, el paquete H se transmite como un paquete denominado ficticio (paquete de relleno) en el instante de tiempo de transmisión t_{14}, aunque el mismo no comprende en este caso valores basados en los datos de indicación de tiempo real y de número de secuencia correspondientes a TS_{1}, SEC_{1} y TS_{2}. Antes de transmitir la indicación de tiempo, en el paquete H se almacena TS_{3}. Puesto que en el paquete H no se copió tampoco un número de secuencia nuevo SEC_{2}, el número de secuencia negativo original SEC_{2} = -4 permanece como el número de secuencia del paquete H.
Cuando los paquetes E, F, G y H llegan al primer ordenador central en los instantes de tiempo t_{15} t_{16}, t_{17} y t_{18}, respectivamente, el primer ordenador central almacena en los mismos las indicaciones de tiempo TS_{4}. Llegado este momento, para los parámetros QoS se pueden determinar valores tal como se describió ya anteriormente. Si el número de secuencia de algún paquete IP recibido SEC_{2} es negativo, el primer ordenador central lo identificará como un paquete ficticio, con lo cual no tiene en cuenta la información que se pueda encontrar en los campos 301 (TS_{1}), 302 (SEC_{1}) y/o 303 (TS_{2}) del paquete ficticio, ya que esta información no se basa en los datos de indicación de tiempo real o de número de secuencia. La existencia de paquetes ficticios en el flujo continuo devuelto de paquetes IP significa normalmente que por lo menos uno de los paquetes IP transmitidos originalmente del primer al segundo ordenador central no ha conseguido llegar al segundo ordenador central o ha llegado al mismo demasiado tarde. No obstante, en la invención se han tomado en consideración situaciones de errores como la mencionada según la manera presentada anteriormente (por ejemplo mediante el uso de paquetes ficticios), y la emulación de una llamada IP realista y las mediciones de la QoS tendrán éxito incluso si se produjeran pérdidas de paquetes.
En una llamada IP, en la que se transfiere voz en tiempo real, se producen normalmente secuencias habladas y periodos de silencio (pausas). Esto se debe al hecho de que cuando una parte de la llamada IP habla, la contraparte normalmente guarda silencio. Para algunos terminales VoIP (terminal inalámbrico, teléfonos), se han desarrollado detectores VAD (Detección de Actividad Vocal), los cuales funcionan de manera que cuando el nivel de una señal de voz que entra en el detector VAD cae por debajo de un límite específico (el hablante está en silencio), ya no se transmitirán paquetes IP al extremo receptor. En este caso, se ahorra banda de transmisión de datos.
A continuación, se complementará la descripción de la invención presentando cómo para realizar mediciones de la QoS se puede emular una llamada IP según la invención, cuyas partes comunicantes disponen de una función VAD en sus terminales VoIP. Llegado este momento los paquetes IP se transmiten del primer ordenador central al segundo ordenador central todavía a intervalos de \Deltat_{ti}, pero cuando se ha transmitido un total de N_{ts} paquetes IP, se realiza una pausa en la transmisión de los paquetes IP que durará un período de N_{sp}\Deltat_{ti}. Después de esto se asigna un nuevo valor para N_{ts} y se transmiten paquetes IP durante un período de N_{ts}\Deltat_{ti}. A continuación, se asigna un nuevo valor para N_{sp} y se realiza nuevamente una pausa en la transmisión de paquetes IP durante un período de N_{sp}\Deltat_{ti}, y así sucesivamente. Las cifras N_{ts} y N_{sp} se asignan a partir de funciones de distribución aleatoria P(N_{ts}) y P(N_{sp}), respectivamente, de entre las cuales P(N_{ts}) emula la distribución de las longitudes de secuencias habladas y P(N_{sp}) la distribución de las longitudes de períodos de silencio en una llamada IP real. El material para formar las distribuciones P(N_{ts}) y P(N_{sp}) se ha obtenido, por ejemplo, midiendo longitudes de secuencias habladas y pausas en llamadas IP reales.
En la práctica, los valores de N_{ts} y N_{sp} se pueden asignar para cada secuencia hablada y período de silencio de forma mutuamente independiente en el primer y el segundo ordenadores centrales. Además, puesto que la información sobre el número N de los paquetes transmitidos se ha suministrado ya, antes del comienzo de las mediciones de la QoS, desde el primer ordenador central al segundo, el número total de paquetes IP transmitidos en ambas direcciones coincidirá. Alternativamente, los valores de N_{ts} y N_{sp} se pueden asignar solamente en el primer ordenador central, en cuyo caso la transmisión de paquetes IP devueltos por el segundo ordenador central al primer ordenador central se puede temporizar durante un período de tiempo en el que los paquetes IP no estén llegando al segundo ordenador central. Por lo tanto en este caso el segundo ordenador central "está escuchando" si están entrando paquetes IP y, si no lo están, el segundo ordenador central inicia la devolución de los paquetes IP que están en la memoria intermedia, hacia el primer ordenador central. En la práctica, la "escucha" se puede implementar, por ejemplo, de manera que si al segundo ordenador central no han llegado paquetes IP antes de un tiempo específico (por ejemplo, el retardo de la memoria intermedia \Deltat_{mem}), el segundo ordenador central concluye que el primer ordenador central tiene activo un período de silencio, tras lo cual inicia la devolución de paquetes IP al primer ordenador central.
La presente descripción se ha centrado anteriormente en describir la emulación de una llamada IP y la realización de las mediciones de la QoS en la llamada IP. Puesto que, en una llamada IP real, se usa el UDP en el que no se usan retransmisiones ni acuses de recibo, naturalmente los mismos tampoco aparecen en la descripción de la invención. No obstante, en un establecimiento de llamada IP, se debe usar un protocolo fiable, con lo cual las retransmisiones y los acuses de recibo de paquetes ganan en interés. Los protocolos de señalización VoIP bien conocidos son, entre otros, el H.323 y el SIP (Protocolo de Inicio de Sesión). Los protocolos de señalización hacen posible en un establecimiento de llamada, por ejemplo, el hecho de que un terminal VoIP (primer ordenador central) que está realizando una llamada IP y un terminal VoIP (segundo ordenador central) que responde a la llamada IP puedan comunicarse el uno al otro qué tipo de códec está usando cada una de las partes de la llamada. Por ejemplo, en el H.323, la mayor parte de la señalización usada en un establecimiento de llamada tiene lugar usando un protocolo fiable, el TCP. Según la invención, se emula el establecimiento de una llamada IP enviando uno o más paquetes IP del primer al segundo ordenador central, dependiendo del protocolo de señalización a emular. Dicho paquete IP usado para emular el establecimiento de la llamada es similar en otros aspectos al paquete IP 300 descrito anteriormente, aunque en lugar del encabezamiento UDP el mismo comprende un encabezamiento TCP. Así, en la emulación de un establecimiento de llamada, los paquetes IP se transmiten preferiblemente usando el TCP sobre IP. Un encabezamiento TCP comprende típicamente, entre otros elementos, información que se puede usar en la retransmisión de paquetes IP perdidos.
En la emulación de un establecimiento de llamada, siempre después de recibir un paquete IP transmitido por el primer ordenador central el segundo ordenador central transmite inmediatamente el mismo paquete IP de regreso al primer ordenador central. Llegado este momento, se puede medir el tiempo de establecimiento de la llamada, el cual es el tiempo que se consume desde la transmisión del primer paquete IP a la recepción del último paquete IP en el primer ordenador central. Alternativamente, es posible transmitir desde el primer ordenador central solamente un paquete IP y esperar que el mismo regrese del segundo ordenador central. A continuación, cuando se recibe el paquete IP devuelto en el primer ordenador central, se puede obtener una aproximación del tiempo de establecimiento de la llamada multiplicando el tiempo entre la transmisión del paquete IP y la recepción del paquete IP devuelto, por ejemplo, por algún número adecuado para este fin. En la determinación del tiempo de establecimiento de la llamada, no se requieren necesariamente en absoluto las indicaciones de tiempo TS_{2} y TS_{3}, ya que el paquete IP se transmite de regreso inmediatamente después de llegar al segundo ordenador central. El tiempo entre la transmisión del paquete IP y la recepción del paquete IP devuelto se obtiene restando de la indicación de tiempo TS_{4} la indicación de tiempo TS_{1}.
Naturalmente, la emulación real de una llamada IP y las mediciones de la QoS de la llamada IP comenzarán solamente después de que se haya completado la emulación de la señalización relacionada con el establecimiento de la llamada.
La Figura 6 muestra un hardware adecuado para implementar la invención. El hardware comprende un primer ordenador central 101 y un segundo ordenador central 102, así como una red IP 103 entre los ordenadores centrales. Los ordenadores centrales pueden ser, por ejemplo, ordenadores PC que se pueden acoplar a la red IP 103, por ejemplo, con una tarjeta de acceso a la red (no mostrada en la figura). El primer y el segundo ordenadores centrales comprenden una unidad MCU (Unidad de Control Principal) que controla al ordenador central, así como una memoria MEM. La MCU puede ser por ejemplo un microprocesador. Los bloques 701 a 709 son bloques funcionales, en los que la MCU está dispuesta para llevar a cabo actividades específicas sobre la base de un programa almacenado en la MEM del ordenador central. En el bloque 701, se almacenan unos datos de indicación de tiempo TS_{1} en los paquetes IP a transmitir según un reloj CL del primer ordenador central justo antes de la transmisión, y unos datos de número de secuencia SEC_{1}. En el bloque 702, los paquetes IP se transmiten al segundo ordenador central 102 a través de la red IP 103. En el bloque 705, el segundo ordenador central 102 recibe los paquetes IP transmitidos por el primer ordenador central 101, en los que, en el bloque 706, se almacenan unos datos de indicación de tiempo TS_{2} según el reloj CL del sistema y unos datos de número de secuencia SEC_{2}. En el bloque 707, los datos de indicación de tiempo y de número de secuencia de los paquetes IP recibidos TS_{1}, SEC_{1}, TS_{2} y SEC_{2}, se copian en los paquetes IP que esperan a ser transmitidos en una memoria intermedia. En el bloque 708, se almacenan unos datos de indicación de tiempo TS_{3} en los paquetes IP a transmitir al primer ordenador central de acuerdo con el reloj CL del segundo ordenador central justo antes de la transmisión. En el bloque 709, se transmite los paquetes IP al primer ordenador central 101 a través de la red IP 103. En el bloque 703, el primer ordenador central recibe los paquetes IP transmitidos por el segundo ordenador central 102 en los que, en el bloque 704, se almacenan unos datos de indicación de tiempo TS_{4} según el reloj CL del primer ordenador central.
En la práctica, en la memoria MEM de los ordenadores centrales, existe un área de almacenamiento en la que la MCU almacena típicamente el contenido de cada paquete IP a transmitir (datos de indicación de tiempo y de número de secuencia). Así, en la transmisión de un paquete IP, es precisamente este contenido del área de almacenamiento el que se envía al extremo receptor. Con dicha expresión área de almacenamiento se da a entender, por ejemplo, la memoria intermedia del segundo ordenador central mencionada anteriormente, en la que los paquetes IP están esperando a ser transmitidos al primer ordenador central. En el extremo receptor, la MCU almacena los datos de los paquetes IP recibidos en su memoria MEM, en un archivo, para su análisis posterior, por ejemplo para calcular los parámetros QoS.
Así, las partes esenciales de la invención se pueden implementar de forma programable. Los productos de programa de ordenador en cuestión almacenados en las memorias MEM de los ordenadores centrales se pueden programar en un lenguaje de programación adecuado para este propósito, tal como el lenguaje de programación C.
Puesto que la invención proporciona medios para emular una llamada IP realista en un nivel de aplicación con señalización y flujos continuos de paquetes IP uniformes simétricos de una forma más precisa que la conocida a partir de soluciones según la técnica anterior, la invención permite la realización de las mediciones de la QoS de una llamada IP de forma más fiable que las soluciones conocidas. En la disposición según la invención, se está preparado también para las situaciones de error de una red IP, con lo cual con la disposición según la invención se pueden llevar a cabo también mediciones fiables de la QoS cuando se pierden paquetes IP de una llamada IP en el camino o cuando los mismos llegan al extremo receptor demasiado tarde.
Aunque anteriormente, en la descripción de la invención, se ha descrito una disposición la cual comprende dos ordenadores centrales y una red por paquetes entre ellos, también puede haber más ordenadores centrales. Así, desde un primer ordenador central se puede transmitir un flujo continuo de paquetes IP a dos o más ordenadores centrales, los cuales devolverán todos ellos los paquetes IP transmitidos por el primer ordenador central. Por ejemplo, de esta manera, es posible emular una llamada de grupo IP, la cual se realiza desde un terminal VoIP a dos o más terminales VoIP, y llevar a cabo las mediciones de la QoS. Además, según la invención, es posible emular más de una llamada IP de manera simultánea o no simultánea y llevar a cabo así las mediciones de la QoS usando varios pares diferentes de ordenadores centrales.
La presente descripción da a conocer la implementación y formas de realización de la presente invención, con la ayuda de ejemplos. Para un experto en la materia, resulta evidente que la presente invención no se limita a los detalles de las formas de realización presentadas anteriormente, y que la invención se puede implementar también de otra forma sin apartarse por ello de las características de la invención. Las formas de realización presentadas anteriormente se deberían considerar ilustrativas, aunque no limitativas. Así, las posibilidades de implementar y usar la invención quedan limitadas solamente por las reivindicaciones adjuntas. Por consiguiente, las diversas opciones de implementación de la invención según determinan las reivindicaciones, incluyendo las implementaciones equivalentes, pertenecen también al alcance de la invención.

Claims (18)

1. Método para emular el flujo de información bidireccional de una aplicación real en un sistema, el cual comprende un primer elemento de red (101) y un segundo elemento de red (102), así como una red por paquetes (103) entre dicho primer elemento de red y dicho segundo elemento de red, comprendiendo dicho método:
transmitir un conjunto de paquetes (300) desde el primer elemento de red a través de la red por paquetes al segundo elemento de red;
recibir por lo menos parte de los paquetes transmitidos en el segundo elemento de red;
transmitir los paquetes recibidos desde el segundo elemento de red a través de la red de paquetes de regreso al primer elemento de red en respuesta a la recepción de los paquetes en el segundo elemento de red, caracterizado porque el método comprende
transmitir un paquete que ha llegado al segundo elemento de red de regreso al primer elemento de red solamente después de un retardo con respecto a la recepción del paquete en el segundo elemento de red.
2. Método según la reivindicación 1, caracterizado porque el método comprende:
transmitir dicho conjunto de paquetes desde el primer elemento de red a través de la red por paquetes al segundo elemento de red como un flujo continuo uniforme de paquetes; y
en respuesta a la recepción de los paquetes en el segundo elemento de red, transmitir los paquetes recibidos al primer elemento de red como un flujo continuo uniforme de paquetes emulando una llamada IP, Protocolo de Internet, real en un nivel de aplicación para determinar la Calidad de Servicio, QoS.
3. Método según la reivindicación 1, caracterizado porque, en el método, los paquetes transmitidos son paquetes IP que se corresponden en tamaño con paquetes IP transmitidos en una llamada IP real.
4. Método según la reivindicación 1, caracterizado porque, en la transmisión de un paquete (300), se usa el UDP, Protocolo de Datagrama de Usuario, sobre IP.
5. Método según la reivindicación 1, caracterizado porque dichos elementos de red (101, 102) son ordenadores.
6. Método según la reivindicación 1, caracterizado porque el método comprende, para emular una llamada de grupo, la transmisión, desde el primer elemento de red a través de la red por paquetes, de un conjunto de paquetes hacia un conjunto de segundos elementos de red, los cuales, en respuesta a la recepción de los paquetes, devuelven los paquetes que han recibido de regreso al primer elemento de red.
7. Método según la reivindicación 1, caracterizado porque el método comprende el uso de más de un par de elementos de red, formado por el primer y el segundo elementos de red, para emular más de una llamada IP.
8. Método según la reivindicación 1, caracterizado porque el método comprende la emulación del establecimiento de llamada correspondiente a una llamada IP mediante la transmisión, antes de transmitir dicho conjunto de paquetes, de por lo menos un paquete desde el primer elemento de red a través de la red por paquetes al segundo elemento de red y mediante la devolución de dicho por lo menos un paquete de regreso al primer elemento de red inmediatamente después de que haya llegado a dicho segundo elemento de red.
9. Método según la reivindicación 8, caracterizado porque, en la transmisión de dicho por lo menos un paquete, se usa el TCP, Protocolo de Control de Transmisión, sobre IP.
10. Método según la reivindicación 1, caracterizado porque cuando el segundo elemento de red está a punto de devolver los paquetes que ha recibido del primer elemento de red en un caso en el que el segundo elemento de red no dispone del paquete a devolver, se transmite un paquete de relleno desde el segundo elemento de red al primer elemento de red para mantener un flujo continuo uniforme de paquetes.
11. Método según la reivindicación 1, caracterizado porque el método comprende la transmisión en primer lugar de dicho conjunto de paquetes desde el primer elemento de red a través de la red por paquetes al segundo elemento de red, después de lo cual se realiza una pausa de una duración específica (N_{sp}\Deltat_{ti}) en la transmisión de los paquetes, transmitiéndose después de dicha pausa un segundo conjunto de paquetes desde el primer elemento de red a través de la red por paquetes al segundo elemento de red para emular las secuencias habladas y los períodos de silencio de una llamada IP.
\newpage
12. Método según la reivindicación 1, caracterizado porque el método comprende:
almacenar en un paquete a transmitir desde el primer elemento de red, en relación con la transmisión del paquete, una primera información de tiempo (TS_{1}) y unos primeros datos de número de secuencia (SEC_{1});
almacenar en un paquete recibido en el segundo elemento de red, en relación con la recepción del paquete, una segunda información de tiempo (TS_{2}) y unos segundos datos de número de secuencia (SEC_{2});
almacenar en el segundo elemento de red en un paquete a devolver al primer elemento de red, en relación con la transmisión de devolución del paquete, una tercera información de tiempo (TS_{3});
almacenar en el primer elemento de red en un paquete devuelto al primer elemento de red, en relación con la recepción del paquete, una cuarta información de tiempo (TS_{4});
determinar, sobre la base de dicha información de tiempo (TS_{1} a TS_{4}) y dichos datos de número de secuencia (SEC_{1} a SEC_{4}), valores para un conjunto de parámetros que describen la Calidad de Servicio con vistas a determinar la Calidad de Servicio, QoS.
13. Sistema para emular el flujo de información bidireccional de una aplicación real, comprendiendo dicho sistema un primer elemento de red (101) y un segundo elemento de red (102), así como una red por paquetes (103) entre dicho primer elemento de red y dicho segundo elemento de red, comprendiendo dicho primer elemento de red (101):
unos medios (MCU, MEM, 701, 702, CL) para transmitir un conjunto de paquetes (300) desde el primer elemento de red (101) a través de la red por paquetes (103) al segundo elemento de red (102), y el segundo elemento de red comprende:
unos medios (MCU, MEM, 705, 706, CL) para recibir por lo menos parte de los paquetes transmitidos (300) en el segundo elemento de red (102);
unos medios (MCU, MEM, 707 a 709, CL) para transmitir los paquetes recibidos (300) desde el segundo elemento de red (102) a través de la red por paquetes (103) de regreso al primer elemento de red (101) en respuesta a la recepción de los paquetes en el segundo elemento de red, caracterizado porque el segundo elemento de red (102) comprende además:
unos medios (MCU, MEM, 707 a 709, CL) para transmitir un paquete (300) que ha llegado al segundo elemento de red (102) de regreso al primer elemento de red (101) solamente después de un retardo (\Deltat_{mem}) con respecto a la recepción del paquete en el segundo elemento de red.
14. Sistema según la reivindicación 13, caracterizado porque el sistema está dispuesto para emular el flujo de información bidireccional de una llamada IP con vistas a determinar la Calidad de Servicio, QoS.
15. Elemento de red (102) para emular el flujo de información bidireccional de una aplicación real en un sistema, el cual además de dicho elemento de red comprende un primer elemento de red específico (101) y una red por paquetes (103) entre el elemento de red (102) y dicho primer elemento de red (101), comprendiendo dicho elemento de red (102):
unos medios (MCU, MEM, 705, 706, CL) para recibir paquetes (300) transmitidos desde dicho primer elemento de red (101) a través de la red por paquetes (103);
unos medios (MCU, MEM, 707 a 709, CL) para transmitir los paquetes recibidos (300) a través de la red por paquetes de regreso al primer elemento de red (101) en respuesta a la recepción de los paquetes en el elemento de red (102), caracterizado porque el elemento de red (102) comprende además:
unos medios (MCU, MEM, 707 a 709, CL) para transmitir un paquete (300) que ha llegado al elemento de red (102) de regreso al primer elemento de red (101) solamente después de un retardo (\Deltat_{mem}) con respecto a la recepción del paquete en el elemento de red (102).
16. Elemento de red según la reivindicación 15, caracterizado porque el elemento de red (102) está dispuesto para emular el flujo de información de una llamada IP con vistas a determinar la Calidad de Servicio, QoS.
17. Producto de programa de ordenador ejecutable en un elemento de red (102) para emular el flujo de información de una aplicación real en un sistema, el cual además de dicho elemento de red comprende un primer elemento de red específico (101) y una red por paquetes (103) entre el elemento de red (102) y dicho primer elemento de red, comprendiendo dicho producto de programa de ordenador un código de programa:
para recibir en el elemento de red (102) paquetes (300) transmitidos desde dicho primer elemento de red (101) a través de la red por paquetes (103);
para transmitir los paquetes recibidos (300) a través de la red por paquetes (103) de regreso al primer elemento de red (101) en respuesta a la recepción de los paquetes en el elemento de red (102), caracterizado porque el producto de programa de ordenador comprende un código de programa:
para transmitir un paquete (300) que ha llegado al elemento de red (102) de regreso al primer elemento de red (101) solamente después de un retardo (\Deltat_{mem}) con respecto a la recepción del paquete en el elemento de red (102).
18. Producto de programa de ordenador según la reivindicación 17, caracterizado porque el producto de programa de ordenador está dispuesto para emular el flujo de información de una llamada IP con vistas a determinar la Calidad de Servicio, QoS.
ES01951195T 2000-02-14 2001-01-15 Emulacion de flujo de informacion. Expired - Lifetime ES2278760T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20000316 2000-02-14
FI20000316A FI20000316A (fi) 2000-02-14 2000-02-14 Informaatiovirran jäljittely

Publications (1)

Publication Number Publication Date
ES2278760T3 true ES2278760T3 (es) 2007-08-16

Family

ID=8557492

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01951195T Expired - Lifetime ES2278760T3 (es) 2000-02-14 2001-01-15 Emulacion de flujo de informacion.

Country Status (15)

Country Link
US (1) US7274714B2 (es)
EP (1) EP1256200B1 (es)
JP (1) JP2003523132A (es)
KR (1) KR100448280B1 (es)
CN (1) CN1240199C (es)
AT (1) ATE349827T1 (es)
AU (1) AU2853501A (es)
BR (1) BR0108329A (es)
CA (1) CA2399056A1 (es)
DE (1) DE60125512T2 (es)
ES (1) ES2278760T3 (es)
FI (1) FI20000316A (es)
MX (1) MXPA02007832A (es)
RU (1) RU2249305C2 (es)
WO (1) WO2001059981A1 (es)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2351175C (en) * 1998-11-24 2016-05-03 Niksun, Inc. Apparatus and method for collecting and analyzing communications data
FI20001578A (fi) 2000-06-30 2001-12-31 Nokia Networks Oy QoS-arkkitehtuuri
US8218555B2 (en) * 2001-04-24 2012-07-10 Nvidia Corporation Gigabit ethernet adapter
US20070253430A1 (en) * 2002-04-23 2007-11-01 Minami John S Gigabit Ethernet Adapter
US7437463B1 (en) * 2002-06-21 2008-10-14 Polycom, Inc. Method and means for providing scheduling for a videoconferencing network in a manner to ensure bandwidth
US8176545B1 (en) 2003-12-19 2012-05-08 Nvidia Corporation Integrated policy checking system and method
US8442506B2 (en) * 2004-07-23 2013-05-14 Gregory Peacock System and method for communications in a multi-platform environment
US8036123B1 (en) 2005-01-07 2011-10-11 Marvell International Ltd. Integrated circuit for network stress testing
US8054826B2 (en) * 2005-07-29 2011-11-08 Alcatel Lucent Controlling service quality of voice over Internet Protocol on a downlink channel in high-speed wireless data networks
US8797870B2 (en) * 2006-01-05 2014-08-05 Cisco Technology, Inc. Method and system for calculation of QOV metrics
US8472371B1 (en) 2007-02-21 2013-06-25 At&T Mobility Ii Llc Roaming support for wireless access subscriber over fixed IP access networks
CN101330700B (zh) * 2007-06-19 2012-02-29 中兴通讯股份有限公司 一种实现上行ip承载话音业务调度的方法
JP2010074227A (ja) * 2008-09-16 2010-04-02 Fuji Xerox Co Ltd 情報処理システム、通信制御装置及びプログラム
US8578020B2 (en) 2009-12-24 2013-11-05 Empire Technology Development Llc Dynamic mobile application quality-of-service monitoring and reporting
US9191696B2 (en) * 2012-06-15 2015-11-17 Samsung Electronics Co., Ltd. Reception device and program for reception device
US9602383B2 (en) 2012-10-11 2017-03-21 Telefonaktiebolaget Lm Ericsson (Publ) General packet radio service tunnel performance monitoring
US9338678B2 (en) * 2012-10-11 2016-05-10 Telefonaktiebolaget Lm Ericsson (Publ) Performance monitoring of control and provisioning of wireless access points (CAPWAP) control channels
CN103532931B (zh) * 2013-09-24 2017-01-25 北京星网锐捷网络技术有限公司 数据流传输性能的测试方法、服务器及测试系统
US9300565B2 (en) * 2014-04-17 2016-03-29 Accedian Networks Inc. System and method for out-of-line real-time in-service performance measurement
US11494101B2 (en) * 2020-10-14 2022-11-08 Western Digital Technologies, Inc. Storage system and method for time-duration-based efficient block management and memory access

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5450394A (en) * 1994-03-10 1995-09-12 Northern Telecom Limited Delay monitoring of telecommunication networks
WO1997003508A1 (fr) * 1995-07-13 1997-01-30 Sony Corporation Procede, appareil et systeme de transmission de donnees
EP0910194A2 (en) 1997-09-24 1999-04-21 At&T Wireless Services, Inc. Network test system
US6587985B1 (en) 1998-11-30 2003-07-01 Matsushita Electric Industrial Co., Ltd. Data transmission method, data transmission apparatus, data receiving apparatus, and packet data structure
EP1075129A1 (en) 1999-08-06 2001-02-07 BRITISH TELECOMMUNICATIONS public limited company Test method for computer telephony
US6577648B1 (en) * 1999-10-04 2003-06-10 Nokia Corporation Method and apparatus for determining VoIP QoS characteristics of a network using multiple streams of packets and synchronizing measurements of the streams
US6731649B1 (en) * 2000-07-26 2004-05-04 Rad Data Communication Ltd. TDM over IP (IP circuit emulation service)
US7016340B1 (en) * 2001-10-26 2006-03-21 General Bandwidth Inc. System and method for testing a voice gateway
US7010595B2 (en) * 2001-12-14 2006-03-07 D-Link Corp. Apparatus for multi-level loopback test in a community network system and method therefor

Also Published As

Publication number Publication date
KR100448280B1 (ko) 2004-09-10
RU2249305C2 (ru) 2005-03-27
FI20000316A0 (fi) 2000-02-14
CN1240199C (zh) 2006-02-01
RU2002124604A (ru) 2004-02-10
FI20000316A (fi) 2001-08-15
DE60125512D1 (de) 2007-02-08
US7274714B2 (en) 2007-09-25
KR20020077460A (ko) 2002-10-11
WO2001059981A1 (en) 2001-08-16
BR0108329A (pt) 2003-03-11
US20030108033A1 (en) 2003-06-12
MXPA02007832A (es) 2002-10-23
CA2399056A1 (en) 2001-08-16
AU2853501A (en) 2001-08-20
EP1256200B1 (en) 2006-12-27
DE60125512T2 (de) 2007-08-02
CN1401170A (zh) 2003-03-05
ATE349827T1 (de) 2007-01-15
JP2003523132A (ja) 2003-07-29
EP1256200A1 (en) 2002-11-13

Similar Documents

Publication Publication Date Title
ES2278760T3 (es) Emulacion de flujo de informacion.
ES2334559T3 (es) Control del retardo del flujo de medios para un nodo de red.
US20030026277A1 (en) Use of a circular buffer to assure in-order delivery of packets
US6868094B1 (en) Method and apparatus for measuring network data packet delay, jitter and loss
US7911963B2 (en) Empirical scheduling of network packets
CN101272290B (zh) Ip网络中路径拥塞状态的测量方法和测量装置
BRPI0610270A2 (pt) método de programação de distribuição de dados de pacotes recebidos em um nó de rede para aqueles objetivados de uma pluralidade de usuários em intervalos de serviço programados, e, nó de rede
JP2003087317A (ja) 音声パケット遅延揺らぎ吸収装置及び吸収方法
US20190014029A1 (en) Performance measurement in a packet-switched communication network
JP5022935B2 (ja) 品質計測システム、受信装置、品質計測方法及びプログラム
EP1618705A1 (en) Sytem and method for measuring data network quality
US20050174947A1 (en) Method and process for video over IP network management
CN103974295B (zh) 链路状态检测装置及其工作方法
US20050102391A1 (en) Method and apparatus providing an asymmetric ping procedure
ES2372230T3 (es) Transmisión de tramas de datos de usuario en tiempo real en paquetes.
JP2005033499A (ja) 音声ip端末の伝搬時間ゆらぎ吸収方法と装置
Kato et al. End-to-End delay distribution on the Internet
Yletyinen The quality of voice over ip
CN100539579C (zh) 局域网络传输控制方法
KR20060084720A (ko) 피티티 단말기의 음성 유디피 패킷 수신 방법
Muyambo De-Jitter Control Methods in Ad-Hoc Networks
Gu et al. Promote the Use of Explicit Delay Control.
Krauthoff Measurement of Position-based Network-Characteristics in Cellular Networks while Moving
KR100926425B1 (ko) 위치 정보를 이용한 데이터 프레임 전송 방법 및 그 노드
Knezevic et al. ANALYSIS OF SOME QUALITY OF SERVICE PARAMETERS'IMPACT ON END-TO-END DELAY MEASUREMENTS IN VOIP NETWORK