ES2391536T3 - Gestión dinámica de la línea - Google Patents

Abstract

Procedimiento de operación de una red de acceso que incluye una pluralidad de conexiones de datos entre unosdispositivos de usuario final (10) y un dispositivo de transceptor de agregación (20), siendo agregadas lasconexiones para una posterior conexión a través de la red de acceso, comprendiendo el procedimiento las etapassiguientes: almacenar una pluralidad de perfiles diferentes, cada uno de los cuales especifica un conjunto de valorespara un conjunto de uno o más parámetros asociados a cada conexión de datos y, para cada conexión de datos,monitorizar el rendimiento de la conexión; seleccionar uno de dichos perfiles almacenados para aplicarlo a laconexión en función de los resultados de la monitorización de la conexión; y aplicar el perfil seleccionado a laconexión de datos, caracterizado porque la monitorización de la conexión incluye determinar el número de eventosde mal rendimiento que se producen, en un período de tiempo determinado, y calcular el número de dichos eventosde mal rendimiento que se producen como resultado de un evento de alcance local que afecta a una pluralidad delíneas y desestimar cualquiera de dichos eventos de mal rendimiento cuando se selecciona un perfil para aplicarlo ala conexión de datos.

Description

Gestión dinámica de la línea.

Campo de la invención

La presente invención se refiere a la gestión dinámica de la línea.

Antecedentes de la invención

La técnica de gestión dinámica de la línea (DLM) es una técnica para incrementar la estabilidad de las conexiones DSL, que resulta particularmente útil cuando se utilizan conexiones DSL cerca de su velocidad máxima, porque en estas condiciones el ruido externo que afecta a la señal transmitida puede determinar que los transceptores sean incapaces de recuperar con éxito la señal que se desea transmitir con suficiente fiabilidad como para permitir que se mantenga la conexión. En tal caso, sería necesario restablecer la conexión. Este restablecimiento de la conexión, denominado "resincronización" o "reacondicionamiento", es percibido por el usuario como una pérdida temporal del servicio. En general, las resincronizaciones resultan particularmente molestas para los usuarios finales.

La DLM tiene por objetivo reducir al mínimo dichas resincronizaciones analizando automáticamente las conexiones DSL (en especial, la frecuencia de aparición de las resincronizaciones) y variando ciertos parámetros que pueden afectar a la probabilidad de que se produzcan las resincronizaciones (por ejemplo la profundidad de entrelazado, la cantidad de la redundancia incorporada en la codificación utilizada, etc.). Habitualmente, esto se realiza utilizando una serie de perfiles diferentes que presentan diversos conjuntos de valores diferentes para los parámetros que tienen más probabilidades de influir en la estabilidad de una conexión DSL o influir en esta de otra manera, y cambiando una conexión particular entre perfiles diferentes hasta que se encuentra un perfil que presenta una estabilidad aceptable. Los perfiles se aplican en la central telefónica local, (a veces denominados, en particular EEUU, oficina central) comúnmente dentro de un aparato denominado "multiplexor de acceso a línea de abonado digital" (DSLAM) que contiene varias unidades de transceptor DSL, como es bien sabido en el ámbito de la técnica.

Se suele diferenciar conceptualmente entre perfiles más agresivos y menos agresivos, de los cuales, los perfiles más agresivos tienden a ofrecer mejores servicios al usuario (especialmente en términos de tasas de bits más altas y latencias más bajas), aunque son más propensos a generar inestabilidad en la línea, mientras que los perfiles menos agresivos tienden a ofrecer tasas de bits y/o latencias más bajas, aunque mayor estabilidad.

Un procedimiento como el mencionado se da a conocer, por ejemplo, en el documento EP 1 953 959 A.

Todas las soluciones DLM conocidas por el presente solicitante utilizan, por lo menos como una de las métricas utilizadas en la monitorización del rendimiento de una línea, el número de reacondicionamientos o resincronizaciones que tienen lugar en una línea en un período de tiempo predeterminado. Sin embargo, los presentes inventores han comprobado que en ciertas circunstancias esta métrica induce a error y que, por consiguiente, es necesario procesarla para ofrecer una medición más fiable del rendimiento de la línea.

Sumario de la invención

Según un primer aspecto de la presente invención, se ofrece un procedimiento de operación de una red de acceso que comprende una pluralidad de conexiones de datos entre dispositivos de usuario final y un dispositivo de transceptor de agregación, en el que las conexiones se agregan para una posterior conexión a través de la red de acceso, comprendiendo el procedimiento las etapas siguientes: almacenar una pluralidad de perfiles diferentes, cada uno de los cuales especifica un conjunto de valores para un conjunto de uno o más parámetros asociados a cada conexión de datos, y, para cada conexión de datos, monitorizar el rendimiento de la conexión; seleccionar uno de dichos perfiles almacenados para aplicarlo a la conexión dependiendo de los resultados de la monitorización de la conexión; y aplicar el perfil seleccionado a la conexión de datos, en el que la monitorización de la conexión comprende la determinación del número de veces que se produce un evento de mal rendimiento, dentro de un período de tiempo determinado, y el cálculo del número de dichos eventos de mal rendimiento que se producen como resultado de un evento de alcance local que afecta a una pluralidad de líneas y la desestimación de cualquiera de dichos eventos de mal rendimiento cuando se selecciona un perfil para aplicar a la conexión de datos.

Preferentemente, los eventos de mal rendimiento monitorizados comprenden por lo menos resincronizaciones o errores (preferentemente, estén o no corregidos), pero más preferentemente comprenden tanto resincronizaciones como errores. Por lo tanto, la determinación del número de eventos de mal rendimiento que se producen en un período de tiempo determinado (habitualmente del orden de un día o una semana) podría comprender el recuento de todas las resincronizaciones que se producen en la conexión durante ese período, el recuento de todos los errores que se producen durante ese período o el recuento de todos los errores y las resincronizaciones (de forma separada o conjunta). Un procedimiento fácil (aunque menos preciso) para registrar el "recuento", en lugar de contar y registrar con exactitud el número total por conexión y período de monitorización, consiste en dividir el período de monitorización (es decir, el período de tiempo determinado que comúnmente es del orden de un día) en bins o períodos de tiempo mucho más pequeños (por ejemplo, de 15 minutos) y simplemente indicar (por ejemplo, con un 1 binario) si se produce alguna resincronización en ese bin o no (por ejemplo, con un 0 binario). Se podría mantener un registro semejante para los errores (o, puesto que los errores son mucho más comunes y menos graves que las resincronizaciones por lo general, bastaría con registrar un 1 binario si se detecta un número de errores superior a un número predeterminado dentro del bin, etc.).

Conforme al primer aspecto que se acaba de exponer, la métrica de mal rendimiento de número de resincronizaciones por unidad de tiempo se modifica para eliminar (en términos generales, por lo menos parcialmente) las resincronizaciones causadas por eventos de alcance local (por ejemplo, tormentas eléctricas), etc., obteniéndose de ese modo una métrica más útil para la gestión dinámica de la línea. Las tormentas eléctricas son el evento de alcance local más común que puede provocar que muchas líneas deban realizar simultáneamente una resincronización forzada, aunque existen otros eventos externos similares que pueden causar la resincronización de una línea pese a que la línea se halle en ese momento en un perfil adecuado, debiéndose descartar por consiguiente todos los eventos de resincronización mencionados. Preferentemente, en un sistema en el que se utilizan más métricas de rendimiento para determinar si deben o no reasignarse perfiles, se descarta cualquier otra métrica, tal como los errores detectados en una línea, que además se producen en una línea que se ha visto afectada por un evento de alcance local (por ejemplo, una tormenta eléctrica) durante el período en el que se ha producido dicho evento de alcance local.

Preferentemente, el cálculo del número de resincronizaciones que se producen como consecuencia de un evento de alcance local comprende la determinación de la proporción de conexiones activas dentro de un grupo predeterminado de conexiones que experimentan una resincronización en un período de prueba de duración predeterminada, la comparación de esta con un umbral y la determinación de un evento de alcance local como causa de todas dichas resincronizaciones si esta proporción rebasa el umbral. Aunque este procedimiento de cálculo del número de resincronizaciones (u otros parámetros tales como errores, etc.) provocadas por un evento de alcance local comparando la proporción de líneas que experimentan una resincronización (u otro parámetro o evento, tal como un error) en un período de tiempo corto predeterminado (por ejemplo, un período de tiempo de cinco minutos) se considera actualmente el sistema más práctico para calcular si se ha producido un evento de alcance local, resultará evidente a las personas expertas en la materia que es posible utilizar procedimientos alternativos. Aunque tras un análisis adecuado dichos procedimientos alternativos pueden funcionar de una manera en esencia muy similar, en ciertos planteamientos tal vez resulte difícil establecer que realmente sea así. Por ejemplo, si se utiliza una red neuronal artificial (ANN), esta podría entrenarse basándose en los datos de entrada sobre las resincronizaciones producidas en un gran número de líneas para calcular cuál de esas resincronizaciones se produce como consecuencia de un evento de alcance local. Aunque es probable que la operación en cuestión sea muy semejante a la comparación de las proporciones de líneas que experimentan resincronizaciones, errores, etc. con un umbral de proporción en cierto período de tiempo, resulta sumamente difícil determinar la operación matemática exacta de las ANN y, por consiguiente, muy difícil determinar con seguridad si es una u otra. Además, si se facilitaran suficientes tipos de datos diferentes a la ANN, probablemente esta hallaría alguna relación matemática subyacente alternativa significativa que pudiera utilizarse para calcular las resincronizaciones (o los errores, etc.) causadas como consecuencia de un evento de alcance local.

Una arquitectura de red de acceso común a la cual puede aplicarse la presente invención comprende una pluralidad de multiplexores de acceso a línea de abonado digital (DSLAM) y/o nodos de acceso multiservicio (MSAN) que actúan (ambos) como un punto de convergencia, en el que una pluralidad de líneas DSL terminan y se conectan a través de conexiones de mayor ancho de banda agregadas con la red principal (por ejemplo, Internet). Habitualmente (aunque no de forma obligatoria ni exclusiva) los DSLAM o MSAN (u otro tipo de dispositivos transceptores de agregación) están situados en una central telefónica local (como se denominan en GB) o unas instalaciones equivalentes de un operador de red que los controla. Cada uno de estos dispositivos transceptores de agregación o puntos de agregación (por ejemplo un DSLAM o un MSAN) agrega varias líneas que generalmente están situadas dentro de un área geográfica razonablemente pequeña, aunque el tamaño real por lo general varía en función de la densidad media de población del área, etc. En cualquier caso, en muchas ocasiones, un gran número de líneas que se dirigen hacia un único punto de agregación se hallarán bastante cerca unas de otra desde un punto de vista geográfico. Así pues, un evento externo tal como una tormenta eléctrica puede afectar a un número de líneas agregadas en el mismo punto de agregación a la misma hora aproximadamente. Por consiguiente, una implementación preferida de la presente invención presenta un dispositivo de punto de agregación, tal como un DSLAM o un MSAN, que monitoriza todas las conexiones DSL que terminan en el mismo y compara el número de dichas conexiones que se resincronizan dentro de cierto lapso de unas a otras. En esta implementación, el administrador del dispositivo de punto de agregación puede configurar los parámetros de duración del período de prueba (dentro del cual se cuentan las resincronizaciones que es probable que hayan sido causadas por un efecto de alcance local) y de umbral de porcentaje de líneas activas que experimentan una resincronización que determinará la detección de un supuesto evento de alcance local.

Se pueden utilizar diferentes mecanismos para controlar la hora de inicio y de fin de un período de prueba. Por ejemplo, puede utilizarse una serie de intervalos de tiempo no superpuestos iguales a la duración del período de prueba. Por lo tanto, si la duración del período de prueba se establece en diez minutos, cada vez que transcurre un período de diez minutos de duración (por ejemplo, de 1:00 pm a 1:10 pm, de 1:10 a 1:20.), el número de resincronizaciones que tienen lugar en ese período puede contarse y compararse con el umbral. Este mecanismo es sencillo pero puede implicar que se pase por alto un evento que en realidad debería incluirse en el recuento, ya que se produce en el límite de un período de prueba (por ejemplo, la mitad de las resincronizaciones tienen lugar justo antes de las 1:10 pm y la otra mitad justo después de esta hora). Esta posibilidad puede mitigarse utilizando períodos de prueba superpuestos (por ejemplo, de 1:00 a 1:10, de 1:05 a 1:15, de 1:10 a 1: 20, etc.). Otra alternativa, aunque es probable que sea más costosa desde el punto de vista informático, sería iniciar un nuevo período de prueba cada vez que se produjera una resincronización.

Sea cual sea el procedimiento utilizado, si se sobrepasa el umbral de porcentaje de líneas activas que se resincronizan dentro de un período de prueba determinado, preferentemente no se tendrá en cuenta ninguna de las resincronizaciones que se produzcan en ese período de prueba (en las líneas conectadas al dispositivo de punto de agregación asociado) al decidir si debe o no cambiarse alguna de las líneas que se resincronizan a un perfil diferente.

Debe observarse que la decisión de cambiar o no una línea particular de un perfil a otro (en lo sucesivo denominado "reasignación de perfil" de línea) se realiza basándose en el número de resincronizaciones efectuadas por la línea en cuestión durante un "período de tiempo determinado", que es diferente del período de prueba utilizado para determinar si es probable o no que una serie de resincronizaciones haya sido ocasionada por un evento del área tal como una tormenta eléctrica. En particular, aparte posiblemente de procedimientos especiales utilizados para detectar líneas muy inestables y corregirlas con gran rapidez, el período de tiempo determinado utilizado para hallar el mejor perfil al cual debe cambiarse una línea particular suele ser del orden de aproximadamente 24 horas, mientras que el período de prueba para detectar eventos de alcance local es preferentemente del orden de unos minutos o inferior.

Preferentemente, cada perfil especifica por lo menos dos parámetros diferentes, y más preferentemente los parámetros que se especifican son, o comprenden, el margen de relación señal-ruido de destino y la profundidad de entrelazado.

El procedimiento de desestimación de las resincronizaciones causadas por un evento de alcance local se utiliza preferentemente en conjunción con lo expuesto en la solicitud EP 07255001 en trámite, en la cual las resincronizaciones causadas por el usuario, por ejemplo, cuando el usuario apaga o desconecta de alguna manera el módem DSL (por ejemplo, desenchufando la línea telefónica de la toma de línea telefónica), etc. tampoco se tienen en cuenta. En este caso, solo se tienen en cuenta las resincronizaciones automáticas o forzadas que no se producen como consecuencia de un evento de alcance local, al decidir si se va a reasignar o no un perfil a una línea.

Las resincronizaciones automáticas o forzadas se producen cuando los errores de la conexión causan una pérdida completa de la conexión. En tal caso, los módems finales revierten a un estado inicial en el que la conexión se restablece desde el principio, en lugar de tratar de mantener la conexión previa. Esto está estipulado en las diversas normas xDSL, que comprenden, en particular, ITU-T G992.1 - ADSL1, ITU-T G992.3 - ADSL2, ITU-T G992.5 - ADSL2+ e ITU-T G994.1 - Handshake Procedures for digital subscriber line (DSL) transceivers.

Preferentemente, la determinación o el cálculo del número de resincronizaciones forzadas que no se producen como resultado de un evento de alcance local comprenden la determinación del número total de resincronizaciones (en el período de tiempo determinado en cuestión) por todas las razones, el cálculo del número total de resincronizaciones causadas por un usuario y el número total de resincronizaciones generadas en ese período como consecuencia de un evento de alcance local, y la resta de los números de resincronizaciones causadas por el usuario y resincronizaciones causadas por eventos de alcance local calculados para obtener el cálculo del número de resincronizaciones forzadas no causadas por un evento de alcance local.

Preferentemente, la etapa de cálculo del número de resincronizaciones causadas por el usuario comprende la detección de la superación de un período de tiempo mínimo predeterminado antes o después de una resincronización sin que se haya establecido una conexión y sin que la línea haya intentado, de manera automática pero infructuosa, restablecer la conexión. Por lo tanto, si el usuario simplemente apaga o desenchufa el módem durante un período de tiempo superior al período de tiempo mínimo, se considera que la resincronización resultante es una resincronización causada por el usuario en lugar de una resincronización forzada. Preferentemente, esto se consigue contando los períodos contiguos de tiempo de inactividad que sobrepasan el período mínimo predeterminado dentro del período particular (más largo).

En una forma de realización, se mantiene un registro de cada período (bin) de 15 minutos, durante el cual no está establecida ninguna conexión, y el número de conjuntos de períodos contiguos en los que no se registra ninguna conexión establecida durante cualquier período de 24 horas (lote) se toma como el número calculado de resincronizaciones causadas por el usuario dentro de dicho período de 24 horas. Naturalmente, en formas de realización alternativas, pueden utilizarse períodos de tiempo diferentes para los bins o los lotes (por ejemplo, bins de períodos de 5 minutos y lotes de 48 horas, etc.). El número de períodos contiguos (bins) puede determinarse convenientemente contando el número de transiciones entre períodos (bins) en los que no se registra la presencia de ninguna conexión y de períodos (bins) en los que se registra la presencia de una conexión.

Preferentemente, se varían dos parámetros principales que controlan el funcionamiento de las conexiones xDSL para generar perfiles diferentes: el margen de relación señal-ruido (SNR) y la modalidad de canal rápido/canal entrelazado.

El margen de SNR representa la cantidad de redundancia incorporada en la tasa de bits seleccionada (y otras opciones de conexión) para la conexión, dado el valor medido de la verdadera SNR experimentada por el módem. Por lo tanto, cada conjunto de valores significativos posible para los parámetros de conexión (es decir, tasa de bits, nivel de codificación de trellis, nivel de entrelazado, etc.) presenta una correspondiente SNR de referencia que representa el valor mínimo de la SNR al cual se espera que la conexión funcione con una tasa de bits erróneos (BER) de 10-7 (es decir, 1 bit erróneo por cada 107 bits), denominándose dicha BER de 10-7 "tasa de destino", puesto que se prevé que la conexión presente un comportamiento muy satisfactorio a este nivel de BER. El margen SNR representa la cantidad (en decibelios) en que la SNR real medida sobrepasa la cantidad de referencia en el momento de establecer la conexión. Por lo tanto, la SNR real recibida puede variar a lo largo del tiempo después del establecimiento de la conexión y situarse por debajo de la cantidad medida en el momento del establecimiento de la conexión, en una cantidad que puede llegar a ser la del margen, y aun así se prevé que la conexión funcione con una BER inferior o igual a la cantidad de destino (es decir, por lo menos tan buena como la cantidad de destino).

La definición de margen de SNR que se proporciona en la norma xDSL ITU G992.1, sección 9.5.1 es la siguiente: "Margen de relación señal-ruido (SNR): El margen de la relación señal-ruido representa la cantidad de ruido recibido incrementado (en dB) relativa a la potencia de ruido que el sistema está diseñado para tolerar y al mismo tiempo alcanzar el objetivo de BER de 10-7, que representa todas las ganancias de codificación (por ejemplo, codificación de trellis, RS FEC) comprendidas en el diseño. El margen de SNR varía entre -64,0 dB y +63,5 dB en incrementos de 0,5 dB."

Se observará, pues, que cuanto más bajo sea el margen de SNR, más alta será la tasa de bits neta factible (es decir, suponiendo que no existen errores). En cambio, cuanto más alto sea el margen de SNR, más probable será que el funcionamiento de la conexión sea estable, incluso en un entorno de ruido fluctuante.

La modalidad de canal rápido o entrelazado cambia la profundidad de entrelazado entre la de "no entrelazado" (modalidad de FAST) y cualquiera de las profundidades de entrelazado definidas en las normas de ADSL actualmente aplicables (por ejemplo, las normas ITU G.992.x). Actualmente, en muchas implementaciones solo se utiliza el nivel más bajo de entrelazado (una profundidad de 2, en la que las unidades de una única palabra de código que ocupan posiciones adyacentes antes del entrelazado quedan separadas de otra palabra por una unidad entrelazada después del entrelazado). Sin embargo, esto puede cambiar en el futuro. Como bien se sabe en el ámbito de la técnica, se obtiene protección contra picos de ruido de corta duración, entrelazando unidades (por ejemplo, bytes) de un cierto número, dependiente de la profundidad de entrelazado, de palabras de código (cada una de las cuales comprende varias unidades), comprendiendo cada palabra de código cierta cantidad de protección contra errores, de tal forma que es posible recuperar un número relativamente pequeño de unidades erróneas por palabra de código mediante el mecanismo de protección contra errores para recuperar por completo la palabra de código original (por ejemplo, si hay 5 unidades (o bytes) por palabra de código y el mecanismo de corrección de errores puede recuperar palabras de código que contienen una unidad errónea, una profundidad de entrelazado de 2 permitiría recuperar ambas palabras entrelazadas en caso de que un ruido haya provocado daños en dos unidades adyacentes dentro de un período de transmisión de dos palabras). El entrelazado ofrece protección contra ruidos impulsivos a costa de un incremento de latencia (y mayores requisitos de almacenamiento en memoria tampón del equipo de red).

Según un segundo aspecto de la presente invención, se ofrece un dispositivo de transceptor de agregación para utilizar en una red de acceso que comprende una pluralidad de conexiones de datos entre dispositivos de usuario final y el dispositivo de transceptor de agregación, en el que las conexiones se agregan para una posterior conexión a través de la red de acceso, comprendiendo el dispositivo: una memoria donde se almacena una pluralidad de perfiles diferentes, cada uno de los cuales especifica un conjunto de valores para un conjunto de uno o más parámetros asociados a cada conexión de datos, y, para cada conexión de datos, un monitor operativo para monitorizar el rendimiento de la conexión; un selector de perfil operativo para seleccionar uno de dichos perfiles almacenados que se va a aplicar a la conexión dependiendo del rendimiento de la conexión, y un aplicador de perfil operativo para aplicar el perfil seleccionado a la conexión de datos, en el que el monitor es operativo además para determinar el número de veces que la conexión se resincroniza, durante un período de tiempo determinado, y para calcular el número de resincronizaciones que se producen como resultado de un evento de alcance local que afecta a una pluralidad de líneas, y en el que el selector de perfil es operativo además para hacer caso omiso de cualquiera de dichas resincronizaciones cuando se selecciona un perfil para aplicar a la conexión de datos.

Según un tercer aspecto de la presente invención, se ofrece un dispositivo de gestión para utilizar en una red de acceso que comprende una pluralidad de conexiones de protocolo de línea de abonado digital entre dispositivos de usuario final y un dispositivo de transceptor de agregación, en el que las conexiones de protocolo de línea de abonado digital terminan, almacenándose en la red de acceso una pluralidad de perfiles diferentes, cada uno de los cuales especifica un conjunto de valores para un conjunto de uno o más parámetros asociados a cada conexión de datos, comprendiendo el dispositivo de gestión: un receptor para recibir, desde el dispositivo de transceptor de agregación, información acerca del rendimiento de las conexiones, un selector de perfil operativo para seleccionar uno de dichos perfiles almacenados que se va a aplicar a cada conexión respectiva dependiendo del rendimiento de la conexión; y un transmisor operativo para transmitir información que identifica el perfil seleccionado para cada respectiva conexión, en el que el selector de perfil determina la necesidad de seleccionar un perfil diferente para la respectiva conexión, y en el que el selector de perfil es operativo para descartar cualquier resincronización que se considera causada por un evento de alcance local, al seleccionar el perfil que se va a aplicar a una conexión.

Tanto el dispositivo de gestión como el dispositivo de transceptor de agregación (por ejemplo, el DSLAM o el MSAN) pueden determinar si se ha producido o no una resincronización como resultado de un evento de alcance local. Una de las ventajas de hacerlo en el dispositivo de gestión se pone de manifiesto cuando el dispositivo de gestión controla más de un dispositivo de transceptor de agregación que están situados dentro de un área geográfica común (y prestan servicio a los dispositivos de usuario final situados dentro de un área geográfica común que podría estar sujeta a un evento de alcance local común). Se considerará, por ejemplo, el caso de una tormenta eléctrica que está activa en un área que abarca y, por lo tanto, afecta a las líneas conectadas a dos transceptores de agregación diferentes aunque vecinos, ambos de los cuales son controlados por el mismo dispositivo de gestión. En dicho caso, el dispositivo de gestión puede tener en cuenta los datos de ambos dispositivos de transceptor de agregación al decidir si se ha producido o no un evento de tormenta eléctrica y, por consiguiente, si debe o no desestimar una serie de resincronizaciones. Una de las ventajas de hacer que la determinación sea tomada por el dispositivo de transceptor de agregación es que el procesamiento necesario para realizar esta determinación puede distribuirse entre un número de dispositivos de transceptor de agregación que es superior al número de dispositivos de gestión, puesto que cada dispositivo de gestión controla por término medio más de un dispositivo de transceptor de agregación.

Según un cuarto aspecto de la presente invención, se ofrece un dispositivo de recopilación de datos de dispositivos de transceptor de agregación para utilizar en una red de acceso que comprende una pluralidad de conexiones de protocolo de línea de abonado digital entre dispositivos de usuario final y una pluralidad de dispositivos de transceptor de agregación en los cuales las conexiones de protocolo de línea de abonado digital terminan, comprendiendo el dispositivo de recopilación de datos: un receptor para recibir, desde una pluralidad de dispositivos de transceptor de agregación, información acerca del rendimiento de las conexiones que terminan en cada uno de dichos transceptores de agregación, un detector de eventos de área operativo para procesar la información de rendimiento recibida para identificar las resincronizaciones que se consideran causadas por un evento de alcance local, y un transmisor operativo para transmitir información de rendimiento agregada a un dispositivo de gestión, modificándose cuando proceda la información de rendimiento agregada para tener en cuenta cualquier resincronización que se considere causada por un evento de alcance local.

La información de rendimiento agregada se agrega en la medida en que comprende información acerca de las líneas conectadas a una pluralidad de dispositivos de transceptor de agregación diferentes. La información agregada puede modificarse (cuando la información se refiere al rendimiento de un conjunto de conexiones durante un período en el que se determina que por lo menos algunas de esas conexiones se han visto afectadas por un evento de alcance local), ya sea simplemente descartando dichas resincronizaciones cuando se facilita información sobre el número de resincronizaciones experimentadas por cada conexión durante un período de tiempo particular indicado,

o incorporando información que indica las resincronizaciones que se consideran causadas por un evento de alcance local. La detección de eventos de alcance local en un dispositivo de recopilación de datos de una red de acceso que presenta una disposición jerárquica en la que hay más colectores de datos que dispositivos de gestión (de los cuales puede haber solo uno), pero menos colectores de datos que dispositivos de transceptor de agregación (por ejemplo, DSLAM y MSAN), presenta algunas de las ventajas tanto del segundo como del tercer aspectos de la presente invención; en concreto, el procesamiento está distribuido en cierta medida, puesto que hay muchos más dispositivos de recopilación de datos que dispositivos de gestión y, al mismo tiempo, cada colector de datos puede utilizar información de más de un dispositivo de transceptor de agregación para contribuir a identificar correctamente los eventos de alcance local que afectan a un conjunto de líneas distribuidas entre dos o más dispositivos de transceptor de agregación.

Según un quinto aspecto de la presente invención, se ofrece un detector de eventos de alcance local para utilizar en una red de acceso que comprende una pluralidad de conexiones de protocolo de línea de abonado digital entre dispositivos de usuario final y una pluralidad de dispositivos de transceptor de agregación en los que las conexiones de protocolo de línea de abonado digital terminan, comprendiendo el dispositivo unos medios para identificar la presencia de resincronizaciones en una pluralidad de las conexiones y para determinar si estas superan un número

o una proporción predeterminados dentro de un período de prueba predeterminado y, de ser así, para identificar un evento de alcance local como causa de dichas resincronizaciones. Un ejemplo de procedimiento para calcular el número de umbral adecuado por encima del cual se determina que es probable que se haya producido un evento de alcance local consistiría en obtener datos de resincronización para una agrupación predeterminada de líneas (por ejemplo, asociadas a un único dispositivo de agregación, tal como un DSLAM, o asociadas a una única central telefónica local tal como se califican en EEUU) durante un período de tiempo (por ejemplo, un día o una semana) considerado por los expertos libre de cualquier evento de alcance local (o de forma alternativa que excluye cualquiera de dichos eventos de alcance local producidos durante dicho período), y calcular el número medio de resincronizaciones por unidad de tiempo predeterminado (de duración relativamente corta, por ejemplo de 5 o 15

minutos, etc.), así como cierta medida de la desviación estándar respecto de la media, etc. Puede determinarse, pues, que el umbral se halla a un determinado número de desviaciones estándar respecto de la media (por ejemplo, más de dos desviaciones estándar por encima de la media).

En una forma de realización preferida, todas las resincronizaciones que tienen lugar dentro del período de prueba y en las líneas que se percibe que están dentro de un área geográfica probablemente afectada por el evento de alcance local se consideran resincronizaciones causadas por el evento de alcance local. En formas de realización sencillas preferidas, se parte del supuesto de que todas las resincronizaciones que tienen lugar en líneas que están conectadas al mismo dispositivo de transceptor de agregación dentro del período de prueba son causadas por el evento de alcance local. Este sistema se podría perfeccionar determinando también cualquier resincronización que se produzca durante el mismo período de prueba pero en líneas conectadas a otros dispositivos de transceptor de agregación, si se considera que estos otros dispositivos de transceptor son dispositivos vecinos. Preferentemente, la información sobre dispositivos de transceptor de agregación vecinos se almacena previamente y se calcula basándose en el conocimiento acerca de la localización de los dispositivos de transceptor de agregación (por ejemplo, los dispositivos de la misma central local se consideran dispositivos vecinos) o basándose en la localización de los dispositivos de usuario final (por ejemplo, si se sabe que dos dispositivos de usuario final cualesquiera conectados a dispositivos de transceptor de agregación diferentes están a cierta distancia predeterminada, por ejemplo 200 m, uno del otro, entonces los correspondientes dispositivos de agregación se consideran dispositivos vecinos, etc.).

Como se ha indicado anteriormente, un detector de eventos de alcance local según el quinto aspecto de la presente invención puede integrarse de forma ventajosa en cualquiera de los dispositivos que se utilizan dentro de una red de acceso, tal como un dispositivo de transceptor de agregación, un colector de datos o un dispositivo de gestión, especialmente un dispositivo que utilice un protocolo de línea de abonado digital dentro de por lo menos una parte de la red de acceso.

Otros aspectos de la presente invención se refieren a sistemas, dispositivos, programas informáticos y medios de soporte o medios de comunicación tales como los especificados en las reivindicaciones adjuntas, especialmente medios de soporte tangibles, tales como dispositivos de almacenamiento óptico (por ejemplo, discos compactos (CD) o DVD), o dispositivos de almacenamiento magnético, tales como discos magnéticos, o dispositivos de memoria no volátil de estado sólido.

Breve descripción de las figuras

Para permitir una mejor comprensión de la presente invención, a continuación se describirán, únicamente a título de ejemplo, formas de realización con referencia a los dibujos adjuntos, en los cuales:

la figura 1 es un diagrama de bloques esquemático que ilustra una red de telecomunicaciones que funciona de conformidad con un procedimiento según la presente invención;

la figura 2 es un diagrama de bloques esquemático que ilustra el dispositivo de gestión de la figura 1 en mayor detalle; y

la figura 3 es un diagrama de flujo que ilustra las etapas realizadas por el dispositivo de gestión de la figura 2 a fin de controlar el perfil DLM aplicado a las conexiones DSL en la red de la figura 1.

Descripción detallada de las formas de realización

La forma de realización principal descrita a continuación emplea un dispositivo de gestión 100 para realizar dos funciones principales: la provisión de un servidor de acceso remoto de banda ancha (BRAS) y la gestión dinámica de la línea (DLM). La provisión de BRAS se describe brevemente en la presente solicitud a fin de completar la información, aunque se describe en mayor detalle en las solicitudes de patentes internacionales en trámite GB 2006/002826 y GB 2006/002818, presentadas ambas el 28 de julio de 2006 y mencionadas anteriormente, que facilitan los detalles de los procedimientos preferidos de provisión de BRAS aplicables a la forma de realización principal.

En cuanto a la función DLM, esta constituye el centro de interés principal de la presente invención. En general, la función DLM es deseable en sistemas tales como el de la forma de realización principal, donde la velocidad descendente de las conexiones ADSL controladas por la velocidad del dispositivo de gestión se adapta a la velocidad más alta que la línea puede tolerar de 2 Mb a 8 Mb. En tales casos, debido a que las conexiones ADSL funcionan en sus límites máximos, estas son más sensibles al ruido que puede causar errores y resincronizaciones espontáneas. Debe observarse que esto es igualmente aplicable a otros tipos de conexiones DSL, tales como las conexiones SDSL VDSL, etc., así como a todos los tipos de ADSL, tales como ADSL 2 y ADSL 2 +.

En general, el papel de la función DLM del dispositivo de gestión es el de asegurar que las conexiones ADSL alcancen un correcto equilibrio entre la estabilidad de la línea y el rendimiento de la línea en términos de tasa de bits (o quizás, todavía más importante, la tasa a la cual un usuario puede recibir los datos deseados, una vez que se han reenviado los paquetes perdidos debido a errores, por ejemplo) y latencia. La función DLM lleva a cabo este cometido (en la presente forma de realización) recibiendo a diario datos de los colectores de datos de los DSLAM y procesando los datos recibidos (obsérvese que en la presente forma de realización solo hay un único dispositivo de gestión 100, varios colectores de datos, que en este caso son colectores de datos de DSLAM, puesto que los dispositivos de transceptor de agregación son DSLAM, y muchos DSLAM, que es el tipo de dispositivos de transceptor de agregación particular utilizado en la presente forma de realización. Debe tenerse en cuenta que cada colector de datos de DSLAM recopila información de una pluralidad de DSLAM. La función DLM (del dispositivo de gestión 100) puede aumentar o disminuir los márgenes de ruido (es decir, los márgenes de SNR de destino) y/o entrelazar niveles según las necesidades, estableciendo un nuevo perfil para cada conexión ADSL (mediante los sistemas de provisión disponibles para establecer los perfiles en los DSLAM). Estas funciones básicas se perfeccionan con la lógica para reducir al mínimo la renovación o la oscilación de perfiles (procurando estabilizar el perfil del DSLAM en cada conexión, en lugar de reaccionar ante los correspondientes cambios del entorno de la conexión, lo cual podría hacer cambiar el perfil estable máximo aplicable). En particular, en la presente forma de realización, la función también tiene por objetivo evitar una innecesaria degradación del perfil de un usuario desde de un perfil más agresivo a un perfil menos agresivo como consecuencia de cualquier resincronización (u otros parámetros de rendimiento normalmente negativos monitorizados por la función DLM, tales como errores detectados, etc.) causada por un evento de alcance local.

Forma de realización principal

Con referencia a la figura 1, se ilustra una visión global de una primera forma de realización de la presente invención. Un bucle de par de cobre 19 (que forma parte de la red de acceso que se extiende entre el equipo del cliente 10a, 10b, 10i, 10n y el BRAS 40) conecta el equipo del cliente 10a con un DSLAM 20a situado dentro de una central telefónica local (también conocida como oficina central en EEUU). Los DSLAM 20a, 20i, 20m separan el tráfico de voz normal y el tráfico de datos y envían el tráfico de voz a la red telefónica conmutada pública (PSTN) 70. El tráfico de datos se transmite a través de una red de modo de transferencia asíncrona (ATM) 30 que constituye el resto de la red de acceso 19, 20, 30 (en la presente forma de realización, la red ATM 30 es la red ATM Multi Service intranet Plataform (MSiP) de British Telecom (BT)). Conectado a la red ATM 30, se halla un servidor de acceso remoto de banda ancha (BRAS) 40, en el cual varios flujos de tráfico IP o circuitos ATM con origen (y destino) en varios proveedores de servicios (SP) 62, 64, 66 se agregan (y desagregan) a través de una red IP 50 (en este caso, la red IP Colossus de BT), que por sí misma puede ejecutarse a través de una o varias redes ATM. El equipo del cliente 10 contiene un filtro separador ADSL 18, un teléfono 12, un módem ADSL 16 y un ordenador 14.

En algunos casos, el primer salto de un paquete IP que se transmite desde el ordenador 14 hacia un ISP 62, 64, 66 será el BRAS 40; mientras que en otros casos el primer salto desde el punto de vista IP sobrepasará el BRAS 40.

En todos los casos, el módem del usuario final 16 crea una sesión de protocolo punto a punto (PPP) desde el módem hasta otro dispositivo de la red. Esta conexión es una conexión de extremo a extremo lógica que transmite el tráfico de los usuarios finales desde el módem hasta la red IP de destino.

En algunos casos (por ejemplo, en el producto Central+ de BT), la sesión PPP termina en el BRAS, y entonces se encamina directamente hacia Internet (por ejemplo, a través de una red IP troncal, tal como la red Colossus de BT).

En un ejemplo de configuración en el que la sesión PPP no termina en el BRAS 40, la sesión PPP termina en una "pasarela doméstica" situada en el borde de la red troncal, conectada al proveedor de servicios (SP). En otro ejemplo de configuración (tal como la del producto BT central), se utiliza un túnel del Protocolo de túnel de capa 2 (L2TP) para pasar a través del BRAS 40 hasta un BRAS de terminación que pertenece al SP, y el túnel L2TP tuneliza todas las sesiones PPP hacia la red del SP, para que sean procesadas de la manera deseada.

En todos los casos, el primer salto de IP es desde el usuario final hasta el BRAS de terminación (es decir, a través de la conexión PPP). Además, en todos los casos, el BRAS 40 se encarga de vigilar la cantidad de tráfico que fluye en sentido descendente (es decir, desde la red hacia el equipo del cliente) hacia cada línea conectada con el BRAS 40, para asegurar que no sobrepase la cantidad máxima dispuesta para esa línea. Esta vigilancia se realiza en la capa IP (donde el BRAS 40 termina una conexión PPP desde el equipo del cliente 10) o en un nivel inferior (por ejemplo, en la capa ATM) donde existe algún tipo de tunelado de capa sub-IP a través del BRAS 40.

La disposición de elementos 10, 19, 20, 30, 40, 50, 62, 64, 66 y 70 mencionada anteriormente es convencional. Sin embargo, además de esta disposición convencional, en la presente forma de realización se dispone de un colector de datos 25 y un dispositivo de gestión 100 que se comunica con el BRAS 40 y los DSLAM 20 (por medio del colector de datos 25). El funcionamiento detallado del dispositivo de gestión (especialmente en lo referente a su función DLM) se describirá en mayor detalle con referencia a las figuras 2 y 3. Sin embargo, en términos generales cabe decir que dicho dispositivo obtiene, desde el DSLAM 20 (por medio del colector de datos DSLAM 25), información acerca de la velocidad a la cual cada línea de abonado digital (DSL) se conecta al DSLAM e información acerca de eventos tales como errores y/o resincronizaciones detectados que se producen en la línea/conexión, y modifica el funcionamiento de los DSLAM en lo referente a la agresividad del perfil utilizado por un respectivo DSLAM para una respectiva conexión DSL. En la presente forma de realización, el colector de datos recopila los datos de métrica de rendimiento de una pluralidad de DSLAM y los agrega conjuntamente antes de enviarlos al dispositivo de gestión 100, ya sea de forma regular y periódica o bien previa petición del dispositivo de gestión 100. Además, en la presente forma de realización, cualquier orden de reasignación de perfil enviada desde el dispositivo de gestión 100 y destinada a un DSLAM particular también pasa por el colector de datos 25 (como parte del mecanismo OSS estándar descrito más adelante); no obstante, en otras formas de realización, dichas órdenes de reasignación de perfil podrían enviarse directamente al DSLAM en cuestión (o un dispositivo de transceptor de agregación diferente) o por medio de algún mecanismo alternativo.

En la presente forma de realización, el dispositivo de gestión 100 se comunica con cada colector de datos 25 mediante el protocolo de llamada a procedimiento remoto, mientras que cada colector de datos se comunica con un DSLAM conectado mediante el protocolo SNMP (Simple Network Messaging Protocol).

Como se representa en la figura 2, el dispositivo de gestión 100 comprende dos partes funcionales principales: una función de provisión de BRAS o de control de BRAS 120 y una función de gestión dinámica de la línea (DLM) 110.

La función de provisión de BRAS 120 procesa una parte de la información recibida desde los DSLAM para determinar la velocidad de conexión constante alcanzada por cada DSL. Si se determina que esta velocidad constante se ha incrementado como consecuencia del establecimiento de conexiones recientes a velocidad más alta, se ordena al BRAS que permita mayores flujos de tráfico a través de dicha DSL. Por otro lado, si se detecta que una velocidad de conexión particular está por debajo del valor constante almacenado, el valor constante se reduce hasta la velocidad de conexión actual y se informa de inmediato al BRAS acerca del nuevo valor de velocidad constante para que, de ese modo, el BRAS no permita que fluya más tráfico hacia la DSL del que esta es capaz de procesar en ese momento.

En las solicitudes internacionales en trámite GB 2006/002826 y GB 2006/002818, pueden consultarse detalles exactos acerca de algunos de los algoritmos que la función de control de BRAS 120 del dispositivo de gestión 100 puede utilizar para calcular la velocidad constante en la presente forma de realización. Sin embargo, debe observarse que el propósito de estos algoritmos es el de asegurar que el usuario reciba los datos a la velocidad más alta que su DSL sea capaz de alcanzar de forma sostenida sin necesidad de reconfigurar el BRATS cada vez que la DSL se conecta a una nueva velocidad máxima. Al mismo tiempo, los algoritmos tratan de asegurar que, si una DSL se conecta a una velocidad que está por debajo de la velocidad que el BRAS tiene configurada actualmente para permitir el paso de datos por dicha DSL, el BRAS se reconfigure rápidamente para evitar la sobrecarga del DSLAM.

Los detalles del algoritmo particular empleado en la presente forma de realización por la función DLM se exponen más adelante. En términos generales, sin embargo, una subfunción de recepción de datos del DLM recibe diariamente un nuevo archivo desde cada colector de datos 25 (denominado también gestor de elementos) que contiene hasta 96 intervalos de tiempo (período de 15 minutos) por conexión DSL y día, junto con información sobre la política o el nivel de estabilidad asociados a cada conexión. Estos datos se utilizan en una subfunción de análisis del DLM para determinar si es necesario realizar algún cambio en el perfil de DSLAM para estabilizar el servicio del usuario final y satisfacer la respectiva política o nivel de estabilidad asociados a la conexión. Si se requiere algún cambio, una subfunción de salida del DLM envía una petición al sistema Operational Support System (OSS) de la red de acceso para el cambio del perfil aplicado a la línea. La manera precisa en la que se realiza este procedimiento dependerá de los detalles del sistema OSS de la red de acceso particular y no concierne a la presente invención; por consiguiente, no se describirá.

Cada una de las subfunciones DLM mencionadas anteriormente se implementa mediante componentes de procesador de ordenador estándar que funcionan de conformidad con unos módulos de código de software almacenados en una memoria 112 que forma parte de la función DLM 110; en particular, un módulo de código de recepción de datos DLM 114 (ENTRADA DE DATOS) causa la implementación de la subfunción de recepción dedatos DLM, un módulo de código de análisis DLM 116 (ANÁLISIS DE DATOS) causa la implementación de la subfunción de análisis DLM y un módulo de código de salida DLM 118 (SALIDA DE DATOS) causa la implementación de la subfunción de salida DLM. Además, la memoria 112 también almacena el conjunto de datosde política de estabilidad 115 (POLÍTICAS DE ESTABILIDAD) que contiene el nivel o la política de estabilidad asociados a cada conexión DSL controlada por el dispositivo de gestión. Asimismo, en la presente forma derealización, la memoria 112 también almacena un módulo de cálculo de resincronizaciones forzadas 117 (CÁLCULO DE RESINCRONIZACIONES FORZADAS) para implementar una subfunción de cálculo del número de resincronizaciones de cada línea en cada lote de datos, provocadas por cualquier tipo de error, etc. en la conexión y no provocadas por una acción del usuario (por ejemplo, el apagado o la desconexión del módem DSL). Esta subfunción de cálculo de resincronizaciones forzadas se describe en mayor detalle más adelante. La memoria 112 también almacena un módulo de cálculo de eventos de alcance local 119 para implementar una subfunción de cálculo de eventos de alcance local, en la que se determina que algunas de las resincronizaciones indicadas a la función DLM han sido provocadas por un evento de alcance local y, por consiguiente, descartadas por la subfunción de análisis de datos. Esta subfunción de cálculo de eventos de alcance local se describe en mayor detalle más adelante.

La principal fuente de datos de entrada para la función DLM es un archivo diario de cada gestor de elementos, que facilita un informe agregado de la actividad de cada línea durante las últimas 24 horas. Esto determina que los cambios en el perfil del DSLAM se apliquen con una frecuencia no superior a uno cada 24 horas, lo cual resulta ventajoso ya que evita la posibilidad de que el DSLAM se reconfigure cada vez que se resincroniza una línea. No obstante, la función DLM recibe además datos de entrada que especifican un nivel de estabilidad para cada línea. En la presente forma de realización, estos datos se reciben desde una base de datos, en la que el operador entra los datos manualmente como parte del proceso de provisión de una nueva conexión DSL, y se almacenan dentro del conjunto de datos de políticas de estabilidad 115 de la memoria DLM 112. Por lo tanto, la finalidad de la presente forma de realización es que cuando un cliente solicite una conexión DSL se le ofrezcan diferentes niveles de estabilidad (que serán los más adecuados para ciertos tipos de actividades diferentes); así pues, los clientes cuya pretensión mayoritaria sea utilizar la conexión para la emisión de vídeo en tiempo real se beneficiarán de una conexión estable, mientras que los clientes que mayormente utilicen la conexión para descargar archivos de gran tamaño, etc., en lugar de beneficiarse de niveles de estabilidad muy altos, se beneficiarán de una tasa de bits superior. De forma alternativa, en lugar de ofrecer este recurso a cada usuario final, podría ofrecerse a los clientes minoristas (es decir, proveedores de servicios) del operador de servicios de red (es decir, un operador de red mayorista) la opción de seleccionar un nivel de estabilidad en representación de sus clientes y venderla a sus clientes (usuario final) como una oferta de producto "especializado".

Sin embargo, en formas de realización alternativas, el nivel de estabilidad podría actualizarse de manera más dinámica previa petición del usuario. En un ejemplo de forma de realización, podría disponerse de un servidor web para recibir las peticiones de cambio de nivel de estabilidad formuladas por los usuarios (tal vez con una frecuencia máxima de peticiones permitidas por usuario, por ejemplo, no superior a una por hora o una por día, etc.), hecho que podría determinar que la función DLM reejecutara tan pronto como fuera posible el proceso de comparación para esa línea con el nivel de estabilidad recién solicitado y, si tras la comparación se considerara adecuado, se realizara la transición hacia un nuevo perfil también lo antes posible, para que de ese modo el usuario percibiera una respuesta bastante dinámica a la petición de cambio de nivel de estabilidad.

Cada vez que se examina una línea para comprobar si debe cambiarse su perfil (en la presente forma de realización, una vez cada 24 horas como parte de una función de procesamiento por lotes), se lee el correspondiente nivel de estabilidad asociado a esa línea y a continuación se establecen los valores de umbral para esa línea en función del nivel de estabilidad asociado a la respectiva línea. Entonces, se procesan los datos del archivo diario, y los datos de la respectiva línea que se analiza se comparan con los valores de umbral fijados para esa línea dependiendo del nivel de estabilidad asociado a la línea. Si la comparación indica la necesidad de efectuar una transición, entonces se genera una correspondiente orden para que el sistema OSS efectúe la transición.

El perfil del DSLAM presenta dos parámetros, el margen de destino y el modo de ejecución (este último permite el uso de entrelazado), que se ajustan en los diversos perfiles disponibles para la función DLM y entre los cuales se puede seleccionar a fin de mejorar la estabilidad de la línea o mejorar la tasa de bits o la baja latencia de conexión. El perfil de línea predefinido que se aplica inicialmente a todas las líneas presenta un margen de destino de 6 dB y el entrelazado inhabilitado (a menudo se dice que se hallan en "modalidad Fast"). El cambio de estos parámetros se basa en dos métricas de rendimiento que, en la presente forma de realización, son los errores (en particular, errores ocasionados por infracciones de código en esta forma de realización) y reacondicionamientos (es decir, resincronizaciones).

El número de errores y reacondicionamientos se normaliza con respecto al tiempo productivo (tiempo sincronizado total durante el período) y se procesa para descartar los reacondicionamientos provocados por el usuario y los errores y reacondicionamientos provocados por eventos de alcance local a fin de generar la verdadera métrica de rendimiento utilizada para determinar la estabilidad de la línea. La normalización asegura que un número determinado de errores que se producen en un corto período de tiempo productivo se traten de forma distinta al mismo número de errores en un período de tiempo productivo mucho más largo; así pues, por ejemplo, 100 errores en 10 horas de tiempo productivo tras normalización son (con bastante buen criterio) muy diferentes a 100 errores en 1 minuto de tiempo productivo. La normalización se realiza calculando un tiempo medio entre errores o resincronizaciones. Además, en la presente forma de realización, el parámetro de reacondicionamiento también se procesa, antes de utilizarlo como métrica del rendimiento de estabilidad, descontando el número de resincronizaciones que se consideran causadas por el usuario, antes de calcular el tiempo medio entre resincronizaciones. De modo parecido, el número de reacondicionamientos y el número de errores también se procesan antes de utilizarlos como métrica de la estabilidad, descontando el número de errores y/o resincronizaciones que se consideran causados por un evento de alcance local.

En la presente forma de realización, se utiliza el siguiente procedimiento, especificado Conforme al siguiente pseudocódigo, para identificar los reacondicionamientos que se consideran causados por un evento de usuario.

[Obsérvese que en lo sucesivo se supone que se ha generado y rellenado una matriz uptimes[], en la que cada elemento de la matriz corresponde a uno de los 96 bins de 15 minutos por período de 24 horas (en la presente forma de realización) para una conexión DSL particular. El tipo de matriz (números de 1 bit, enteros de 1 byte, enteros cortos, números flotantes, etc.) es indiferente, siempre y cuando los elementos de la matriz que sean cero indiquen un tiempo productivo igual a cero en el correspondiente bin, y los valores no cero indiquen que existe cierta cantidad de tiempo productivo en dicho bin, y si se utilizan valores de 1 bit pueda considerarse que estos adoptan el valor "verdadero" (true) o "falso" (false), en cuyo caso deberá utilizarse uno de esos para indicar un tiempo productivo igual a cero en lugar de cero. Sin embargo, en la presente forma de realización, cada

5 elemento comprende un entero corto entre 0 y 900 que indica el número de segundos de tiempo productivo en el respectivo bin de 15 minutos (es decir, 900 segundos).]

*** Comment - method to count number of unforced re-trains in a 24-hour period for a given connection

10 SET unforcedretrains = 0 FOR (i = 0 to 95) ( IF (uptimes[i] = 0 AND uptimes[i+1] != 0) THEN unforcedretrains++ ) RETURN unforcedretrains.

15 El pseudocódigo anterior básicamente indica que debe comprobarse cada bin y determinar si presenta un tiempo productivo cero mientras que el subsiguiente bin presenta un tiempo productivo no cero (es decir, debe detectarse una transición desde un bin sin tiempo productivo hasta un bin con tiempo productivo), e incrementar, para cada una de dichas transiciones, la variable "unforcedretrains" que lleva la cuenta del total del número de (supuestas)

20 resincronizaciones causadas por el usuario.

En la presente forma de realización, se utiliza el siguiente procedimiento, especificado Conforme al siguiente pseudocódigo, para identificar los reacondicionamientos y errores que se consideran causados por un evento de alcance local:

25 [Obsérvese que en lo sucesivo se supone que se han generado y rellenado tres matrices de dos dimensiones uptimes[96,n], retrains[96,n] y errors[96,n], cada una de las cuales presenta n por 96 posiciones de [0,0] a [95,n1], en las que cada elemento de la matriz corresponde a uno de los 96 bins de 15 minutos por período de 24 horas (en la presente forma de realización) para cada una de las n conexiones DSL establecidas con un DSLAM

30 particular, y en las que cada elemento de cada matriz contiene un valor binario que adopta un valor cero o un valor uno, cada valor de la matriz uptimes se establece en cero para indicar cero tiempo productivo en el correspondiente bin para la correspondiente conexión, y en uno para indicar la presencia de por lo menos cierta cantidad de tiempo productivo en ese bin, cada valor de la matriz retrains se establece en cero en ausencia de reacondicionamientos en ese bin, y en uno en caso contrario, y cada valor de la matriz errors se establece en

35 cero en ausencia de errores en ese bin, y en uno en caso contrario. También se ha generado, aunque no rellenado, una matriz binaria unidimensional denominada areaWideEvents[96] que presenta 96 posiciones de 0 a 95, cada una de las cuales adopta un valor cero si se considera que no se produce ningún evento de alcance local en ese intervalo de tiempo, y un valor uno en caso contrario.]

40 *** Comment - method to identify area event timeslots in a 24-hour period for a given DSLAM.

El pseudocódigo anterior básicamente indica que deben examinarse todos los bins de cada intervalo de tiempo y 45 sumar el número total de conexiones del intervalo de tiempo que presentan tiempo productivo, el número total de conexiones que experimentan un reacondicionamiento en el intervalo de tiempo y el número total de conexiones que presentan tiempo productivo y experimentan un error en el intervalo de tiempo, y a continuación determinar si para ese intervalo de tiempo la proporción de líneas que presentan tiempo productivo y también experimentan un reacondicionamiento sobrepasa el 20% o si la proporción de líneas que presentan tiempo productivo y experimentan un reacondicionamiento sobrepasa el 10% y la proporción de líneas que presentan tiempo productivo y experimentan errores sobrepasa el 50%, y para cada uno de dichos intervalos de tiempo se registra un evento de alcance local en la matriz de eventos de alcance local para indicar que este se ha producido. Debe observarse que es posible utilizar diferentes valores para los porcentajes, o que se podría identificar un evento de alcance local basándose exclusivamente en los errores sin tener en cuenta el número de reacondicionamientos que se detectan, o que se podrían utilizar números absolutos en lugar de números proporcionales, etc., dependiendo de las circunstancias particulares de la red de acceso. En particular, es preferible que los valores utilizados para los umbrales de porcentaje en las comparaciones anteriores se generen basándose en la determinación del valor medio y el valor de desviación estándar para estas cantidades (por ejemplo, las proporciones de reacondicionamientos por conexiones operativas y de errores por conexiones operativas y combinaciones de ambas, etc.). Si se utiliza el análisis basado en el valor medio y la desviación estándar, tal vez resulte más fácil realizar una primera comparación con referencia a la proporción de reacondicionamientos por conexión operativa y, a continuación, realizar otra por separado con referencia solo a la proporción de errores por conexión operativa independientemente de la proporción de reacondicionamientos por conexión operativa.

Cualquier reacondicionamiento que se produzca en los intervalos de tiempo que la matriz areaWide Events señala como resultantes de un evento de alcance local se resta del número total de reacondicionamientos para cada conexión en ese período de 24 horas junto con el número de reacondicionamientos no forzados detectados para dicha conexión a fin de obtener un número estimado de reacondicionamientos forzados no causados por un evento de alcance local durante el período de 24 horas, y a continuación el tiempo productivo total en segundos se divide por el número estimado de reacondicionamientos forzados no causados por un evento de alcance local para obtener el tiempo medio estimado entre reacondicionamientos en segundos. En la presente forma de realización, la matriz uptimes[] almacena el número de segundos de tiempo productivo en cada bin, para facilitar de ese modo la obtención del tiempo productivo total para la conexión simplemente sumando los valores de todos los elementos de la matriz. También se calcula de manera similar el tiempo medio entre errores, tras restar cualquier error causado por un evento de alcance local.

Una vez que se ha calculado la métrica que se va a utilizar para determinar la estabilidad de la línea, se comprueban los umbrales, etc. tal como se describe en mayor detalle más adelante y, si se considera necesario o deseable, se efectúa un cambio de perfil.

En general, si se considera necesario cambiar a un perfil menos agresivo, preferentemente se cambia a un perfil entrelazado en lugar de incrementar el margen de destino. Inicialmente, se establece un perfil entrelazado con un correspondiente margen de destino que es igual al del perfil de modalidad de canal rápido anterior (es decir, la modalidad fast de 6 dB hará la transición hacia la modalidad de canal entrelazado de 6 dB).

Si un cliente ha optado por renunciar a la opción de aplicar entrelazado (por ejemplo, debido a que prefiere una baja latencia a una tasa de bits máxima, como suele ser el caso de clientes que son jugadores en línea o usuarios de VOIP o videoconferencia), entonces la transición solo se realiza entre los perfiles de modalidad fast (únicamente se varía el margen de destino). Esto limita claramente la capacidad del proceso DLM.

Antes de realizar una transición, se comprueba la velocidad de la línea para asegurar que esta sea capaz de realizar la transición a un nuevo perfil sin sufrir una caída de la tasa de bits tan drástica como para situarla por debajo de una tasa de bits mínima aceptable predeterminada. La transición solo se realiza si existe cierto nivel de confianza en que la línea será capaz de prestar el servicio encima de esta tasa mínima aceptable una vez que se haya aplicado el nuevo perfil. Por ejemplo, en la presente forma de realización, solo se efectúa una transición a un perfil de margen de ruido más alto si la tasa de bits actual es aproximadamente 800 kb/s superior a la tasa de umbral de fallos (FTR). La FTR representa la tasa de bits mínima aceptable determinada por el operador de red. En la presente forma de realización, el operador de red es un mayorista de servicios de red que presta los servicios a minoristas de red, o proveedores de servicio, quienes a su vez prestan los servicios a los clientes, la velocidad máxima estable es un parámetro determinado por el operador de red mayorista y facilitado al proveedor de servicios como una indicación de la capacidad calculada de la línea, y la FTR está relacionada con la MSR aunque adopta un valor inferior y se utiliza para generar un informe de fallos si la velocidad de conexión cae por debajo de la FTR, ya que esto indicaría que la línea está funcionando a una velocidad significativamente inferior a la que se considera capaz de tolerar. Si la línea es inestable y todavía no puede realizar la transición porque se situaría por debajo de su tasa de bits mínima aceptable (es decir, la FTR), entonces esta circunstancia se marca para su análisis más detenido. En la presente forma de realización, la FTR se establece inicialmente en 2 Mbs y, a continuación, se restablece en el 80% de la velocidad máxima estable detectada por la red durante los primeros 10 días de funcionamiento de la DSL en su modalidad de adaptación a la velocidad.

Cuando una línea es incapaz de sincronizarse, se realiza una transición a un margen de destino inferior. Si esto significa volver a un estado inestable previo, entonces se coloca una marca para un análisis más detenido, ya que la línea no se ha estabilizado correctamente (aunque no se halla en el margen de destino máximo). La línea vuelve al estado inestable anterior para poder prestar cierto nivel de servicio al cliente mientras es objeto de dicho análisis.

Cuando una línea es incapaz de sincronizarse aunque se halla en el margen de destino más bajo, se coloca una 5 marca para un análisis más detenido. Por ejemplo, puede ser que la línea no admita el servicio deseado o puede ser que la línea esté en mal estado.

Análogamente, cuando una línea sigue siendo inestable en el margen de destino máximo posible, se coloca una marca para un análisis más detenido. Por ejemplo, la línea puede estar en mal estado.

10 Si una línea es completamente estable, entonces, en general, la función DLM cambia la línea a un margen (o profundidad de entrelazado) de destino más bajo, para incrementar la capacidad disponible (o reducir la latencia) de la línea (recuérdese que 3 dB = 800 kb/s). No obstante, estas transiciones se realizan con cuidado para evitar que se produzcan cambios ascendentes y descendentes frecuentes en el margen (o profundidad de entrelazado) de

15 destino. Por lo tanto, si una línea ha cambiado previamente de un perfil de margen de destino más bajo y más agresivo (o menos entrelazado) al perfil de margen de destino (y profundidad de entrelazado) actual, para efectuar una transición de regreso al perfil de margen de destino (o profundidad de entrelazado) más bajo, deberá esperar un tiempo considerablemente más largo (por ejemplo, una semana o un mes) que el que esperaría si no hubiera cambiado previamente desde el perfil de margen de destino (o profundidad de entrelazado) más bajo.

20 En la presente forma de realización, se ofrece un proceso manual que permite la transición entre cualquier perfil de línea (por ejemplo, la transición directa de la modalidad de canal rápido de 3 dB a la modalidad de canal entrelazado de 15 dB es posible mediante intervención manual).

25 En la presente forma de realización, las líneas, que se han marcado para un análisis más detenido se reparan de forma dinámica con la intención de que puedan repararse antes de que se genere cualquier informe de fallos.

Las peticiones de reasignación de perfil para cambiar a un perfil menos agresivo pueden producirse diariamente. Las decisiones de reasignación de perfil para que las líneas estables cambien a un perfil más agresivo a fin de

30 incrementar la capacidad global se toman durante un período de tiempo más prolongado (que generalmente se incrementa con el número de veces que la línea se ha desviado previamente del perfil de destino debido a la falta de estabilidad) tal como se ha descrito en el párrafo anterior.

En la presente forma de realización, cada línea se clasifica mediante la primera subfunción de la función DLM en

35 una de cuatro categorías diferentes dependiendo del número normalizado de errores y/o resincronizaciones indicadas a la función de DLM en el archivo masivo. Las categorías corresponden a muy deficiente, deficiente, aceptable y muy estable.

El flujo básico del proceso DLM se representa en la tabla 1 siguiente.

40 En la presente forma de realización, la progresión general a través de los perfiles representados en la tabla 1 tiene lugar como se describe a continuación. Si se va a cambiar una línea a un perfil más estable, el primer cambio será al perfil con el mismo margen de destino pero en modalidad de canal entrelazado en lugar de modalidad fast. Si la línea ya se halla en modalidad de canal entrelazado, entonces la línea cambiará al siguiente perfil de margen de destino más alto también en modalidad de canal entrelazado. Si se va a cambiar la línea en la dirección de incremento de la capacidad, se mantiene la misma modalidad (ya sea, canal rápido o canal entrelazado) pero se cambia al siguiente perfil de margen de destino más bajo, a menos que la línea se halle ya en el margen de destino mínimo en modalidad de canal entrelazado, en cuyo caso se cambia al perfil de margen de destino mínimo en modalidad fast.

En la segunda subfunción de la función DLM, una línea clasificada como muy deficiente se desplaza de inmediato dos pasos en la dirección de incremento de la estabilidad (por ejemplo, de perfil de canal rápido de 6 dB pasaría a canal entrelazado de 9 dB, de canal entrelazado de 6 dB pasaría a canal entrelazado de 12 dB, etc.). Una línea clasificada como deficiente se desplaza de inmediato un paso (aunque con una prioridad más baja que la de reasignación de perfil de cualquier línea clasificada como muy deficiente) en la dirección de incremento de la estabilidad (por ejemplo, de canal rápido de 6 dB a canal entrelazado de 6 dB o de canal entrelazado de 9 dB a canal entrelazado de 12 dB). Una línea clasificada como aceptable se mantiene en el perfil actual (es decir, no se emprende ninguna acción). Una línea clasificada como muy estable se desplaza un paso (si los otros requisitos para evitar oscilaciones, etc. también se cumplen) en la dirección de incremento de la capacidad (por ejemplo, de canal rápido de 6 dB a canal rápido de 3 dB, de canal entrelazado de 9 dB a canal entrelazado de 6 dB o de canal entrelazado de 3 dB a canal rápido de 3 dB).

En la presente forma de realización, cada línea se procesa una vez cada 24 horas para determinar cómo debe clasificarse y, por lo tanto, si debe seleccionarse un nuevo perfil para la línea. Para evitar oscilaciones frecuentes entre perfiles adyacentes, se utiliza un contador de retardo bueno y un contador de retardo malo para establecer la velocidad a la cual se reasigna el perfil de la línea. Así pues, cada vez que una línea se clasifica como buena, el contador de retardo bueno se incrementa (y el contador de retardo malo se decrementa), y hasta que el contador de retardo bueno no alcanza el umbral de bueno (que, en la presente forma de realización, se fija en 13) no se hace ninguna petición al sistema OSS para aplicar al perfil un incremento de un paso hacia un nivel más agresivo, y después se restablecen los contadores de retardo. Además, cada vez que se clasifica una línea como deficiente, se incrementa un contador de retardo deficiente (y el contador de retardo bueno se reduce), y hasta que el contador de retardo deficiente no alcanza el umbral de deficiente (que, en la presente forma de realización, se establece en 3), no se aplica al perfil un decremento de un paso hacia un nivel menos agresivo. Los contadores de retardo no se decrementan nunca por debajo de 0, de tal manera que aunque una línea haya experimentado un número de días "buenos" (y el contador de retardo deficiente se haya decrementado hasta cero tras, por ejemplo, cinco días buenos seguidos), bastarán 3 días consecutivos de comportamiento deficiente de la línea para que se alcance el umbral de deficiente y se provoque una reasignación de perfil. Asimismo, se utiliza un duplicador de retardo para incrementar el retardo (es decir, incrementar el umbral de bueno) necesario para permitir que una línea que ha cambiado de un nivel de perfil más agresivo a un nivel de perfil menos agresivo vuelva a realizar la transición de regreso al nivel más agresivo. Por consiguiente, el duplicador de retardo se incrementa (en la presente forma de realización, hasta un máximo de 5) siempre que se reasigna la línea a un nivel menos agresivo, y a continuación se restablecen los retardos (como en el caso en el que la línea se reasigna a un nivel más agresivo). El restablecimiento de los retardos tiene lugar de conformidad con las fórmulas siguientes:

UMBRAL DE BUENO = UMBRAL DE BUENO PREDEFINIDO * 2 EXP (DUPLICADOR DE RETARDO) CONTADOR DE RETARDO DEFICIENTE = CONTADOR DE RETARDO BUENO = 0

En la presente forma de realización el UMBRAL DE BUENO PREDEFINIDO se establece en 13 (es decir, equivalente a 14 días), el RETARDO DEFICIENTE PREDEFINIDO se establece en 3 (es decir, equivalente a 3 días) y el DUPLICADOR DE RETARDO se establece en 0, de tal manera que el retardo bueno inicial es 13, pero cada vez que el perfil de la línea efectúa una transición a un perfil menos agresivo, el DUPLICADOR DE RETARDO se incrementa hasta que se efectúan 5 de dichas transiciones, y cada vez que el RETARDO se restablece adopta un valor de 448 (es decir, equivalente a 14 meses aproximadamente). En la presente forma de realización, si la política

o el nivel de estabilidad de un usuario cambia, el duplicador de retardo se restablece nuevamente en cero; además, el operador puede restablecer manualmente el duplicador de retardo e incluso el contador de retardo para hacer frente a circunstancias excepcionales.

Las prestaciones específicas de la función DLM en la presente forma de realización, que permiten que diferentes líneas funcionen a diferentes niveles de estabilidad de conformidad con las políticas de estabilidad fijadas para cada línea, se describen a continuación con referencia a la figura 3. En resumen, en la presente forma de realización, antes de que la DLM aplique la función de clasificación a una línea particular, se determina su nivel de estabilidad asociado para que de ese modo la clasificación se base en los valores de umbral asociados al respectivo nivel de estabilidad, presentando cada nivel de estabilidad un conjunto diferente de valores de umbral asociados para utilizar en la función de clasificación. Por lo tanto, en la etapa S5 se obtiene el nivel de estabilidad de la línea particular que se va a clasificar junto con los datos de retardo almacenados para la línea (es decir, el valor actual para el contador de retardo, RETARDO, que como se ha mencionado anteriormente se establece inicialmente en un valor de 3, y el valor actual del duplicador de retardo, DUPLICADOR DE RETARDO, que inicialmente se establece en un valor de 0).

El proceso inicia después la etapa S10, en la que se obtienen los valores de umbral asociados al nivel de estabilidad 5 hallado en la etapa S5, para utilizarlos en el resto del proceso y, a continuación, el proceso continúa por la etapa S15.

En la etapa S15, la función DLM obtiene los datos de errores y resincronizaciones actuales que se han recibido en relación con la línea que se está analizando. Estos se obtienen mediante lectura del archivo de datos diario que se

10 envía cada día a la función DLM tras el procesamiento descrito anteriormente para tener en cuenta (descartar) cualquier error y reacondicionamiento causado por las acciones del usuario o como consecuencia de un evento de alcance local como los descritos anteriormente. A continuación, el proceso continúa por la etapa S20.

La etapa S20 es la encargada de clasificar realmente las líneas en una de cuatro categorías diferentes: muy

15 deficiente, deficiente, correcta y buena. Con este propósito, ambas de las métricas utilizadas en la presente forma de realización, en concreto el número de errores detectados, tanto en el módem del usuario como en el módem de red del DSLAM, y el número de resincronizaciones registradas por el DSLAM, se comparan (tras la normalización descrita anteriormente) con unos correspondientes umbrales diversos cuyos valores se fijan Conforme al nivel de estabilidad asignado a la línea. La tabla 2 siguiente expone los diversos umbrales utilizados en la presente forma de

20 realización.

Tabla 2

Estabilidad

Métrica Muy deficiente Deficiente Correcta Buena

Agresivo

Reacondicionam. >10 por hora mtb<3600 mtb<8640 mtb�8640

Agresivo

Errores - mtb<10 mtb<8640 mtb�8640

Normal

Reacondicionam. >10 por hora mtb<7200 mtb<8640 mtb�8640

Normal

Errores - mtb<300 mtb<8640 mtb�8640

Estable

Reacondicionam. >10 por hora mtb<28800 mtb<86400 mtb�86400

Estable

Errores - mtb<1000 mtb<28800 mtb�28800

25 En la tabla 2, "mtb" representa "tiempo medio entre" y por lo tanto corresponde a la métrica normalizada calculada dividiendo el tiempo total en segundos durante el cual la respectiva línea ha permanecido sincronizada en el período de monitorización de las últimas 24 horas por el número de reacondicionamientos o errores registrados en dicho período. Para todos los casos, si en la presente forma de realización se producen más de 10 reacondicionamientos en cualquier período de una hora, se considera que la línea es muy deficiente, independientemente del número de

30 errores registrados. Para las líneas que funcionan a un nivel de estabilidad agresivo, si el tiempo medio entre reacondicionamientos es inferior a uno por hora, (es decir es igual a 3600 segundos) (por ejemplo, 6 reacondicionamientos en menos de 5 horas de "tiempo productivo") o si el tiempo medio entre errores es inferior a uno por cada 10 segundos de tiempo productivo, la línea se considera deficiente. A su vez, si el tiempo medio entre reacondicionamientos es inferior a uno por cada 2,4 horas (pero más de uno por hora) o el tiempo medio entre

35 errores es inferior a uno por cada 2,4 horas (pero más de uno por cada 10 segundos), la línea se considera correcta, mientras que si el tiempo medio entre reacondicionamientos es superior o igual a uno por cada 2,4 horas o si el tiempo medio entre errores es superior o igual a uno por cada 2,4 horas, la línea se considera buena. La tabla 2 anterior permite deducir con claridad y de la misma manera los umbrales para los otros niveles de estabilidad.

40 En una forma de realización alternativa, los niveles de estabilidad podrían ser operativos para que, en el nivel de estabilidad más agresivo, la función DLM tratara de mantener las pérdidas de sincronización por debajo de 12 por período de 24 horas (incluidos el apagado de módems y encaminadores que cuentan como pérdida de sincronización) y mantener la línea libre de errores durante el 98,3% (59/60 segundos) del tiempo productivo medido en un período de 24 horas; en el nivel de estabilidad normal, la función DLM tratara de mantener las pérdidas de

45 sincronización por debajo de 6 por período de 24 horas y mantener la línea libre de errores durante el 99,8% (599/600 segundos) del tiempo productivo medido en un período de 24 horas y, en el nivel de estabilidad estable, la función DLM tratara de mantener las pérdidas de sincronización por debajo de 3 por período de 24 horas y mantener la línea libre de errores más del 99,98% (5999/6000 segundos) del tiempo productivo medido en un período de 24 horas.

50 Una vez que en la etapa S20 se ha clasificado la línea de conformidad con la tabla 2, el proceso continúa por la etapa S25 en la que se determina si la línea se ha clasificado como "deficiente/muy deficiente", "correcta" o "buena". Si se ha clasificado la línea como deficiente/muy deficiente, el proceso continúa por la etapa S30 en la que se determina si la línea se ha clasificado como muy deficiente o deficiente. Si en la etapa S30 se determina que la línea

55 se ha clasificado como muy deficiente, el proceso continúa por la etapa S35, en la que se formula una petición OSS para que se aplique, al perfil DLM de la línea, una transición de 2 pasos en la dirección de reducción de agresividad, siempre y cuando este se halle por lo menos dos pasos encima del nivel de agresividad mínima (que en la presente forma de realización es "canal entrelazado de 15dB" como puede observarse claramente en la tabla 1), y de no ser así, se efectúe solo la transición directa hacia este nivel de agresividad mínima. En cambio, si la línea ya se halla en ese nivel de agresividad mínimo, permanece en el mismo, aunque se añade una marca de fallo para el sistema a fin de atraer la atención del personal técnico. Una vez terminada la etapa S35, el procedimiento continúa por la etapa S60.

Si en la etapa S30 se determina que la línea se ha clasificado como deficiente, el proceso continúa por la etapa S40, en la que se determina si el contador de retardo deficiente es inferior al umbral de deficiente. De ser así, el procedimiento continúa por la etapa S45, en la que el contador de retardo deficiente se incrementa (en una unidad) y, a continuación, el procedimiento inicia la etapa S50, en la que el contador de retardo bueno se decrementa (en una unidad). Una vez acabada la etapa S50, el proceso termina (para la respectiva línea). Si en la etapa S40 se determina, por otro lado, que el contador de retardo es igual a (o sobrepasa) el umbral de deficiente, el procedimiento continúa por la etapa S55, en la que se formula una petición OSS para que se aplique, al perfil DLM de la línea, una transición de 1 paso en la dirección de reducción de agresividad, siempre y cuando este no se halle ya en el nivel de agresividad mínima (que, en la presente forma de realización, es canal entrelazado de 15dB como puede observarse claramente en la tabla 1), y de no ser así , se mantiene en el mismo (es decir, en el nivel de agresividad mínima); aunque se añade una marca de fallo para el sistema a fin de atraer la atención del personal técnico. Una vez acabada la etapa S55, el procedimiento continúa por la etapa S60.

En la etapa S60, a la cual se llega tras aplicar una transición de reasignación de perfil menos agresivo de dos pasos en la etapa S35 o tras aplicar una transición de reasignación de perfil de un paso en la etapa S55, el duplicador de retardo se incrementa en una unidad (siempre que no haya alcanzado ya su valor máximo de 5, en cuyo caso simplemente se mantiene en 5) y, por último, se restablece el umbral de bueno de conformidad con la fórmula UMBRAL DE BUENO = UMBRAL DE BUENO PREDEFINIDO * 2 EXP (DUPLICADOR DE RETARDO). Finalmente, en la etapa S60, los contadores de retardo deficiente y retardo bueno se ponen a cero. Una vez acabada la etapa S60, el procedimiento termina (para la respectiva línea que se procesa) y la función DLM pasa a analizar cualquier otra línea que requiera análisis en el proceso por lotes del período de 24 horas actual.

Si en la etapa S25 se determina que la línea se ha clasificado como correcta, entonces el proceso continúa por la etapa S65, en la que los contadores de retardo bueno y retardo malo se decrementan en una unidad (aunque si un contador ya está a cero no se decrementa, sino que permanece a cero). Este decremento de los contadores de retardo para las líneas clasificadas como correctas asegura que las líneas que solo son buenas ocasionalmente o solo malas ocasionalmente pero la mayor parte del tiempo son correctas permanezcan en el valor de perfil actual. Una vez acabada la etapa S65, el proceso (para la respectiva línea) termina.

Si en la etapa S25 se determina que la línea es "buena," el proceso continúa por la etapa S70, en la que se determina si el contador de retardo bueno es inferior al umbral de bueno. De ser así, el proceso continúa por la etapa S75, en la que el contador de retardo bueno para la línea en cuestión (RETARDO BUENO) se incrementa (en una unidad). Una vez acabada la etapa S75, el proceso continúa por la etapa S80, en la que el contador de retardo deficiente (RETARDO DEFICIENTE) se decrementa, lo cual ayuda a evitar que líneas que habitualmente son buenas con la misma frecuencia que son deficientes cambien a un perfil diferente. Una vez acabada la etapa S80, el proceso (para la respectiva línea) termina.

Si en la etapa S70 se determina que el contador de retardo bueno (RETARDO BUENO) no es inferior al umbral de bueno (UMBRAL DE BUENO), es decir, ha alcanzado o sobrepasado el umbral, el proceso continúa por la etapa S85, en la que se formula una petición OSS para que se aplique, al perfil DLM de la línea, una transición de un paso en la dirección de incremento de agresividad (siempre y cuando este no se halle ya en el perfil más agresivo que, en la presente forma de realización, es la modalidad de canal no entrelazado de 3 dB, tal como se observa claramente en la tabla 1, en cuyo caso simplemente permanece en su perfil más agresivo). Una vez acabada la etapa S85, el proceso continúa por la etapa S90, en la cual se restablecen los contadores de retardo RETARDO BUENO y RETARDO DEFICIENTE para la línea y, a continuación, el proceso (para la respectiva línea) termina. Como se ha mencionado anteriormente, una vez acabado el proceso para la línea que se procesa actualmente, la función DLM pasa a analizar cualquier otra línea que requiera análisis en el proceso por lotes del período de 24 horas actual.

Variantes

En una ligera variante del proceso descrito anteriormente, puede utilizarse la marca PERFIL AGRESIVO para averiguar cuando se ha efectuado una reasignación de perfil en la dirección de incremento de agresividad, y el duplicador de retardo puede incrementarse solo si se ha efectuado una reasignación de perfil en la dirección de reducción de agresividad (justo) después de que se haya efectuado una reasignación de perfil en la dirección de incremento de agresividad. Esto ayuda a incrementar el retardo necesario para poder efectuar una transición a mayor agresividad solo si hay constancia de oscilación entre perfiles diferentes. Estas funciones pueden implementarse añadiendo una etapa adicional después de (es decir, cuando termina) la etapa S90 para cambiar la marca PERFIL AGRESIVO a verdadero (desde el valor falso predefinido), enmendando la etapa S60 de tal manera que el duplicador de retardo solo se incremente si la marca PERFIL AGRESIVO está establecida en verdadero y, por último, restableciendo la marca PERFIL AGRESIVO en falso tras incrementar el duplicador de retardo.

En formas de realización alternativas, pueden utilizarse procedimientos diferentes para diferenciar entre reacondicionamientos causados por el usuario y reacondicionamientos forzados. Por ejemplo, puede instalarse algún tipo de software especial en el extremo del módem del usuario (que se ejecutará en el PC del usuario conectado al módem DSL de usuario final, o bien en el propio módem DSL) para detectar las veces en que aparentemente el módem ha sido desconectado por el usuario (por ejemplo, detectando la pérdida de la alimentación del módem, tal como sucede cuando el usuario apaga el módem o desenchufa el cable de alimentación, etc. o detectando la desconexión del cable telefónico, etc.). Por otra parte, las diversas normas de ADSL especifican como requisito opcional que las ATU (es decir, los módems ADSL) deben monitorizar las pérdidas de alimentación e informar si es necesario. Desgraciadamente, los fabricantes de módems ADSL todavía no han implementado de manera generalizada esta característica. Por esta razón, la estrategia descrita en la forma de realización preferida anterior, que consiste en buscar transiciones entre períodos en los cuales no se detecta la presencia de ninguna conexión y períodos en los que se detecta la presencia de una conexión, es la preferida, porque puede llevarse a cabo con los módems comunes actuales sin tener que realizar ninguna modificación en los módems ni en los PC de los usuarios (ni en el software que se ejecuta en estos).

En formas de realización alternativas, la detección de eventos de alcance local puede ser realizada por DSLAM individuales o por colectores de datos (o gestores de datos), en cuyo caso podría simplemente no informarse al dispositivo de gestión (o al colector de datos) acerca de los errores o reacondicionamientos causados por un evento de alcance local o dicha información podría pasarse explícitamente al dispositivo de gestión (o al colector de datos), ya que esta podría resultar útil al tratar de determinar otros reacondicionamientos o errores que podrían haber sido causados por un evento de alcance local.

En la forma de realización anterior, los bins se utilizan como período de prueba para detectar eventos de alcance local, sobre todo para hacer más cómodo y fácil el procesamiento. Como alternativa, podrían utilizarse bins diferentes (tal vez más pequeños) y/o bins superpuestos con el propósito específico de determinar eventos de alcance local (quizás podrían utilizarse bins de 5 minutos superpuestos con el propósito de detectar eventos de alcance local mientras se siguen utilizando bins de 15 minutos para otros menesteres como, por ejemplo, calcular el tiempo medio entre errores e identificar las resincronizaciones causadas por el usuario, etc.) para mejorar todavía más la detección de eventos de alcance local a costa de un incremento en los requisitos de procesamiento y memoria.

En la forma de realización anterior, se efectúa una comparación simple entre la proporción de líneas activas que experimentan una resincronización dentro de cierto período de tiempo predeterminado y cierto umbral por encima del cual se determina que las resincronizaciones son resultado de un evento de alcance local. No obstante, en una forma de realización alternativa, se podrían utilizar una o más redes neuronales artificiales (ANN) para realizar el cálculo. En dicha forma de realización, la red neuronal podría tomar como entradas las tres matrices bidimensionales uptimes[96,n], retrains[96,n] y errors[96,n] cada una de las cuales presenta n por 96 posiciones de [0,0] a [95,n-1] mencionadas en la página 20 anterior. Sin embargo, como sabrán deducir los expertos en la materia, es posible aumentar el número de entradas. Las salidas de este caso sencillo podrían representar los elementos de la matriz areaWideEvents mencionada en la página 21. Como bien saben los expertos en la materia, el número de nodos de la capa o capas ocultas puede variarse hasta que se encuentra una disposición aceptable.

Un ejemplo de entradas adicionales que podrían facilitarse a la ANN sería el de las entradas de datos meteorológicos. Por ejemplo, podría diseñarse un programa para determinar, desde un sitio web de información meteorológica, si se ha producido alguna tormenta eléctrica en los alrededores del grupo de líneas que se monitoriza, y para establecer la correlación con los períodos a los que se refieren cada una de las entradas de valores de la matriz. Como alternativa extrema aunque menos preferida, podría utilizarse dicha información de manera exclusiva en lugar de utilizar las matrices uptimes[96,n], retrains[96,n] y errors[96,n] (o información equivalente).

Para entrenar la ANN, podría utilizarse la primera forma de realización a fin de obtener algunos datos de entrenamiento. Preferentemente, los datos generados de esa forma deberán ser verificados por el personal técnico para tratar de eliminar los falsos ejemplos y tal vez también los casos dudosos en los que el resultado no se vislumbra con claridad, etc. Una vez que los datos se han depurado de esta manera, estos se pueden utilizar para entrenar la ANN, y posteriormente la ANN puede utilizarse para generar la matriz areaWideEvents que entonces podrá emplearse como en la forma de realización principal descrita anteriormente. Un procedimiento de entrenamiento alternativo consistiría simplemente en hacer que las matrices de entrada fueran generadas y estudiadas por el personal técnico con el propósito de determinar cuáles serían los vectores de salida adecuados, y utilizarlos como datos de entrenamiento.

Si cada dispositivo de agregación o central telefónica estuvieran provistos de un calculador, podría crearse y entrenarse una ANN separada para cada una de dichas posiciones y, de forma alternativa, podría crearse y entrenarse solo una o varias ANN y luego duplicarlas en cada punto en el que fuera necesario. En tal caso, deberá construirse y entrenarse la ANN de mayor tamaño que se necesite, con lo cual sería suficiente inhabilitar algunas entradas, etc. de las ANN que monitorizan menos líneas. Como alternativa, las entradas podrían procesarse para hacer que la ANN sea más escalable a diferentes números de líneas monitorizadas, etc., manteniendo fijo el número de entradas para la ANN, independientemente del número de líneas que se monitorizan, etc.

Claims (11)

1. REIVINDICACIONES

   1.

   Procedimiento de operación de una red de acceso que incluye una pluralidad de conexiones de datos entre unos dispositivos de usuario final (10) y un dispositivo de transceptor de agregación (20), siendo agregadas las conexiones para una posterior conexión a través de la red de acceso, comprendiendo el procedimiento las etapas siguientes: almacenar una pluralidad de perfiles diferentes, cada uno de los cuales especifica un conjunto de valores para un conjunto de uno o más parámetros asociados a cada conexión de datos y, para cada conexión de datos, monitorizar el rendimiento de la conexión; seleccionar uno de dichos perfiles almacenados para aplicarlo a la conexión en función de los resultados de la monitorización de la conexión; y aplicar el perfil seleccionado a la conexión de datos, caracterizado porque la monitorización de la conexión incluye determinar el número de eventos de mal rendimiento que se producen, en un período de tiempo determinado, y calcular el número de dichos eventos de mal rendimiento que se producen como resultado de un evento de alcance local que afecta a una pluralidad de líneas y desestimar cualquiera de dichos eventos de mal rendimiento cuando se selecciona un perfil para aplicarlo a la conexión de datos.

2. 2.

   Procedimiento según la reivindicación 1, en el que el cálculo del número de eventos de mal rendimiento que se producen como resultado de un evento de alcance local incluye determinar la proporción de conexiones activas dentro de un grupo predeterminado de conexiones que experimentan una resincronización en un período de prueba de duración predeterminada, y comparar ésta con un umbral e identificar un evento de alcance local como causa de todas dichas resincronizaciones si esta proporción sobrepasa el umbral.

3. 3.

   Procedimiento según la reivindicación 2, que identifica asimismo que cualquier error que se produzca en las conexiones dentro del grupo predeterminado de conexiones producidas en un periodo de prueba asociado con un evento de alcance local es provocado por un evento de alcance local y por lo tanto, también desestima dichos errores cuando se selecciona un perfil que va a ser aplicado.

4. 4.

   Procedimiento según cualquiera de las reivindicaciones anteriores, en el que la selección del perfil se realiza basándose en el cálculo del número de resincronizaciones forzadas que no se producen como resultado de un evento de alcance local, y en el que el mismo se realiza determinando el número total de resincronizaciones por todos los motivos, calculando el número total de aquellas resincronizaciones causadas por un usuario y el número total de aquellas resincronizaciones generadas en ese período como resultado de un evento de alcance local, y restando estos números calculados de resincronizaciones causadas por el usuario y resincronizaciones causadas por eventos de alcance local para obtener un cálculo del número de resincronizaciones forzadas no causadas por un evento de alcance local.

5. 5.

   Detector de eventos de alcance local para su utilización en una red de acceso que incluye una pluralidad de conexiones de protocolo de línea de abonado digital entre dispositivos de usuario final (10) y una pluralidad de dispositivos de transceptor de agregación (20), en los que terminan las conexiones de protocolo de línea de abonado digital, caracterizado porque el detector incluye unos medios (117, 119) para identificar la presencia de resincronizaciones en una pluralidad de las conexiones y para determinar si más de un número predeterminado de éstas se produce en un período de prueba predeterminado y, de ser así, identificar que dichas resincronizaciones han sido provocadas por un evento de alcance local.

6. 6.

   Detector de eventos de alcance local según la reivindicación 5, en el que el número predeterminado comprende una proporción del número total de conexiones activas que experimentan una resincronización en el período de prueba predeterminado.

7. 7.

   Dispositivo de transceptor de agregación (20) que incorpora un detector de eventos de alcance local según la reivindicación 5 o 6.

8. 8.

   Colector de datos (25), que incorpora un detector de eventos de alcance local según las reivindicaciones 5 o 6.

9. 9.

   Dispositivo de gestión (100) que incorpora un detector de eventos de alcance local según la reivindicación 5 o 6.

10. 10.

    Red de acceso, que incluye un dispositivo de transceptor de agregación según la reivindicación 7, un colector de datos (25) según la reivindicación 8 o un dispositivo de gestión según la reivindicación 9.

11. 11.

    Medios de soporte tangibles, que contienen un programa informático o un paquete de programas informáticos para llevar a cabo el procedimiento según cualquiera de las reivindicaciones 1 a 4 durante la ejecución del programa

    o los programas.