ES2360668T3 - Control de admisión de llamadas. - Google Patents

Abstract

Procedimiento de control de admisión de llamadas para un flujo de datos continuo en redes conmutadas por paquetes que incluye al menos dos redes de área local que se comunican entre sí a través de una red de conexión, comprendiendo el procedimiento las etapas de: a) transmitir una ráfaga de datos de prueba desde un primer nodo en una primera red de área local a través de la red de conexión a un segundo nodo en una segunda red de área local a una tasa de transmisión de datos más alta que los paquetes que van a transmitirse en el flujo de datos continuo, incluyendo seleccionar un trayecto a través de la red de conexión, determinándose el trayecto por la red de conexión; b) reflejar la ráfaga de datos de prueba recibida en el segundo nodo de vuelta al primer nodo; c) recibir la ráfaga reflejada de datos de prueba en el primer nodo a través de la red de conexión; y d) comparar la ráfaga reflejada de datos de prueba con la ráfaga transmitida de datos de prueba para determinar si puede iniciarse la transmisión de un flujo de datos continuo desde el primer nodo en la primera red de área local al segundo nodo en la segunda red de área local.

Description

La presente invención se refiere a mejoras en o en relación con el control de llamadas y más particularmente, aunque no exclusivamente, se refiere a la admisión de llamadas.

En la telefonía tradicional, es decir, la telefonía por conmutación de circuitos, para establecer una llamada entre dos teléfonos remotos, es decir, teléfonos conectados a diferentes centrales locales, se usa señalización para establecer un trayecto antes de establecer la propia llamada. El trayecto en el ejemplo anterior comprende el teléfono que inicia la llamada a su central local, la central local que inicia la llamada a una conexión troncal, la conexión troncal a la central local que recibe la llamada, y la central local que recibe la llamada al teléfono que recibe la llamada. En este caso, la señalización y la llamada toman habitualmente el mismo trayecto y existe un control completo del trayecto a través de cada elemento en el trayecto. Como existe un control completo, es relativamente sencillo determinar si puede establecerse o no una llamada entre dos teléfonos.

En la telefonía convencional sobre protocolo (P) de Internet, las centrales locales se sustituyen por “controladores de acceso” locales que se comunican con uno o más controladores de acceso troncales para establecer el trayecto entre el teléfono que inicia la llamada y el teléfono que recibe la llamada. En este caso, la señalización se realiza a través del (de los) controlador(es) de acceso troncal(es) pero la llamada no toma el mismo trayecto. En este caso, el (los) controlador(es) de acceso troncal(es) controla(n) el ancho de banda que puede usarse al establecer la llamada, y si el ancho de banda no es suficiente, la llamada no se establece.

Con la llegada de la telefonía IP troncal opaca, no existe ningún controlador de acceso en la red IP que forme el “tronco”. Como resultado, efectivamente no existe ningún control sobre poder establecer una llamada con éxito. En este caso, el teléfono que inicia la llamada no puede garantizar que una llamada, una vez establecida, se complete con éxito.

Un documento conocido, “Performance Evaluation of a New End-to-end Measurement Based Call Admission Control Scheme for Supporting IP Telephony” en PROCEEDINGS OF THE SYMPOSIUM OF PERFORMANCE EVALUATION OF COMPUTER AND TELECOMMUNICATION SYSTEMS, XX, XX, 15 de julio de 2001 páginas 498505, XP009020891, da a conocer una pasarela de recepción, situada dentro de una red, que puede identificar la pasarela a partir de la que se envió cada trama/paquete y la llamada a la que pertenece cada trama/paquete. La pasarela comprueba el número de secuencia de cada trama para calcular si se ha perdido algún paquete o trama anterior, actualizando un contador de pérdida de paquetes de manera correspondiente. Al final de cada periodo de medición predeterminado, se envía un paquete de control a cada pasarela de envío para informar a los emisores acerca de la estadística de pérdidas de sus llamadas. A partir de la estadística notificada a la pasarela de recepción en el (los) paquete(s) de control, la pasarela de envío puede determinar si rechazar o aceptar cualquier nueva llamada para un destino.

Otro documento conocido, la solicitud de patente europea n.º EP 0 932 282 A, da a conocer un aparato de control de admisión que tiene una cola de petición de conexión. Todas las peticiones de conexión nuevas se almacenan en esta cola de petición de conexión, que funciona con un método de primero en entrar primero en salir a menos que se invoque el control de admisión. El control de admisión detecta cualquier reenvío de paquetes debido a la pérdida o descarte de paquetes. El control de admisión proporciona un patrón de estas pérdidas o descartes de paquetes, denominado característica de pérdida de paquetes, para identificar cualquier patrón. Si se cumplen determinados criterios, o la característica de pérdida de paquetes corresponde con el patrón predeterminado, se invoca el control de admisión y cualquier petición de conexión nueva en la cola se retardará o descartará, o se descartarán las conexiones existentes, hasta que se resuelva la condición.

Por tanto es un objetivo de la presente invención proporcionar un procedimiento de control de admisión de llamada que supere las desventajas anteriormente descritas.

Según un aspecto de la presente invención, se proporciona un procedimiento de control de admisión de llamadas para un flujo de datos continuo en redes conmutadas por paquetes que incluyen al menos dos redes de área local que se comunican entre sí a través de una red de conexión, comprendiendo el procedimiento las etapas de:

a) transmitir una ráfaga de datos de prueba desde un primer nodo en una primera red de área local a través de la red de conexión a un segundo nodo en una segunda red de área local a una tasa de transmisión de datos más alta que los paquetes que van a transmitirse en el flujo de datos continuo, incluyendo seleccionar un trayecto a través de la red de conexión, determinándose el trayecto por la red de conexión;

b) reflejar la ráfaga de datos de prueba recibida en el segundo nodo de vuelta al primer nodo;

c) recibir la ráfaga reflejada de datos de prueba en el segundo nodo a través de la red de conexión; y

d) comparar la ráfaga reflejada de datos de prueba con la ráfaga transmitida de datos de prueba para determinar si puede iniciarse la transmisión de un flujo de datos continuo desde el primer nodo en la primera red de área local al nodo de recepción en la segunda red de área local.

Preferiblemente, la ráfaga de datos de prueba tiene el mismo tamaño que los paquetes que van a transmitirse en el flujo de datos continuo.

En una realización de la presente invención, la etapa d) incluye comparar el número de paquetes en la ráfaga transmitida de datos de prueba y la ráfaga reflejada de datos de prueba, y calcular una estimación de tasa de pérdida de paquetes del trayecto.

En esta realización, las ráfagas múltiples de datos de prueba pueden transmitirse para mejorar la estimación.

El procedimiento comprende además la etapa de:

e) determinar si puede iniciarse la transmisión de un flujo de datos continuo, basándose en una tasa de pérdida de paquetes aceptable para la transmisión del flujo de datos continuo.

Si la tasa de pérdida de paquetes no es aceptable, la etapa e) puede incluir cambiar la prioridad de la transmisión del flujo de datos continuo y repetir las etapas a) a d) anteriores con la prioridad cambiada. Alternativamente, la etapa e) puede incluir no iniciar la transmisión del flujo de datos continuo.

La etapa e) puede llevarse a cabo mediante el primer nodo, mediante otro nodo en la primera red o mediante un operador humano.

Para un mejor entendimiento de la presente invención, ahora se hará referencia, solamente a modo de ejemplo, a los dibujos adjuntos en los que:

la figura 1 ilustra una red de telefonía convencional conmutada por circuitos;

la figura 2 ilustra una red de telefonía convencional IP; y

la figura 3 ilustra una telefonía IP troncal opaca según la presente invención.

En referencia inicialmente a la figura 1, hay una pluralidad de teléfonos 100, 200, 300 conectados a centrales 120, 220, 320 telefónicas locales respectivas mediante las líneas 140, 240, 340 respectivas. Si va a realizarse una llamada entre el teléfono 100 y el teléfono 200, debe encaminarse la llamada a través de la central 120, la conexión 400 troncal y la central 220. En este caso, la conexión 400 troncal incluye una central 420 troncal que determina si puede establecerse la llamada.

De manera similar, si va a realizarse una llamada entre el teléfono 100 y el teléfono 300, se encamina desde el teléfono 100 a través de la central 120, una conexión troncal (no mostrada) entre la central 120 y la central 320, y la central 320 al teléfono 300.

Evidentemente, cada central 120, 220, 320 tiene más de un teléfono 100, 200, 300 conectado a ésta y se proporcionan otras conexiones troncales entre pares de centrales 120, 220, 320.

Ahora en referencia a la figura 2, se muestran dos redes 10, 20 que están conectadas entre sí a través de una red 30 de conexión. La red 10 incluye una pluralidad de teléfonos 12, 14, 16 y un controlador 18 de acceso y la red 20 incluye una pluralidad de teléfonos 22, 24, 26 y un controlador 28 de acceso. Los controladores 18, 28 de acceso se conocen como controladores de acceso “locales” y cada controlador 18, 28 de acceso controla las llamadas realizadas dentro y fuera de su red 10, 20 asociada.

Aunque se muestran tres teléfonos en cada red, se apreciará que el número de teléfonos en cada red puede ser cualquier número adecuado según la aplicación de la red. También se apreciará que una red puede tener un número diferente de teléfonos respecto a la otra red.

Tal como se muestra, la red 30 de conexión también incluye un controlador 32 de acceso para controlar las llamadas encaminadas a través de la red 30. El controlador 32 de acceso se conoce como controlador de acceso “troncal”.

Se entenderá que si el teléfono 12 en la red 10 desea realizar una llamada al teléfono 22 en la red 20, tal como se indica mediante la flecha 40 discontinua, se encamina la llamada desde el teléfono 12 al controlador 18 de acceso para un encaminamiento hacia delante a través de la red 30 de conexión. En la red 30 de conexión, la llamada se encamina a través del controlador 32 de acceso y luego al controlador 28 de acceso en la red 20 antes de encaminarse al teléfono 22. En cada controlador 18, 32, 28 de acceso, existe la posibilidad de que se corte la llamada si el ancho de banda del controlador de acceso respectivo no es suficiente en el momento que va a realizarse la llamada.

En la figura 3, se muestran dos redes 50, 60 que están conectadas entre sí a través de una red 70 de conexión. Sin embargo, se apreciará que más de dos redes pueden estar conectadas a la red 70 de conexión, y sólo se muestran dos redes 50, 60 para una descripción más clara y sencilla.

Cada red 50, 60 incluye una pluralidad de teléfonos (aunque por motivos de claridad sólo se muestran dos teléfonos 52, 54 y 62, 64). Cada red 50, 60 también incluye un controlador 56, 66 de acceso respectivo. Se apreciará que las redes 50, 60 son similares a las redes 10, 20 de la figura 2.

La red 70 de conexión incluye una pluralidad de nodos 72, 74, 76, 78, 80 de encaminamiento para encaminar las llamadas dentro de la red 70 de una red 50, 60 a otra. Cada par de nodos 72, 74, 76, 78, 80 está conectado entre sí mediante un enlace o conexión. Cabe indicar que no todos los nodos necesitan conectarse a cada otro nodo.

En la realización ilustrada en la figura 3, el nodo 72 está conectado de manera eficaz a la red 50 y el nodo 80 está conectado de manera eficaz a la red 60. El nodo 72 también está conectado a los nodos 74, 76 y 78 y el nodo 80 también está conectado a los nodos 74, 76 y 78. No hay conexión directa entre los nodos 72 y 80 en la red 70 de conexión.

Si debe realizarse una llamada desde el teléfono 54 en la red 50 al teléfono 62 en la red 60, se encamina a través del controlador 56 de acceso al nodo 72 en la red 70 de conexión. Como no hay conexión directa entre el nodo 72 y el nodo 80, puede encaminarse la llamada al nodo 80 de una de varias maneras. Por ejemplo, las rutas pueden realizarse a través de los siguientes nodos:

•

a través del nodo 74 - enlaces 82 y 84

•

a través del nodo 76 - enlaces 86 y 88

•

a través del nodo 78 - enlaces 90 y 92

•

a través de los nodos 74 y 76 - enlaces 82, 94 y 88 (o enlaces 86, 94 y 84 en la otra dirección)

•

a través de los nodos 74 y 78 - enlaces 82, 96 y 92

•

a través de los nodos 76 y 78 - enlaces 86, 98 y 92 (o enlaces 90, 98 y 88 en la otra dirección)

• a través de los nodos 74, 76 y 78 - enlaces 82, 94, 98 y 92 (u otras combinaciones de los mismos enlaces dependientes de la dirección)

Se apreciará que, para cada nodo a través del que va a encaminarse una llamada, existe la posibilidad de que se pierdan los paquetes desde el flujo de datos continuo que comprende una llamada dependiendo del ancho de banda disponible en el enlace entre cada par de nodos.

En la figura 3, las redes 50, 60 comprenden redes “locales” que están controladas por el controlador 56, 66 de acceso respectivo. En este caso, la red 70 de conexión no incluye un controlador de acceso de la misma manera que la figura 2. En efecto, la disponibilidad del ancho de banda en la red 70 de conexión es opaca para ambas redes 50, 60 locales y puede considerarse una conexión “troncal” opaca.

Aunque la presente invención se ha descrito con referencia a llamadas que se realizan de un teléfono a otro, se apreciará que la presente invención puede aplicarse igualmente a otros tipos de tráfico. Tal tráfico, por ejemplo, transmisiones y comunicaciones, incluye transmisiones de gestión y señalización (con limitación de tasa de transmisión), transmisiones de vídeo y transmisiones de datos. El tráfico puede transmitirse en forma de paquetes de protocolo de Internet (IP). El tráfico puede comprender flujos de datos continuos y puede tener limitación de tasa de transmisión. Cada paquete puede estar codificado para una transmisión segura según una codificación de paquetes adecuada. La codificación se lleva a cabo en la red local mediante el nodo de transmisión u otro nodo y/u otro elemento (no mostrado) ubicado dentro de esa red.

Se apreciará fácilmente que es posible priorizar el tráfico dentro de una red IP de modo que determinados tipos de tráfico tengan prioridades particulares. También se apreciará que puede modificarse la prioridad según se requiera.

El problema de la congestión sólo se produce cuando el ancho de banda es insuficiente para un tipo particular de tráfico, ya sea porque la capacidad de enlace esté ocupada por tráfico de una prioridad mayor, o porque un enlace físicamente no tenga el ancho de banda requerido. Los nodos o transmisores independientes deben detectar la congestión y reaccionar de manera individual a ésta para reducir la carga presentada a la red y evitar un “colapso por congestión”.

La congestión puede producirse de dos maneras:

1.

Un transmisor o nodo particular puede iniciarse, añadiendo carga adicional a una red de funcionamiento de manera adecuada.

2.

El ancho de banda disponible en la red puede cambiar, ya sea porque se le dé preferencia al tráfico de prioridad mayor o por un cambio de encaminamiento en la red, de modo que ahora el tráfico se lleve por un enlace de capacidad menor.

En cada caso, el transmisor o nodo debe implementar un esquema de evitación de congestión para permitir una transición satisfactoria del mayor tráfico posible a ese nivel de prioridad por la red.

La mayor parte del tráfico de datos se transmitirá usando el protocolo de control de transmisión (TCP) que tiene un comportamiento frente a la congestión extremadamente robusto. El TCP permite una transferencia fiable de datos si no hay restricciones de tiempo puesto que asigna el ancho de banda disponible de la manera más equitativa posible. El TCP usa un “comienzo lento” (comienzo lento de TCP) para evitar aplicar una carga adicional repentina a la red cuando un transmisor o nodo se inicia primero y aún no sabe qué es una tasa de transmisión apropiada. Se usan acuses de recibo de datos como mecanismo de retroalimentación mediante el que el transmisor o nodo mantiene la tasa de transmisión apropiada en el estado estable. Un transmisor o nodo intenta gradualmente transmitir cada vez más rápido, pero cuando se detecta una congestión retrocede rápidamente (conocido como retroceso de TCP (TCP-backoff)). El resultado es que los transmisores o nodos TCP pueden mantener una carga total en una red muy cercana a la capacidad, pero cuando el ancho de banda de red disponible cambia repentinamente se adaptan al mismo muy rápidamente.

Los mecanismos de gestión de congestión de robustez similar deben usarse por tanto también para transmisiones de voz, para evitar un colapso por congestión en un nivel de prioridad particular usado para la transmisión de flujos de datos continuos. Para ello, pueden implementarse tres mecanismos ya sea en el teléfono en la red local o por el controlador de acceso asociado con la red local. En los mecanismos a continuación, las llamadas son transmisiones de flujos de datos continuos en una red conmutada por paquetes.

El primer mecanismo requiere que los teléfonos que han establecido una llamada y están en la banda telefónica (transmitiendo) examinen el historial reciente de los paquetes de voz del teléfono al que están conectados. Es muy duro para un abonado oír una tasa de pérdida de paquetes del 10%, de modo que existe un margen considerable de pérdida de paquetes detectable antes de que la llamada aparezca degradada ante un abonado. La decisión de cuándo cortar una llamada se basa en la tasa de pérdida y el tiempo durante el que se ha producido la pérdida. En este caso, como la congestión puede detectarse antes por un teléfono que por su abonado, es posible insertar un anuncio grabado de que la llamada se cortará debido a una congestión de la red y permitir un periodo de gracia de algunos segundos antes de interrumpir la llamada. Esto ocurre mientras que la llamada tiene una calidad aceptable. Puesto que la razón principal para una congestión de este tipo serán las llamadas con una prioridad mayor, un mecanismo de este tipo será altamente aceptable para los usuarios. Desde un punto de vista de los factores humanos, también es probable que los usuarios con llamadas menos importantes o llamadas que sólo han comenzado recientemente elijan interrumpirlas por sí mismos en caso de haber una degradación perceptible de la llamada. Este mecanismo es equivalente al retroceso de TCP anteriormente descrito.

En este mecanismo, cuando se toma la decisión de cortar una llamada, esta información se retransmite al controlador de acceso para una medición estadística. Esto permite proporcionar al teléfono una estimación de si una llamada será satisfactoria cuando intente establecer una llamada.

El segundo mecanismo requiere que los teléfonos que están estableciendo una llamada envíen una ráfaga de prueba de paquetes “de verificación de conexión” al teléfono al que están intentando llamar antes de enviar el mensaje de señalización que hará que suene el otro teléfono. Esta “sonda de ancho de banda” puede usar cuatro o cinco paquetes de verificación de conexión del mismo tamaño y prioridad que los paquetes de voz que se usarán cuando la llamada esté en la banda telefónica pero menos espaciados en el tiempo. Esto hace que un enlace tenga brevemente una sobrecarga al enviar un impulso de corta duración pero ancho de banda elevado. El efecto de estas verificaciones de conexión sobre las llamadas de voz establecidas será pequeño, pero si un enlace está próximo a la congestión algunos de estos paquetes o bien sufrirán cada vez más retardos o bien se perderán en conjunto. Analizando los paquetes devueltos, el teléfono puede decidir cómo de cerca a la congestión está el trayecto al otro teléfono y por consiguiente la probabilidad de que la llamada tenga una calidad aceptable si se establece. El número y espaciamiento óptimo de estas verificaciones de conexión pueden elegirse según los requerimientos de una red o sistema particular. También puede determinarse un algoritmo adecuado para asignar una probabilidad de éxito de llamada basándose en la llegada y el tiempo de los paquetes devueltos. Entonces, basándose en esta probabilidad estimada el teléfono tomará una decisión aleatoria de si continuar con la llamada o interrumpirla. Si se decide interrumpir la llamada, al abonado se le puede presentar un mensaje informando de que el trayecto de red a ese destino estaba congestionado y de que debe intentarlo de nuevo más tarde. Este mecanismo de admisión de llamadas es más prudente que el primer mecanismo de modo que las llamadas existentes siguen haciendo frente a una ligera congestión pero no se admiten nuevas llamadas. Este mecanismo es equivalente al comienzo lento de TCP anteriormente descrito.

En este mecanismo, la decisión de o bien interrumpir una llamada o bien continuar con la llamada se basa en una tasa de pérdida de paquetes aceptable para la transmisión particular del flujo de datos continuo. Es posible cambiar la prioridad de la llamada a una prioridad mayor si la tasa de pérdida de paquetes no es aceptable. Este cambio en la prioridad tiende a aumentar la tasa de éxito de la llamada que se establece.

La decisión puede tomarse por el teléfono que inicia la llamada, por otro teléfono o elemento en la misma red local que el teléfono que inicia la llamada, o por un operador humano.

El tercer mecanismo requiere que un controlador de acceso al que se le pide que establezca una llamada decida si permitir incluso el uso de la ráfaga de prueba inicial. En enlaces muy congestionados en los que la carga de llamada ofrecida es mucho mayor que la capacidad actual, la suma de las cargas transitorias pequeñas a partir de las ráfagas iniciales de muchos intentos de llamada será lo suficientemente alta para hacer que las llamadas actuales en la banda telefónica se vean afectadas negativamente e incluso se corten. Sin embargo, usando la estadística acerca del éxito o fallo (y las tasas de pérdida actuales) de llamadas a teléfonos controladas por otros controladores de acceso, el controlador de acceso para un teléfono que llama puede formar una estimación de probabilidad de pérdida para esta nueva llamada. Basándose en esta probabilidad de pérdida, el controlador de acceso puede tomar una decisión aleatoria de si permitir incluso la ráfaga de prueba inicial de una llamada, o de si detenerla inmediatamente. Este mecanismo no tiene equivalente en TCP pero es muy similar al “espaciamiento de llamadas” usado en redes telefónicas públicas. El “espaciamiento de llamadas” funciona para reducir la congestión cortando intentos de llamada muy cerca de un abonado que llama cuando se detectan sobrecargas concentradas. Una sobrecarga concentrada se produce cuando muchas personas intentan llamar a un número de teléfono particular al mismo tiempo. Cuando se corta un intento de llamada, se le presenta al que llama un tono de ocupado.

Se apreciará que, aunque se haya descrito cada uno de los tres mecanismos como funcionando independientemente, es posible que los tres funcionen en la misma llamada. Por ejemplo, el primer mecanismo indica que una llamada puede continuarse basándose en un historial de llamadas recientes del teléfono al que se llama, el tercer mecanismo determina si puede transmitirse la ráfaga de prueba de paquetes de verificación de conexión, y el segundo mecanismo determina la tasa de pérdida de paquetes para el trayecto elegido por la red de conexión entre las redes locales que contienen el teléfono que llama y el teléfono al que se llama.

Usando los primeros dos mecanismos, las llamadas de voz en una red de algunos miles de abonados deben manejarse de manera apropiada bajo casi todas las condiciones de congestión. Las razones para la interrupción de una llamada serán evidentes para los usuarios de modo que habrá poca frustración por parte del usuario o una rellamada falsa.

Cuando también se use el tercer mecanismo, el manejo de la congestión será extremadamente robusto e incluso las sobrecargas concentradas en enlaces congestionados de ancho de banda reducido también se resistirán bien.

Claims (9)

1. REIVINDICACIONES

   1. Procedimiento de control de admisión de llamadas para un flujo de datos continuo en redes conmutadas por paquetes que incluye al menos dos redes de área local que se comunican entre sí a través de una red de conexión, comprendiendo el procedimiento las etapas de:

   a) transmitir una ráfaga de datos de prueba desde un primer nodo en una primera red de área local a través de la red de conexión a un segundo nodo en una segunda red de área local a una tasa de transmisión de datos más alta que los paquetes que van a transmitirse en el flujo de datos continuo, incluyendo seleccionar un trayecto a través de la red de conexión, determinándose el trayecto por la red de conexión;

   b) reflejar la ráfaga de datos de prueba recibida en el segundo nodo de vuelta al primer nodo;

   c) recibir la ráfaga reflejada de datos de prueba en el primer nodo a través de la red de conexión; y

   d) comparar la ráfaga reflejada de datos de prueba con la ráfaga transmitida de datos de prueba para determinar si puede iniciarse la transmisión de un flujo de datos continuo desde el primer nodo en la primera red de área local al segundo nodo en la segunda red de área local.

2. 2.

   Procedimiento según la reivindicación 1, en el que la ráfaga de datos de prueba tiene el mismo tamaño que los paquetes que van a transmitirse en el flujo de datos continuo.

3. 3.

   Procedimiento según la reivindicación 1 ó 2, en el que la etapa d) incluye comparar el número de paquetes en la ráfaga transmitida de datos de prueba y la ráfaga reflejada de datos de prueba, y calcular una estimación de tasa de pérdida de paquetes del trayecto.

4. 4.

   Procedimiento según la reivindicación 3, en el que las múltiples ráfagas de datos de prueba se transmiten para mejorar la estimación.

5. 5.

   Procedimiento según una cualquiera de las reivindicaciones anteriores, que comprende además:

   e) determinar si puede iniciarse la transmisión de un flujo de datos continuo, basándose en una tasa de pérdida de paquetes aceptable para la transmisión del flujo de datos continuo.

6. 6.

   Procedimiento según una cualquiera de las reivindicaciones anteriores, en el que la tasa de pérdida de paquetes no es aceptable, comprendiendo además el procedimiento cambiar la prioridad de la transmisión del flujo de datos continuo y repetir las etapas a) a d) con la prioridad cambiada.

7. 7.

   Procedimiento según cualquiera de las reivindicaciones 5 ó 6, en el que la tasa de pérdida de paquetes no es aceptable y la etapa e) incluye no iniciar la transmisión del flujo de datos continuo.

8. 8.

   Procedimiento según una cualquiera de las reivindicaciones anteriores, en el que se envía una ráfaga transmitida de datos de prueba por un teléfono que establece una llamada.

9. 9.

   Procedimiento según la reivindicación 8, en el que la ráfaga transmitida de datos de prueba se envía por un teléfono que establece una llamada al teléfono al que intenta llamar.