ES2711792T3 - Método y dispositivo para configurar dinámicamente FEC o ARQ como protección de ruido de impulso en una línea de comunicación - Google Patents

Abstract

Un método para configurar protección de ruido de impulso, INP, en una línea de comunicación (203) en una capa física, PHY, que comprende las siguientes etapas: - configurar (100) dicha PHY para usar un modo de RTC usando retransmisiones para INP; - monitorizar (101, 401) un rendimiento en dicho modo de RTX; - reconfigurar (103) dicha PHY para usar un modo de IFEC usando corrección de errores hacia delante e intercalación para INP si (102) dicho rendimiento en dicho modo de RTX está por debajo de un cierto umbral; - monitorizar (104, 404) un rendimiento en dicho modo de IFEC; - reconfigurar dicha PHY de vuelta a dicho modo de RTX si (105, 405) dicho rendimiento en dicho modo de IFEC está por debajo de dicho rendimiento en dicho modo de RTX caracterizado adicionalmente por que: - dicho rendimiento en dicho modo de RTX está relacionado con un primer tiempo medio entre errores de transmisión, primer MTBE (401); y en el que dicha reconfiguración de dicha PHY para usar dicho modo de IFEC se realiza únicamente cuando (410) dicho primer MTBE está por debajo de un MTBE umbral predeterminado; dicho rendimiento en dicho modo de IFEC está relacionado con un segundo MTBE (404); y en donde dicha reconfiguración de dicha PHY de vuelta a dicho modo de RTX se realiza cuando (405) dicho segundo MTBE en dicho modo de IFEC está por debajo de dicho primer MTBE.

Description

DESCRIPCION

Metodo y dispositivo para configurar dinamicamente FEC o ARQ como proteccion de ruido de impulso en una ilnea de comunicacion

Campo de la invencion

La presente invencion se refiere en general a la configuracion automatica de llneas de comunicacion tales como llneas digitales de abonados, DSL. En el campo de DSL, esta configuracion y optimizacion automatica de llneas de comunicacion tambien se conoce como Gestion de Llnea Dinamica, DLM. Normalmente, DLM se realiza de manera central en el lado del operador de red evaluando las caracterlsticas de rendimiento de la capa flsica, PHY desde transceptores conectados a las llneas de comunicacion. Basandose en esta evaluacion, la llnea de comunicacion se reconfigura entonces actualizando los parametros relacionados con la PHY de los transceptores.

Mas particularmente la invencion se refiere a la configuracion de la tecnica de correccion de errores aplicada en la capa flsica, PHY, para mitigar ruido de impulso captado por las llneas de comunicacion. Una tecnica de correccion de errores esta basada en la correccion de errores hacia adelante combinada con intercalacion, IFEC, y otra tecnica esta basada en la retransmision de paquetes de datos de PHY o unidades de transmision de datos, abreviado DTU. Cuando la PHY esta configurada para usar correccion de errores basada en IFEC se denomina como que esta en modo de IFEC y cuando esta configurada para usar retransmisiones para correccion de errores se denomina como que esta en modo de RTX.

Antecedentes de la invencion

Las tecnicas de llnea digital de abonado, DSL, permiten conectar usuarios finales a la Internet o cualquier otra red de datos a traves de llneas de comunicacion de par trenzado tradicionales. Normalmente, las llneas de comunicacion marchan desde las instalaciones del usuario a un Multiplexor de Acceso de Llnea Digital de Abonado, DSLAM, donde se determina una agrupacion de llneas de comunicacion. El DSLAM se conecta adicionalmente a continuacion a una parte troncal, por ejemplo a traves de un enlace de fibra o enlace de Ethernet de alta velocidad. Las llneas DSL son susceptibles a degradacion de ruido de las senales de comunicacion en la llnea dando como resultado un caudal de datos neto inferior factible a traves de la llnea de DSL. Se consideran dos tipos de ruido, ruido estacionario y ruido de impulso.

El ruido estacionario toma la forma de un fondo de ruido constante o que varla lentamente y se provoca principalmente por diafonla captada de llneas vecinas desde la agrupacion. La consecuencia de ruido estacionario es que limita la tasa a la que una llnea puede sincronizar. Se han desarrollado tecnicas tales como vectorizacion para mitigar el impacto de ruido estacionario y aumentar la tasa de datos conseguida.

El ruido de impulso o IN por otra parte consiste en rafagas cortas de ruido que tienen una duracion relativamente corta pero una alta amplitud que da como resultado una perdida total de la senal de comunicacion real. Estas rafagas de ruido pueden tener lugar ya sea aleatoriamente en tiempo como un SHINE, Evento de Ruido de Alto Impulso Unico, o ser repetitivas y seguir un patron regular como REIN, Ruido de Impulso Repetitivo. Una fuente tlpica de SHINE es el encendido o apagado de electrodomesticos en las cercanlas de un modem. REIN por otra parte se provoca normalmente por interferencia electrica desde un dispositivo electrico en funcionamiento. La frecuencia de aparicion entonces corresponde a un multiplo de la frecuencia de operacion de la red de electricidad, por ejemplo 50 Hz o 60 Hz. La perdida de datos provocada por el ruido de impulso puede mitigarse por mecanismos de proteccion de ruido de impulso, INP.

Un primer mecanismo de INP es usar una combinacion de correccion de errores hacia adelante, FEC, e intercalacion indicada como proteccion de ruido de impulso de IFEC. En DSL, la IFEC se implementa normalmente por un codificador Reed-Solomon (RS) y un intercalador de datos que extiende la rafaga de errores desde el ruido de impulso a traves de varias palabras de codigo del codificador de RS. Sin embargo, una desventaja de los mecanismos de IFEC es que este tipo de INP esta consumiendo ancho de banda de manera constante ya que se introduce redundancia a todos los datos incluso cuando no esta presente ruido de impulso.

Un segundo mecanismo de INP esta basado en retransmisiones de datos que estaban corruptos por ruido de impulso. Estas retransmisiones se encuentran en la capa flsica o PHY donde se retransmite una Unidad de Transmision de Datos, DTU, cuando estan corruptas. Una implementacion para esta tecnica para proveedores de servicio de DSL se describe bajo la norma ITU-T G.998.4 y tambien se denomina como G.INP, RTX, o ARQ (Consulta de Repeticion Automatica).

Una de las grandes ventajas de RTX frente a IFEC radica en el hecho de que la sobrecarga de tasa de bits necesaria para retransmision de datos se usa unicamente cuando es necesario, es decir unicamente cuando es necesaria una retransmision de datos. Como resultado, cuando hay poco ruido de impulso y, por lo tanto, no se requieren retransmisiones, no se introduce sobrecarga y la tasa de datos neta completa esta disponible para trafico de usuario.

Ya que RTX unicamente consume ancho de banda cuando es necesario, es el mecanismo de INP ideal en la mayorla de los casos. Sin embargo, en algunos entornos de ruido especlficos, RTX no funciona muy bien ya que no puede corregir todos los errores de transmision mientras aun esta consumiendo una gran cantidad de ancho de banda. Ademas, en algunos de estos casos, IFEC puede ser mucho mas eficaz y exitoso al corregir la mayorla o todos los errores mientras consume menos ancho de banda que RTX.

La publication US2003126238A1 desvela un sistema de comunicaciones de datos para cambiar dinamicamente el procesamiento de errores entre una funcion de ARQ y una funcion de FEC de acuerdo con el estado de red, posibilitando de esta manera reproduction de datos de alta calidad. En transmision de paquetes, se realiza control de correction de errores basandose en el estado de la red monitorizado por una unidad de monitorizacion de red. El modo de control de error se conmuta entre control de error basado en FEC y control de error basado en ARQ de acuerdo con la tasa de error y/o retardo de transmision, y se realiza transmision de paquetes. Si el retardo de transmision es corto, se selecciona correccion de errores basada en ARQ. Si el retardo de transmision es largo, se selecciona correccion de error no basada en ARQ, sino en FEC. Puede conseguirse tal control de correccion de error dinamico.

La publicacion EP1507369A1 desvela un metodo de procesamiento de information que permite que sea conocido el estado de red bidireccional. Una unidad de analisis de paquetes de RTCP analiza un paquete de RTCP en un informe de receptor RR recibido a traves de un puerto de RTCP desde un terminal de usuario a traves de una red. Basandose en un numero de secuencia de RTCP obtenido desde el paquete de RTCP analizado, una unidad de detection de perdida de paquetes calcula una tasa de perdida de paquetes con respecto al terminal de usuario en la red. Una unidad de creation de paquete de RTCP fija la tasa de perdida de paquetes calculada a un informe de emisor y transmite el informe de emisor a intervalos de tiempo predeterminados al terminal de usuario a traves de la red. En el caso de tasa de errores muy baja, se desconecta el control de error en la capa de RTP/RTCP, en el caso de tasa de errores baja, se selecciona ARQ y en el caso tasa de errores alta, se selecciona FEC.

La publicacion JP2002009883 desvela un metodo para conmutar entre FEC o ARQ de acuerdo con una comparacion entre la tasa de errores medida / caudal de datos y un umbral predeterminado. Si se selecciona FEC, existe una posibilidad de conmutar de vuelta a ARQ y de manera reclproca.

La publicacion de patente US6182264B1 desvela un sistema en el que, en caso de buenas condiciones de canal (tasa de errores baja, buena calidad de senal), unicamente se selecciona CRC como mecanismo de control de errores. En caso de condiciones de canal peores, se selecciona FEC y en caso de condiciones de canal malas, se seleccionan FEC y ARQ.

La publicacion EP2369781A1 desvela una unidad de transceptor para operar un canal de comunicacion. La unidad de transceptor esta adaptada para operar el canal de comunicacion en un primer modo de operation de referenciapotencia, para configurar el control de error a traves del canal de comunicacion de acuerdo con una primera calidad de servicio QoS requerida y una primera tasa de datos nominal conseguible a traves del canal de comunicacion durante el primer modo de operacion, y para conmutar la operacion del canal de comunicacion desde el primer modo de operacion a un segundo modo de operacion de baja potencia, en el que la unidad de transceptor esta adaptada adicionalmente para ajustar el control de error a traves del canal de comunicacion de manera concomitante con la entrada en el segundo modo de operacion, haciendose el ajuste de acuerdo con una segunda QoS requerida; y una segunda tasa de datos reducida conseguible a traves del canal de comunicacion durante el segundo modo de operacion.

Sumario de la invencion

Es un objetivo de la invencion atenuar las desventajas de la tecnica anterior y ofrecer una solution que seleccione un mecanismo de INP optimo en todas las circunstancias. Esto se consigue, en un primer aspecto, por un metodo para configurar Protection de ruido de impulso, INP, en una llnea de comunicacion en una capa flsica, PHY, que comprende las siguientes etapas:

- configurar PHY para usar un modo de RTC usando retransmisiones para INP;

- monitorizar un rendimiento en este modo de RTX;

- reconfigurar PHY para usar un modo de IFEC usando correccion de errores hacia adelante e intercalar para INP si el rendimiento en este modo de RTX esta por debajo de un cierto umbral;

- monitorizar un rendimiento en el modo de IFEC;

- reconfigurar PHY de vuelta al modo de RTX si el rendimiento en este modo de IFEC esta por debajo del rendimiento en el modo de RTX

y en el que:

- el rendimiento en el modo de RTX esta relacionado con un primer tiempo medio entre errores de retransmision, primer MTBE; y en el que la reconfiguration de PHY para usar el modo de IFEC se realiza unicamente cuando el primer MTBE esta por debajo de un MTBE umbral predeterminado; el rendimiento en dicho modo de IFEC esta relacionado con un segundo MTBE; y en el que la reconfiguracion de PHY de vuelta al modo de RTX se realiza cuando el segundo MTBE en el modo de IFEC esta por debajo del primer MTBE.

Esta llnea de comunicacion puede ser una llnea de DSL que conecta, por ejemplo, un modem en unas instalaciones del usuario con un DSLAM. La llnea de comunicacion esta configurada para usar cualquier modo de IFEC o RTX. Mediante esta configuration, los transceptores en ambos extremos de la llnea de comunicacion estan reconfigurados para usar estos modos. Esta configuracion puede ser, por ejemplo, parte de Gestion de Llnea Dinamica mediante la cual el operador de red que gestiona la llnea de comunicacion aplica remotamente la configuracion al DSLAM responsable de la configuracion adicional de la llnea, es decir la configuracion del mismo DSLAM y el modem en el lado de CPE. El rendimiento se mide a continuation en la capa PHY en los transceptores y puede aplicarse la reconfiguracion despues de recibir el rendimiento monitorizado y detectar que el rendimiento ha caldo por debajo de un cierto umbral o valor mlnimo.

Es una ventaja que la llnea de comunicacion este reconfigurada de acuerdo con el mejor rendimiento y, por lo tanto, la llnea de comunicacion pueda entregar una tasa de datos superior o mejor calidad de servicio, QoS, al usuario. El rendimiento por lo tanto se monitoriza adicionalmente despues de la reconfiguracion. Ya que el metodo es emplrico, la reconfiguracion desde modo de RTX a IFEC puede dar como resultado realmente un rendimiento inferior. Es por lo tanto una ventaja que se seleccione siempre el mejor modo de realization, tambien si el mejor modo de realizacion fuera el modo de RTX.

Con un error en MTBE se pretende significar que un paquete de datos de PHY o DTU estaba corrupto y no podrla corregirse por una retransmision. Esto puede ocurrir, por ejemplo, si se alcanza el numero maximo de retransmisiones permitidas en modo de ^rT^x . Un error de este tipo tambien se denomina como una violation de codigo, CV. El MTBE es entonces el tiempo medio entre CV sucesivas dentro de un intervalo de tiempo monitorizado. El MTBE es un buen indicador del rendimiento de RTX ya que cada CV indica un fallo del modo de RTX. Cuando tiene lugar una CV en la capa PHY, el error tendra que corregirse en una capa de red superior, por ejemplo en la capa de TCP. La capa PHY por lo tanto rastreara las CV - que es el caso en la mayorla de las implementaciones de DSL - y las informara. Si el MTBE cae por debajo de un MTBE mlnimo y, por lo tanto, MTBE umbral predeterminado de esta manera, se realizara la reconfiguracion al modo de IFEC.

De manera similar a las CV en modo de RTX, la capa PHY tambien registra las CV en modo de IFEC. Por lo tanto, un MTBE tambien esta disponible en modo de IFEC. El MTBE por lo tanto proporciona una manera facil y sencilla de evaluar si el modo de IFEC rinde de manera eficaz mejor que el modo de RTX.

No unicamente se tienen en cuenta las violaciones de codigo por lo tanto, si no tambien posibles retransmisiones hechas en la capa superior debido a las DTU corruptas no corregidas. Por ejemplo, una DTU corrupta puede provocar una retransmision en la capa de TCP de la pila de protocolo, generando tambien sobrecarga y reduciendo por lo tanto el caudal real en la llnea de comunicacion. La sobrecarga generada en la capa PHY y en la capa de aplicacion se combina de esta manera en la sobrecarga de comunicacion. Si esta sobrecarga de comunicacion es mayor que una sobrecarga de comunicacion predefinida, se hace la reconfiguracion al modo de IFEC.

Es una ventaja que el impacto de errores de transmision se verifique de manera precisa teniendo en cuenta la retransmision en la capa de aplicacion superior ya que esto dara como resultado decisiones mas satisfactorias para reconfigurar el modo de PHY a IFEC y por lo tanto entregar una QoS superior al usuario.

En otras palabras, para determinar si el modo de IFEC rinde mejor que modo de RTC unicamente se consideran las violaciones de codigo, es decir los errores de transmision en la capa PHY. Siempre que haya aun violaciones de codigo, la capa PHY se configura de vuelta al modo de RTX.

Mas ventajosamente, la reconfiguracion puede comprender adicionalmente:

- elegir parametros relacionados con el modo de IFEC de manera que la sobrecarga inducida por el modo de IFEC dependa de una sobrecarga observada en el modo de RTX.

La sobrecarga real en modo de RTX es bien conocida ya que la cantidad de retransmisiones puede monitorizarse en la PHY como es normalmente el caso en aplicaciones de DSL. La sobrecarga en modo de IFEC esta fijada como para la tasa de codification de la codification de FEC que es un parametro elegido en el momento de configuracion. Por lo tanto, la tasa de codificacion del modo de FEC, y por lo tanto la sobrecarga por el modo de IFEC, pueden seleccionarse de manera que es mas cercana a la sobrecarga monitorizada durante el modo de RTX.

Es una ventaja que el rendimiento medido en modo de IFEC se medira para la misma sobrecarga de codificacion que permite una comparacion precisa entre los dos modos. De hecho, si se seleccionara un modo de IFEC con sobrecarga mayor, podrla provocarse en este modo un mejor rendimiento por la mayor tasa de codificacion y no por el mejor rendimiento intrlnseco de la IFEC en si misma.

Despues de que se ha configurado la llnea de comunicacion al modo IFEC, el metodo puede comprender adicionalmente:

- optimizar adicionalmente los parametros relacionados con el modo de IFEC.

Por lo tanto, para comparar el rendimiento en modo de IFEC con el rendimiento en modo de RTX se eligieron los parametros relacionados con el modo de IFEC de manera que la sobrecarga estaba cercana a la sobrecarga en modo de RTX. Cuando se decide permanecer en modo de IFEC, estos parametros se optimizan adicionalmente. Es por lo tanto una ventaja que el rendimiento en modo de IFEC pueda incluso mejorarse en comparacion con el rendimiento en modo de RTX.

Opcionalmente para las realizaciones anteriores, la reconfiguracion se realiza unicamente cuando el modo de IFEC puede corregir un numero mlnimo de slmbolos de Multi-Tono Discreto erroneos consecutivos, enviados a traves de la llnea de comunicacion.

En otras palabras, antes de reconfigurar al modo de IFEC se determina si el modo de IFEC con los parametros que dan como resultado una sobrecarga similar que el modo de RTX pueden rendir realmente segun se requiere mlnimamente, es decir si corrige este numero mlnimo de slmbolos de DMT erroneos consecutivos. La capacidad para corregir este numero de slmbolos depende de estos parametros pero tambien de un retardo permisible maximo para la intercalacion que es un valor preestablecido determinado por la QoS requerida.

Es una ventaja que la reconfiguracion innecesaria al modo de IFEC pueda evitarse determinando teoricamente el rendimiento de la IFEC cuando se aplican los parametros provocando la misma cantidad de sobrecarga que en modo de RTX.

En un segundo aspecto, la invencion se refiere a un producto de programa informatico que comprende instrucciones ejecutables por ordenador para realizar el metodo de acuerdo con el primer aspecto cuando el programa se ejecuta en un ordenador.

En un tercer aspecto, la invencion tambien se refiere a un medio de almacenamiento legible por ordenador que comprende el producto de programa informatico de acuerdo con el segundo aspecto.

En un cuarto aspecto, la invencion se refiere un sistema de procesamiento de datos programado para llevar a cabo el metodo de acuerdo con el primer aspecto.

La invencion tambien se refiere, en un quinto aspecto, a un dispositivo de Gestion de Llnea Dinamica, DLM, para configurar Proteccion de ruido de impulso, INP, en una llnea de comunicacion en una capa flsica, PHY; dicho dispositivo de DLM estando configurado adicionalmente para:

- configurar dicha PHY para usar un modo de RTC usando retransmisiones para INP;

- monitorizar un rendimiento en dicho modo de RTX;

- reconfigurar dicha PHY para usar un modo de IFEC usando correccion de errores hacia adelante e intercalar para INP si dicho rendimiento en dicho modo de RTX esta por debajo un cierto umbral;

- monitorizar un rendimiento en dicho modo de IFEC;

- reconfigurar dicha PHY de vuelta a dicho modo de RTX si dicho rendimiento en dicho modo de IFEC esta por debajo de dicho rendimiento en dicho modo de RTX

en el que:

- dicho rendimiento en dicho modo de RTX esta relacionado con un primer tiempo medio entre errores de transmision, primer MTBE; y en el que dicha reconfiguracion de dicha PHY para usar dicho modo de IFEC se realiza unicamente cuando dicho primer MTBE esta por debajo de un MTBE umbral predeterminado; dicho rendimiento en dicho modo de IFEC esta relacionado con un segundo MTBE; y en el que dicha reconfiguracion de dicha PHY de vuelta a dicho modo de RTX se realiza cuando dicho segundo MTBE en dicho modo de IFEC esta por debajo de dicho primer MTBE.

Definiciones

La siguiente descripcion y realizaciones se entenderan mejor a la luz de las siguientes definiciones. La mayorla de estas definiciones definen terminos que se usan comunmente en el campo de llneas de comunicacion de DSL o en el campo mas amplio de las telecomunicaciones.

Tasa de datos neta, NDR, es la tasa de bits total disponible en una llnea de comunicacion en la capa PHY cuando no tienen lugar retransmisiones. En el caso de una llnea de DSL, es la tasa de datos a la que esta sincronizada la ilnea.

Caudal sin errores, EFTR, es ia tasa de datos real disponibie para trafico de usuario. Consiste en ia NDR menos ia sobrecarga necesaria para retransmisiones. Cuando no tiene iugar ia retransmision, ei EFTR equivaie a ia NDR. Ei EFTR es variabie, dependiendo de condiciones de ruido de impuiso.

minINP_SHINE es un parametro de configuracion que describe ei numero esperado de slmboios de Muiti-Tono Discreto, DMT, que podrlan verse afectados por eventos SHINE, es decir una rafaga aisiada de ruido de impuiso. Describe tambien entonces ei nivei mlnimo de protection de ruido de impuiso (INP) contra eventos SHINE, requerido para transmision sin errores en ias condiciones de ruido esperadas.

miniNP_REIN es un parametro de configuracion que describe ei numero esperado de slmboios de DMT consecutivos que podrlan verse afectados por REIN, es decir ruido de impuiso que tiene iugar a una tasa dada. En una configuracion de DSL tlpica, esta tasa puede configurarse a traves dei parametro IAT_REIN, tiempo interiiegada para REIN, y normaimente corresponde a 100 Hz en Europa y 120 Hz en America dei Norte. miniNP_REIN entonces tambien describe ei nivei mlnimo de INP frente a REIN, requerido para transmision sin errores en ias condiciones de ruido esperadas.

Shineratio es un parametro que describe ia cantidad de sobrecarga que se espera que sea necesaria para retransmision de DTU corruptas que se han visto afectadas por SHINE. Esta reiacion se proporciona como un porcentaje dei NDR y puede estar configurada entre ei 0,1 % y ei 10 %.

La sobrecarga de retransmision esperada, RTX_OH, es ia portion de ia NDR que se usa para retransmision de DTU corruptas, y que por io tanto no esta disponibie para trafico de usuario. A partir de ia norma G.INP, ia sobrecarga de retransmision esperada se caicuia como sigue:

RTX_OH = SHINE_OH REIN_OH STAT_OH

La sobrecarga SHINE_OH, SHINE, es ia sobrecarga esperada necesaria para mitigar eventos SHINE y corresponde a ia Shineratio.

La sobrecarga de REIN, REIN_OH, es ia sobrecarga esperada necesaria para mitigar eventos REIN y puede aproximarse a partir de miniNP_REIN. Si se supone una tasa de slmboio de datos de 4000 slmboios por segundo, ia REIN_OH puede aproximarse por:

REIN_OH » (miniNP_REIN / 40) a

Donde a es una cantidad desconocida a priori, que varla dei 1,25 % ai 10 % y que depende de parametros de aiineacion de tramas.

La sobrecarga estatica, STAT_OH, es ia sobrecarga esperada necesaria para mitigar ruido estacionario. En normas de DSL se supone que es 1.10-4.

Caudai esperado, ETR, es un parametro que se caicuia durante sincronizacion de una ilnea de comunicacion y representa ei EFTR que se obtendrla si ias condiciones de ruido requirieran exactamente ia cantidad esperada de sobrecarga, segun se caicuia a partir de Shineratio y minINP_REIN configuradas y a partir de ia RTX_OH. Se caicuia por io tanto como sigue:

ETR = (1 - RTX_OH) * NDR.

Por io tanto, si ia cantidad reai de sobrecarga necesaria para retransmisiones es menor que io que se esperaba entonces se apiica ia siguiente condition:

NDR > EFTR > ETR

Si ia cantidad reai de sobrecarga necesaria para retransmisiones es exactamente io que se esperaba, se apiica ia siguiente condicion:

NDR > EFTR = ETR.

Si ia cantidad reai de sobrecarga necesaria para retransmisiones es superior que io que se esperaba, se apiica ia siguiente condicion:

NDR>ETR>EFTR.

En otras paiabras, ei ETR es una estimation dei EFTR caicuiado durante sincronizacion de una ilnea de comunicacion basandose en la suposicion de que las condiciones de ruido configuradas definidas por Shineratio y minlNP_REIN corresponden exactamente al ruido observado. Sin embargo, las condiciones de ruido exactas nunca son conocidas a priori por los operadores de la red responsables de la configuracion de la llnea de comunicacion y por lo tanto, el ETR puede sobrestimarse significativamente en caso de que las condiciones de ruido se subestimen o puede subestimarse significativamente en caso de que las condiciones de ruido se sobreestimen. minEFTR, EFTR mlnimo, es un parametro que informa el EFTR mlnimo observado durante un intervalo de observacion dado que puede ser, por ejemplo, 15 minutos, 1 hora o 1 dla. El EFTR considerado para obtener el minEFTR es el valor promediado durante una ventana de 1 segundo.

EFbits, bits sin errores, es la cantidad de bits que se enviaron a traves de una llnea de comunicacion sin errores durante un cierto intervalo de tiempo. Dividiendo esta cantidad de bits por la duracion del respectivo intervalo de tiempo, se obtiene una estimacion del EFTR promedio sobre este intervalo.

Breve descripcion de los dibujos

La Figura 1 ilustra una red de acceso de datos que comprende un dispositivo de Gestion de Llnea Dinamico; La Figura 2 ilustra el caudal y rendimiento de error en una llnea de DSL;

La Figura 3 ilustra un diagrama de flujo para configurar protection de ruido de impulso en una llnea de comunicacion de acuerdo con una realization de la invention;

La Figura 4 ilustra un diagrama de flujo para configurar proteccion de ruido de impulso en una llnea de comunicacion de acuerdo con otra realizacion de la invencion.

Descripcion detallada de la realizacion o realizaciones

La Figura 1 ilustra una topologla de red de una red de acceso de datos que proporciona acceso de datos a traves de la tecnologla de Llnea Digital de Abonado, DSL. El equipo de las instalaciones de cliente o CPE 200 esta conectado a traves de un par trenzado tal como, por ejemplo, una llnea de telefonla de cobre trenzado, a un Multiplexor de Acceso de Llnea Digital de Abonado, DSLAM, 201. Este DSLAM 201 modula y demodula datos que se envlan y reciben a traves de las llneas de DSL 203. En el otro lado, tambien multiplexa estos datos a traves de un enlace troncal 204 a la Oficina Central, CO, del operador de red 206. Este enlace troncal 204 es normalmente un enlace de datos de alta velocidad tal como un enlace optico o enlace de Ethernet de alta velocidad.

Para gestionar la configuracion de la llnea de DSL 203 un dispositivo 205 esta instalado en la CO 206 para realizar Gestion de Llnea Dinamica, DLM. Durante la operation, el DSLAM 201 y el CPE 200 envlan datos de rendimiento al dispositivo de DLM 205. A continuation, a intervalos de tiempo regulares, el dispositivo de DLM 205 reconfigura las llneas de DSL para mejorar el rendimiento de las llneas de DSL 203. Estos intervalos de tiempo pueden variar de varias horas a varios dlas equilibrando el rendimiento mejorado con la conexion de datos perdidos durante la reconfiguration para el CPE 200 y por lo tanto el cliente del operador de red.

Cuando se reconfigura una llnea de comunicacion 203, el dispositivo de DLM 205 puede reconfigurar los parametros de la capa flsica, PHY, de los transceptores conectados a la llnea, es decir los transceptores en el DSLAM 201 y los transceptores en el CPE 200. Un conjunto de parametros de PHY y caracterlsticas de rendimiento estan relacionados con la codification de errores o correction de errores de los datos. Una manera de correction de errores es configurar la llnea 203, es decir los transceptores conectados a una llnea 203, para usar retransmision de DTU enviadas a traves de la llnea. Esta tecnica se describe en la norma ITU-T G.998.4 para llneas de DSL y tambien se denomina como Consulta de Repetition Automatica, ARQ, como G.INP o como modo de RTX. Otra manera o correccion de errores es configurar la llnea 203 para usar correccion de errores hacia adelante combinada con intercalation tambien denominado como modo de IFEC. Una tecnica de correccion de errores hacia adelante usada en llneas de DSL esta basada en codigos de correccion de errores clclicos, mas particularmente en codigos de Reed-Solomon.

La Figura 2 muestra caracterlsticas de rendimiento de una llnea de comunicacion de VDSL2 203 obtenida por un dispositivo de DLM 205. La llnea monitorizada 203 tiene una longitud de 400 metros y, como se indica por el eje X, la llnea se configura en primer lugar en modo de RTX durante 30 minutos y a continuacion se reconfigura al modo de IFEC durante otros 30 minutos. El primer grafico, es decir el grafico a), presenta el EFTR 300 en kilobits por segundo, kbps, como una funcion del tiempo. Mientras que en modo de rTx , el EFTR, que se promedia sobre periodos de 20 segundos en este grafico, se evalua cada 20 segundos a partir de los bits sin errores. Este EFTR promedio varla entre aproximadamente 33 Megabits por segundo o Mbps y 36 Mbps, dependiendo de las condiciones de ruido. Por la presente, 36 Mbps es el llmite superior y corresponde a la NDR en modo de RTX. El grafico a) tambien muestra el EFTR mlnimo 301, es decir el valor mlnimo de el EFTR promediado sobre 1 segundo durante un intervalo de tiempo de 15 minutos. Aunque el EFTR 300 promediado sobre periodos de 20 segundos esta siempre por encima de 33 Mbps, el EFTR mlnimo 301 cae regularmente tan bajo como 10 Mbps. En otras palabras, de manera regular, mas del 65 % del ancho de banda disponible se usa para retransmisiones durante un segundo completo, dejando unicamente aproximadamente un tercio de la tasa de datos neta, NDR, para trafico de usuario real. Dejando de manera regular tan poco ancho de banda para las capas de aplicacion para al menos un segundo completo tiene un impacto en la calidad de servicio, QoS.

Por otra parte, despues de estar reconfigurado al modo IFEC, el EFTR 300 es constante a 37 Mbps que corresponde a la NDR en modo de IFEC. Por lo tanto, la tasa de datos disponible es superior en modo de IFEC que en RTX, alrededor del 10 % superior de media. Ademas, el EFTR mlnimo 301 nunca cae a tales niveles bajos como en modo de RTX. Por lo tanto, en el caso ilustrado por la Figura 2 el modo de IFEC rinde mejor el modo de RTX. El grafico b) de la Figura 2 ilustra la cantidad de violaciones de codigo, CV, recibidas y por lo tanto la cantidad de DTU corruptas recibidas y no corregidas por la capa PHY. Debido al llmite superior en la cantidad de retransmisiones que pueden aplicarse para una unidad de datos, no todas las unidades de datos corruptas se retransmitieron en modo de RTX dando como resultado las CV en modo de RTX. Dependiendo de las capas de comunicacion superior, los datos corruptos pueden aun retransmitirse. Por ejemplo, si se usa una capa de aplicacion de TCP, los datos corruptos se retransmitiran alll. Esto, sin embargo, reducira adicionalmente el caudal de datos eficaz. En modo de IFEC por otra parte, no quedan errores de transmision, CV, es decir todas las unidades de datos corruptas se corrigen por el decodificador de FEC.

La Figura 3 ilustra un diagrama de flujo de la funcionalidad implementada en el dispositivo de DLM 205 que permite identificar el caso ilustrado por la Figura 2 y reconfigurando de esta manera una comunicacion desde el modo de RTX al modo de IFEC.

En una primera etapa 100, el dispositivo de DLM 205 configura una llnea de comunicacion 203 en modo de RTX. A continuacion, en una etapa 101, la llnea de comunicacion se monitoriza para un cierto intervalo de tiempo. Despues de este intervalo, en una etapa 102, se determina si este rendimiento es como se esperaba, es decir si es mejor que un cierto umbral predefinido o determinado. A continuacion, si el rendimiento esta por debajo del umbral, la llnea de comunicacion se reconfigura para usar el modo de IFEC para correccion de errores en una etapa 103. Cuando esta en este modo de IFEC, el rendimiento de la llnea de comunicacion se monitoriza de nuevo para un cierto periodo de tiempo en una etapa 104. Despues de este intervalo de tiempo, el rendimiento monitorizado en modo de RTX que era el activador para reconfigurar el modo de IFEC se compara con el rendimiento monitorizado en modo de IFEC en una etapa 105. Si el rendimiento no se ha mejorado, el dispositivo de DLM 205 reconfigura la llnea de comunicacion 203 de vuelta al modo de RTX. Si se ha mejorado el rendimiento, la llnea de comunicacion se mantiene en modo de IFEC y el dispositivo de DLM 205 mantiene la monitorizacion del rendimiento en modo de IFEC de acuerdo con la etapa 104.

Opcionalmente despues de decidir permanecer en modo de IFEC en la etapa 105, los parametros del modo de IFEC pueden optimizarse adicionalmente para mejorar adicionalmente el rendimiento.

De acuerdo con una realizacion de la invencion, el rendimiento se monitoriza por el Tiempo Medio entre Error, MTBE, es decir el tiempo medio entre apariciones de un error o violacion de codigo. Esto se ilustra mediante la Figura 4 que detalla adicionalmente las etapas de la Figura 3 de acuerdo con esta realizacion. En la misma, la etapa 401 monitoriza el MTBE y comprueba en la etapa 410 si:

MTBE < minMTBE

mediante el cual minMTBE es un MTBE mlnimo preconfigurado usado como un umbral.

En caso afirmativo, se decide que el modo de RTX no esta rindiendo lo suficientemente bien y se determinan los parametros para el modo de IFEc . Estos se determinan a partir de la siguiente formula calculando la sobrecarga de datos inducidos provocada por el mecanismo de correccion de IFEC:

D M - IN P

U M IF E C ~ 2*Retardo

• OH^ifec es la sobrecarga de datos inducidos provocada por el mecanismo de correccion de IFEC;

• INP es el nivel de proteccion de ruido de impulso que significa el numero de slmbolos de DMT erroneos consecutivos que el modo de IFEC deberla poder corregir;

• Retardo es el retardo maximo permitido para el intercalador.

El retardo es un parametro fijado determinado por el operador de red y que depende del tipo de servicio ofrecido a traves de la llnea de comunicacion. El otro parametro que determina el modo de IFEC es entonces el nivel de INP y se calcula como sigue:

IN P — 2 ^ Retardo ^ O H jp ^c — 2 ^ Retardo ^ O H ^ j'^

El parametro de INP IFEC por lo tanto se elige de manera que la sobrecarga OH^ifec en modo de IFEC depende de la sobrecarga OH^rtx en modo de RTX. La sobrecarga en el modo de RTX se deriva de esta manera a partir del Caudal Sin Errores monitorizado, EFTR, y la tasa de datos neta, NDR:

Opcionalmente, de acuerdo con la etapa 411 puede verificarse si el nivel de INP calculado es mayor que un nivel de INP mlnimo predefinido, minlNP. Este minlNP puede a continuacion determinarse por el operador de red.

Si el MTBE esta por debajo de un minMTBE de acuerdo con la etapa 410 y si, opcionalmente, el nivel de INP calculado para el modo de IFEC es mayor que un minIP predefinido de acuerdo con la etapa 411, entonces el dispositivo de DLM 205 continua a la etapa 103 y la llnea de comunicacion se reconfigura al modo de IFEC de acuerdo con el parametro de INP y retardo. En la etapa 404, el rendimiento en modo de IFEC se monitoriza monitorizando el MTBE en modo de IFEC. En la etapa 405, se comprueba a continuacion si:

MTBE^ifec > MTBE^rtx

mediante lo cual

MTBE^ifec es el MTBE en modo de IFEC;

MTBE^rT^x es el MTBE en modo de RTX.

Si esto se cumple, el modo de IFEC rinde mejor que el modo de RTX y se decide permanecer en modo de IFEC. Si esta condition es falsa, el modo de IFEC no rinde mejor que el modo de RTX y se decide reconfigurar la llnea de comunicacion de vuelta al modo de RTX continuando a la etapa 100.

Opcionalmente, tambien puede optimizarse en este punto el nivel de INP adicionalmente en la etapa 106 para mejorar el rendimiento, es decir para minimizar el MTBE adicionalmente. Esto puede ser beneficioso ya que el nivel de INP se eligio inicialmente para proporcionar la misma sobrecarga que en el modo de RTX. Por lo tanto, el nivel de INP puede aun reducirse adicionalmente siempre que sea mayor que el minlNP y siempre que se mantenga la condicion bajo la etapa 405.

Las realizaciones anteriores se han descrito usando un dispositivo de DLM 205 para configurar las llneas de comunicacion 203. Este dispositivo puede ser un servidor o grupo de servidores mediante el cual la funcionalidad ilustrada por la Figura 3, 4 y 5 se ejecuta como un servicio en este servidor o servidores. La funcionalidad puede a continuacion proporcionarse como codigo de software que se compila y se ejecuta en uno o mas procesadores comprendidos en el dispositivo de DLM 205. Se prefiere que el dispositivo de DLM 205 este localizado en la oficina central 206 ya que esta localization central posibilita la gestion de todas las llneas de comunicacion 203 operadas por la oficina central 206, es decir por el operador de red. Sin embargo, tambien es posible localizar el dispositivo de DLM 205 en otras localizaciones, por ejemplo cerca del DSLAM o incluso embeberlo como un servicio adicional dentro de un unico DSLAM gestionando de esta manera unicamente las llneas de comunicacion conectadas a este unico DSLAM.

Aunque la presente invention se ha ilustrado por referencia a realizaciones especlficas, sera evidente para los expertos en la materia que la invencion no esta limitada a los detalles de las realizaciones ilustrativas anteriores, y que la presente invencion puede realizarse con diversos cambios y modificaciones sin alejarse del alcance de la misma. La presentes realizaciones se han de considerar por lo tanto en todos los aspectos como ilustrativas y no restrictivas, indicandose el alcance de la invencion por las reivindicaciones adjuntas en lugar de por la description anterior, y todos los cambios que entren dentro del significado y alcance de equivalencia de las reivindicaciones, por lo tanto se pretende que esten abarcados en las mismas. En otras palabras, se contempla cubrir cualesquiera y todas las modificaciones, variaciones o equivalentes que caigan dentro del alcance de los principios subyacentes basico y cuyos atributos esenciales se reivindiquen en esta solicitud de patente. Se entendera adicionalmente por el lector de esta solicitud de patente que las palabras “que comprende” o “comprende” no excluyen otros elementos o etapas, que las palabras “un” o “una” no excluyen una pluralidad, y que un unico elemento, tal como un sistema informatico, un procesador, u otra unidad integrada puede satisfacer las funciones de varios medios indicados en las reivindicaciones. Cualesquiera signos de referencia en las reivindicaciones no deberan interpretarse como que limitan las respectivas reivindicaciones referidas. Los terminos “primero”, “segundo”, “tercero”, “a”, “b”, “c”, y similares, cuando se usan en la descripcion o en las reivindicaciones se introducen para distinguir entre elementos o etapas similares y no estan describiendo necesariamente un orden secuencial o cronologico. De manera similar, los terminos “superior, “inferior”, “por encima de”, “por debajo de”, y similares se introducen para fines descriptivos y no para indicar necesariamente posiciones relativas. Se ha de entender que los terminos as! usados son intercambiables bajo circunstancias apropiadas y las realizaciones de la invencion pueden operar de acuerdo con la presente invencion en otras secuencias o en orientaciones diferentes de la o las descritas o ilustradas anteriormente.

Claims (8)

REIVINDICACIONES

1. Un metodo para configurar proteccion de ruido de impulso, INP, en una ilnea de comunicacion (203) en una capa flsica, PHY, que comprende las siguientes etapas:

- configurar (100) dicha PHY para usar un modo de RTC usando retransmisiones para INP;

- monitorizar (101,401) un rendimiento en dicho modo de RTX;

- reconfigurar (103) dicha PHY para usar un modo de IFEC usando correction de errores hacia delante e intercalation para INP si (102) dicho rendimiento en dicho modo de RTX esta por debajo de un cierto umbral; - monitorizar (104, 404) un rendimiento en dicho modo de IFEC;

- reconfigurar dicha PHY de vuelta a dicho modo de RTX si (105, 405) dicho rendimiento en dicho modo de IFEC esta por debajo de dicho rendimiento en dicho modo de RTX

caracterizado adicionalmente por que:

- dicho rendimiento en dicho modo de RTX esta relacionado con un primer tiempo medio entre errores de transmision, primer MTBE (401); y en el que dicha reconfiguration de dicha PHY para usar dicho modo de IFEC se realiza unicamente cuando (410) dicho primer MTBE esta por debajo de un MTBE umbral predeterminado; dicho rendimiento en dicho modo de IFEC esta relacionado con un segundo MTBE (404); y en donde dicha reconfiguracion de dicha PHY de vuelta a dicho modo de RTX se realiza cuando (405) dicho segundo MTBE en dicho modo de IFEC esta por debajo de dicho primer MTBE.

2. Un metodo de acuerdo con la reivindicacion 1, en el que dicha reconfiguracion comprende adicionalmente:

- elegir parametros relacionados con dicho modo de IFEC de manera que la sobrecarga inducida por dicho modo de IFEC depende de la sobrecarga observada en dicho modo de RTX.

3. Un metodo de acuerdo con la reivindicacion 2, que comprende adicionalmente:

- optimizar adicionalmente (106) dichos parametros relacionados con dicho modo de IFEC.

4. Un metodo de acuerdo con la reivindicacion 1, en el que dicha reconfiguracion de dicha PHY para usar dicho modo de IFEC se realiza unicamente cuando (411) dicho modo de IFEC puede corregir un numero mlnimo de slmbolos de Multi-Tono Discreto, DMT, erroneos consecutivos enviados a traves de dicha llnea de comunicacion (203).

5. Un producto de programa informatico que comprende instrucciones ejecutables por ordenador para realizar el metodo de acuerdo con la reivindicacion 1 cuando el programa se ejecuta en un ordenador.

6. Un medio de almacenamiento legible por ordenador que comprende el producto de programa informatico de acuerdo con la reivindicacion 5.

7. Un sistema de procesamiento de datos programado para llevar a cabo el metodo de acuerdo con la reivindicacion 1.

8. Un dispositivo de gestion de llnea dinamica, DLM, (205) para configurar proteccion de ruido de impulso o INP en una llnea de comunicacion (203) en una capa flsica, PHY; estando configurado adicionalmente dicho dispositivo de DLM para:

- configurar (100) dicha PHY para usar un modo de RTC usando retransmisiones para INP;

- monitorizar (101,401) un rendimiento en dicho modo de RTX;

- reconfigurar (103) dicha PHY para usar un modo de IFEC usando correccion de errores hacia adelante e intercalacion para INP si dicho rendimiento en dicho modo de RTX esta por debajo de un cierto umbral;

- monitorizar (104, 404) un rendimiento en dicho modo de IFEC;

- reconfigurar (105, 405) dicha PHY de vuelta a dicho modo de RTX si dicho rendimiento en dicho modo de IFEC esta por debajo de dicho rendimiento en dicho modo de RTX

caracterizado adicionalmente por que:

- dicho rendimiento en dicho modo de RTX esta relacionado con un primer tiempo medio entre errores de transmision, primer MTBE (401); y en donde dicha reconfiguracion de dicha PHY para usar dicho modo de IFEC se realiza unicamente cuando (410) dicho primer MTBE esta por debajo de un MTBE umbral predeterminado; dicho rendimiento en dicho modo de IFEC esta relacionado con un segundo MTBE (404); y en donde dicha reconfiguracion de dicha PHY de vuelta a dicho modo de RTX se realiza cuando (405) dicho segundo MTBE en dicho modo de IFEC esta por debajo de dicho primer MTBE.