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.

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... [Seguir leyendo]

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. 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. 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. 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. 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. 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. 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. Colector de datos (25) , que incorpora un detector de eventos de alcance local según las reivindicaciones 5 o 6.

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

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. 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.