ES2636463T3 - Comunicación de datos - Google Patents

Comunicación de datos Download PDF

Info

Publication number
ES2636463T3
ES2636463T3 ES15161548.1T ES15161548T ES2636463T3 ES 2636463 T3 ES2636463 T3 ES 2636463T3 ES 15161548 T ES15161548 T ES 15161548T ES 2636463 T3 ES2636463 T3 ES 2636463T3
Authority
ES
Spain
Prior art keywords
data connection
resynchronizations
connection
data
profile
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES15161548.1T
Other languages
English (en)
Inventor
Philip Everett
Christopher Marcus Croot
Trevor Linney
Ashley Pickering
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Application granted granted Critical
Publication of ES2636463T3 publication Critical patent/ES2636463T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • H04L12/2869Operational details of access network equipments
    • H04L12/287Remote access server, e.g. BRAS
    • H04L12/2876Handling of subscriber policies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M11/00Telephonic communication systems specially adapted for combination with other electrical systems
    • H04M11/06Simultaneous speech and data transmission, e.g. telegraphic transmission over the same conductors
    • H04M11/062Simultaneous speech and data transmission, e.g. telegraphic transmission over the same conductors using different frequency bands for speech and other data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Arrangements for supervision, monitoring or testing
    • H04M3/2227Quality of service monitoring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Arrangements for supervision, monitoring or testing
    • H04M3/26Arrangements for supervision, monitoring or testing with means for applying test signals or for measuring
    • H04M3/28Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor
    • H04M3/30Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor for subscriber's lines, for the local loop
    • H04M3/302Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor for subscriber's lines, for the local loop using modulation techniques for copper pairs
    • H04M3/304Automatic routine testing ; Fault testing; Installation testing; Test methods, test equipment or test arrangements therefor for subscriber's lines, for the local loop using modulation techniques for copper pairs and using xDSL modems

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Método de funcionamiento de una red de acceso (19, 20, 30), que incluye una pluralidad de conexiones de datos (10, 19, 20) entre unos dispositivos de usuario final (10) y un dispositivo transceptor de agregación (20), en el que las conexiones de datos (10, 19, 20) son agregadas para la conexión hacia delante a través de la red de acceso, comprendiendo el método: almacenar una pluralidad de diferentes perfiles, cada uno de los cuales especifica un conjunto de valores para una pluralidad de parámetros asociados con cada conexión de datos (10, 19, 20); y para cada conexión de datos (10, 19, 20), monitorizar el rendimiento de la conexión de datos (10, 19, 20); seleccionar uno de entre dichos perfiles almacenados para ser aplicados a la conexión de datos (10, 19, 20) dependiendo de los resultados de la monitorización de la conexión de datos (10, 19, 20); y aplicar el perfil seleccionado a la conexión de datos (19); en el que la monitorización de la conexión de datos (10, 19, 20) incluye estimar el número de veces que la conexión de datos (10, 19, 20) se resincroniza, dentro un periodo de tiempo dado, como resultado de una resincronización automática o forzada en lugar de como resultado de una acción del usuario, y utilizar el número estimado de resincronizaciones automáticas o forzadas, cuando se selecciona un perfil para ser aplicado a la conexión de datos (10, 19, 20), estando el método caracterizado por que la estimación del número de veces que la conexión de datos (10, 19, 20) se resincroniza de manera automática o forzada comprende determinar el número total de resincronizaciones, dentro del periodo de tiempo dado, por todos los motivos, estimar el número total de estas resincronizaciones causadas por un usuario y restar este número estimado de resincronizaciones causadas por el usuario para obtener una estimación del número de resincronizaciones automáticas o forzadas, comprendiendo la estimación del número total de resincronizaciones causadas por un usuario detectar que ha transcurrido más de un periodo de tiempo mínimo predeterminado antes de una resincronización sin haber establecido conectividad y sin que la conexión (10, 19, 20) haya intentado automáticamente, pero sin éxito, restablecer la conectividad.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Comunicacion de datos.
Campo de la invencion
La presente invencion se refiere a la comunicacion de datos. En particular, se refiere a la gestion de una red de acceso que incluye conexiones de Lfnea de Abonado Digital (DSL).
Antecedentes de la invencion
La Gestion Dinamica de Lfneas (DLM) es una tecnica para mejorar la estabilidad de conexiones de DSL. Resulta particularmente util cuando se trabaja con conexiones de DSL cerca de su velocidad maxima, ya que, en estas condiciones, el ruido externo que afecta a la senal transmitida puede provocar que los transceptores sean incapaces de recuperar satisfactoriamente la senal a transmitir, con la suficiente fiabilidad para permitir el mantenimiento de la conexion. Si se produce esto, es necesario volver a establecer la conexion. A esto se le hace referencia como resincronizacion y el usuario percibe una perdida temporal de servicio mientras la conexion se vuelve a establecer. En general, las resincronizaciones son percibidas como particularmente molestas por los usuarios finales.
La DLM busca minimizar dichas resincronizaciones analizando automaticamente conexiones de DSL (especialmente la tasa de aparicion de resincronizacion) y variando ciertos parametros que pueden afectar a la probabilidad de aparicion de resincronizaciones (por ejemplo, la profundidad de intercalacion, la cantidad de redundancia incorporada en la codificacion usada, etcetera). Tfpicamente, esto se realiza utilizando varios perfiles diferentes que presentan varios conjuntos diferentes de valores para los parametros que es mas probable que tengan un impacto sobre la estabilidad o alternativamente de una conexion de DSL, y cambiando una conexion particular entre perfiles diferentes hasta que se halle un perfil que presente una estabilidad aceptable. Los perfiles se aplican en la central local (a la que se hace referencia en ocasiones - especialmente en Estados Unidos - como central telefonica (central office)) habitualmente en un equipo conocido como Multiplexor de Acceso de Lfnea de Abonado Digital (DSLAM) el cual aloja varias unidades transceptoras de DSL tal como es sabido ampliamente en la tecnica.
Tfpicamente, en terminos conceptuales se puede considerar que los perfiles estan dentro de una gama que los califica de mas agresivos a menos agresivos, donde los perfiles mas agresivos tienden a proporcionar servicios mejores al usuario (en terminos de velocidades de bit especialmente mayores y latencias menores), aunque presentan una mayor probabilidad de dar como resultado inestabilidades en la lfnea, mientras que los perfiles menos agresivos tienden a ofrecer velocidades de bits y/o latencias inferiores aunque estabilidades mayores.
Un Libro Blanco de Tecnologfa de Alcatel titulado “Dynamic Line Management for Digital Subscriber Lines” y disponible en el siguiente URL
http://www1.alcatel-lucent.com/com/en/appcontent/apl/18812 DLM twp tcm172- 228691635.pdf describe la DLM y sugieren en lfneas generales una implementacion en la cual se producen una Fase de Validacion y una Fase de Operaciones. En la fase de validacion, una conexion se monitoriza de forma bastante exhaustiva para identificar un perfil apropiado para la lfnea y, a continuacion, se monitoriza menos exhaustivamente para garantizar que el perfil seleccionado originalmente continua siendo valido.
La solicitud de patente europea en tramite n.° 07250428.5 describe una solucion de DLM previa, ideada por los presentes solicitantes, en la cual se detectan conexiones de datos muy inestables, de una manera eficiente, y se emprende una accion correctora en un periodo de tiempo relativamente breve, mientras que conexiones de datos que no son muy inestables son monitorizadas y realizan transiciones entre perfiles diferentes sobre la base de una monitorizacion mas minuciosa en una escala de tiempo mayor.
El documento US 2002/0136203 A1 describe un metodo y un aparato en el que una funcionalidad de Sistema Mejorado de Terminacion de Cablemodems (Enhanced Cable Modem Termination System, CMTS), que incluye unos moduladores y desmoduladores de dominio digital programables se incorpora a los Nodos de Fibra (FN) o mini Nodos de Fibra (mFN), resultando en Nodos de Fibra mejorados (eFN). Estos eFN distribuyen la funcionalidad CMTS en Redes Hfbridas de Fibra Coaxial (Hybrid-Fiber-Coax Networks, HFCN) en lugar de centralizar las funciones CMTS en un unico punto.
El documento WO 02/35793 describe un metodo de control de encaminamiento de paquetes en una red de comunicaciones que presenta una red central (del ingles, core network) y una red de acceso donde los dispositivos moviles pueden conectarse con la red de acceso en diferentes nodos de acceso. Si el nodo de acceso al cual esta conectado un dispositivo cambia se produce un proceso de redireccionamiento de ruta y un bloqueo temporal es colocado por un nodo aguas arriba en la red de acceso en el reenvfo de los paquetes destinados al dispositivo movil durante el proceso de redireccionamiento de ruta.
5
10
15
20
25
30
35
40
45
50
55
60
65
El documento US 2006/198430 describe un metodo de control de la transicion de comunicaciones de datos entre un perfil actual y unos posibles perfiles objetivo evaluando la viabilidad de los perfiles posibles y actuales objetivo y a continuacion, seleccionando una transicion deseada basada en la viabilidad evaluada de los perfiles y en una prioridad de las posibles transiciones. La evaluacion de la viabilidad de los perfiles puede implicar “monitorizar los contajes de reacondicionamientos causados por el elevado ruido y el gran numero de violaciones de codigos”.
Todas las soluciones de DLM conocidas por el presente solicitante utilizan, como por lo menos una de las metricas usadas en la monitorizacion del rendimiento de una lfnea, el numero de reacondicionamientos o resincronizaciones que se producen sobre una lfnea dentro de un periodo de tiempo predeterminado. Sin embargo, los presentes inventores se han dado cuenta de que esta metrica, en determinadas circunstancias, puede ser enganosa y deberfa ser procesada para proporcionar una metrica mas fiable del rendimiento de la lfnea.
Sumario de la invencion
Segun un primer aspecto de la invencion, se proporciona un metodo de funcionamiento de una red de acceso de acuerdo con lo que se expone en la reivindicacion 1.
De acuerdo con el primer aspecto, una metrica del numero de resincronizaciones por unidad de tiempo se modifica para eliminar las resincronizaciones (en general, por lo menos algunas) causadas por la accion del usuario en lugar de como resultado de la lfnea con problemas tecnicos o inestabilidad, etc., proporcionando, por lo tanto, una metrica mas util para su utilizacion al llevar a cabo la Gestion Dinamica de Lfneas.
Una resincronizacion automatica o forzada es una que se produce debido a que los errores en la conexion causan una perdida completa de conexion. Cuando esto ocurre, los modems finales vuelven a un estado inicial en el que se restablece de cero una conexion, en lugar de intentar rescatar la conexion anterior. Esto se establece en las diversas normas de xDSL incluyendo, en particular, ITU-T G992.1-ADSL1, ITU-T G992.3- ADSL2, ITU-T G992.5-ADSL2+ e ITU-T G994.1 - Procedimientos de Establecimiento de Comunicacion para los transceptores para lfnea de abonado digital (Handshake Procedures for digital subscriber line, DSL).
Preferentemente, la determinacion o estimacion del numero de resincronizaciones forzadas comprende determinar el numero total de resincronizaciones (en el periodo de tiempo dado de interes) por muchos motivos, estimar el numero total de aquellas resincronizaciones causadas por un usuario y restar este numero estimado de resincronizaciones causadas por el usuario para obtener una estimacion del numero de resincronizaciones forzadas.
Preferentemente, la etapa de estimar el numero de resincronizaciones provocadas por el usuario comprende detectar que ha transcurrido mas de un periodo de tiempo mfnimo predeterminado antes o despues de una resincronizacion sin que se haya establecido una conexion y sin que la lfnea intente automaticamente volver a establecer la conexion, aunque no consiguiendolo. Asf, si el usuario simplemente apaga o desenchufa el modem durante un periodo de tiempo mayor que el periodo de tiempo mfnimo, se determina que la resincronizacion resultante es una resincronizacion provocada por un usuario en lugar de una resincronizacion forzada. Preferentemente, esto se logra contando los periodos contiguos de tiempo de indisponibilidad que superan el periodo mfnimo predeterminado dentro del periodo dado (mas largo).
En una forma de realizacion, se mantiene un registro de cada periodo (compartimento) de 15 minutos durante el cual no hay ninguna conexion en marcha, y el numero de conjuntos de periodos contiguos en los cuales no se registra ninguna conexion en marcha dentro de cualquier periodo de 24 horas (lote) se toma como el numero estimado de resincronizaciones provocadas por el usuario en ese periodo de 24 horas; naturalmente, en formas de realizacion alternativas, se pueden usar periodos de tiempo diferentes para los compartimentos o para los lotes (por ejemplo, compartimentos de periodos de 5 minutos y lotes de 48 horas, etcetera). El numero de periodos contiguos (compartimentos) se puede determinar convenientemente contando el numero de transiciones entre periodos (compartimentos) en los cuales no se registran conexiones como presentes, y periodos (compartimentos) en los cuales se registra una conexion como presente.
En una forma de realizacion de la invencion, el procedimiento tambien comprende almacenar, con respecto a cada una de las conexiones, un nivel de estabilidad y, para cada conexion de datos, seleccionar de entre uno de dichos perfiles almacenados que deben ser aplicados a la conexion se lleva a cabo en funcion de los resultados de monitorizacion de la conexion y el nivel de estabilidad asociado con la conexion de datos.
Asf, el metodo de esta forma de realizacion permite la aplicacion de polfticas de estabilidad diferentes (cada una de las cuales se corresponde con o especifica un nivel de estabilidad) a conexiones de datos diferentes para reflejar los posibles usos diferentes de la conexion que pueden imponer valores diferentes sobre los meritos relativos de estabilidad de la lfnea, ancho de banda y latencia. Preferentemente, las diferentes polfticas de estabilidad controlan las circunstancias bajo las cuales una conexion realizara una transicion entre perfiles
5
10
15
20
25
30
35
40
45
50
55
60
65
diferentes (por ejemplo, tolerando un numero mayor de errores o resincronizaciones por unidad de tiempo antes de efectuar una transicion a un perfil menos agresivo y viceversa).
Preferentemente, dos parametros principales que controlan el funcionamiento de las conexiones xDSL son modificados para generar diferentes perfiles, el margen de la Relacion Senal/Audio (SNR) y el modo rapido/intercalado.
El margen de SNR representa la cantidad de redundancia incorporada a la velocidad de bits seleccionada (y otras opciones de la conexion) para la conexion, dado el valor medido de la SNR concreta que experimenta el modem. Asf, cada conjunto posible de valores significativos para los parametros de la conexion (es decir, la velocidad de bits, el nivel de la codificacion reticulada, el nivel de intercalacion, etcetera) tiene una SNR de lfnea basal correspondiente que representa el valor mfnimo de la SNR en el cual se esperarfa que funcionase la conexion con una Tasa de Errores de Bit (BER) de 10-7 (es decir, se espera 1 bit erroneo por cada 107); a esta BER de 10-7 se le denomina tasa objetivo en la medida en la que se espera que la conexion funcione muy bien con este nivel de BER. El margen de SNR representa la cantidad (en decibelios) por la cual la SNR medida real supera esta cantidad de lfnea basal en el momento de establecer la conexion. Asf, la SNR recibida real puede variar con el tiempo, despues de establecer la conexion, por debajo de la cantidad medida en el establecimiento de la conexion hasta en una cantidad correspondiente al margen y se seguirfa esperando todavfa que la conexion funcionase con una BER inferior o igual a la cantidad objetivo (es decir, por lo menos tan buena como la cantidad objetivo).
La definicion de margen de SNR que se proporciona en la norma de xDSL ITU G992.1 Seccion 9.5.1 es: “Margen de la Relacion Senal/Ruido (SNR): el margen de la relacion de senal/ruido representa la cantidad de aumento de ruido recibido (en dB) con respecto a la potencia de ruido que esta disenado para tolerar el sistema y cumplir todavfa con la BER objetivo de 10-7, teniendo en cuenta todas las ganancias de codificacion (por ejemplo, codificacion reticulada, Rs FEC) incluidas en el diseno. El margen de la SNR varfa de -64,0 dB a +63,5 dB con pasos de 0,5 dB”.
De este modo, se apreciara que cuanto menor sea el Margen de SNR, mayor sera la velocidad de bits significativa que se podra alcanzar (es decir, suponiendo que no se produzcan errores). En cambio, cuanto mayor sea el Margen de la SNR, mas probable sera que la conexion funcione de una manera estable, incluso en un entorno de ruido fluctuante.
El modo rapido/de intercalacion conmuta la profundidad de intercalacion entre intercalacion no existente (modo RAPIDO) y cualquiera de las profundidades de intercalacion definidas en las normas de ADSL aplicables actualmente (por ejemplo, las normas ITU G.992.x). En muchas implementaciones, por el momento se usa unicamente el nivel de intercalacion mas bajo (una profundidad de 2, en donde unidades de una unica palabra de codigo que son adyacentes antes de la intercalacion se separan por una unidad intercalada, con respecto a otra palabra, despues de la intercalacion); no obstante, esto puede cambiar en el futuro. Tal como es bien sabido en la tecnica, el uso de la intercalacion ofrece proteccion contra picos de ruido de corta duracion intercalando unidades (por ejemplo, bytes) de un cierto numero (en funcion de la profundidad de intercalacion) de palabras de codigo (que comprenden, cada una de ellas, varias unidades), donde cada palabra de codigo tiene una cierta cantidad de proteccion contra errores, de tal manera que un numero relativamente pequeno de unidades con error por cada palabra de codigo puede ser recuperado por el mecanismo de proteccion contra errores para recuperar completamente la palabra de codigo original (por ejemplo, si hay 5 unidades (por ejemplo, bytes) por cada palabra de codigo y el mecanismo de correccion de errores puede recuperar palabras de codigo en donde una unidad es erronea, una profundidad de intercalacion de 2 permitirfa recuperar las dos palabras intercaladas si un ruido provocase la alteracion de dos unidades adyacentes dentro de un periodo de transmision de dos palabras). La intercalacion proporciona proteccion contra ruidos impulsivos a costa del aumento de la latencia (y requisitos mas elevados de almacenamiento temporal de los equipos de red).
La funcionalidad (o subcomponentes de esta funcionalidad) de la presente invencion puede ser realizada por varios dispositivos diferentes. En particular, el nivel de estabilidad se puede almacenar dentro del dispositivo transceptor de agregacion (por ejemplo, el DSLAM) o un dispositivo asociado al mismo. Esto se corresponded con una forma de realizacion en la cual el controlador/operador de la red de acceso asume la responsabilidad de implementar polfticas de estabilidad diferentes para conexiones de datos diferentes. Esto resulta particularmente ventajoso cuando esta es la parte que tiene el control de conmutar entre perfiles de conexion diferentes (tal como se produce generalmente) y para casos en los que la conexion no desea realizar una transicion entre polfticas de estabilidad diferentes de una manera muy frecuente (por ejemplo, en funcion de la aplicacion particular que es usada por el dispositivo de usuario en cualquier momento particular), puesto que provocarfa dificultades para un sistema centralizado que debe de hacer frente de una manera muy rapida a lo que potencialmente podrfa ser muchos clientes.
No obstante, en una forma de realizacion alternativa, las polfticas de estabilidad se pueden almacenar en el dispositivo de usuario final respectivo. Basandose en la polftica de estabilidad seleccionada (y con un conocimiento adecuado del nivel de estabilidad que esta intentando proporcionar el DSLAM para esa conexion
5
10
15
20
25
30
35
40
45
50
55
60
de datos), el dispositivo de usuario puede incluir cierta funcionalidad (por ejemplo, proporcionada por un programa de ordenador adecuado) que intercepte mensajes del modem de DSL del dispositivo de usuario final destinados al modem de DSL del lado de la red (por ejemplo, ubicado en el dispositivo transceptor de agregacion) y modifique estos mensajes para conseguir que el modem de DSL del lado de la red establezca una conexion de DSL que sea mas o menos agresiva (en terminos de ancho de banda o de latencia o de ambos aspectos). De manera equivalente, el funcionamiento normal del modem de DSL simplemente se podrfa modificar de tal modo que para polfticas o niveles de estabilidad diferentes el modem genere mensajes diferentes que seran devueltos al modem de DSL del lado de la red.
Un ejemplo de un programa de ordenador que funciona de esta manera general y el cual se podrfa usar (preferentemente con algunas modificaciones adecuadas que se describen posteriormente) para esta finalidad es la “herramienta de DMT” la cual esta disponible para su descarga en
http://dmt.mhilfe.de/. Este programa funciona enviando informacion sobre caracterfsticas de la conexion (especialmente la SNR) que no se basa puramente en lo que ha sido detectado por el modem de acuerdo con el funcionamiento normal de este ultimo. En su lugar, con la herramienta de DMT, esta informacion puede ser introducida directamente por un usuario de la herramienta, sobrescribiendo asf la informacion que serfa enviada normalmente por el modem. No obstante, en una forma de realizacion preferida de la presente invencion, este programa no se usarfa para modificar los valores de SNR (o no se usarfa solamente para modificar los valores de SNR) comunicados por el modem de usuario final al modem del lado de la red, sino mas bien (o adicionalmente) el numero de errores (especialmente el numero de segundos con errores) que se producen en la direccion del sentido descendente y los cuales dependen de las caracterfsticas medidas reales asf como el nivel de estabilidad asociado a la polftica de estabilidad actualmente en vigor para la conexion.
Preferentemente, en todos los casos, los diferentes perfiles se almacenan todos ellos en el lado de la red (por ejemplo, en el DSLAM) y el operador de la red tiene la responsabilidad de seleccionar el perfil concreto aplicado a una conexion, aunque esto se realiza habitualmente al menos de forma parcial como respuesta a mensajes provenientes del modem de DSL del usuario final. Preferentemente, los parametros usados para determinar si se deberfa realizar o no un cambio de perfil incluyen el numero de veces que se ha producido una resincronizacion sobre una conexion DSL dentro de un cierto periodo de tiempo y el numero de segundos con errores que se han producido dentro de un cierto periodo de tiempo (por ejemplo, dentro de las ultimas 24 horas).
Preferentemente, el sistema incluye de manera adicional un selector de polfticas de estabilidad que selecciona una polftica de estabilidad apropiada basandose en el uso (o uso deseado o solicitado) de la conexion. Preferentemente el selector es configurable por el usuario u operador, y preferentemente actua como una maquina de estados, con lo cual algunas circunstancias pueden dar como resultado la adopcion de una polftica nueva para algunos estados del selector aunque no para otros. Por ejemplo, el selector puede tener tres estados de agresivo, normal y estable, y se puede configurar de tal manera que si el selector esta en el estado estable y el usuario conmuta de una aplicacion de flujo continuo de video a navegacion web, el selector puede cambiar el estado de estable a normal, mientras que si el selector esta en el estado agresivo y el usuario conmuta de una aplicacion de juego a navegacion web, el selector puede que no cambie de estado, etcetera. Igual que con el almacenamiento del nivel de estabilidad polftica, este selector tambien se podrfa implementar o bien en el lado de la conexion de DSL correspondiente al usuario final (que se corresponde con la forma de realizacion en la que el control de la polftica de estabilidad reside en el dispositivo de usuario final) o bien en el lado de la conexion de DSL correspondiente a la red/DSLAM (que se corresponde con la forma de realizacion en la que el operador de la red tiene la responsabilidad de la polftica o nivel de estabilidad aplicados actualmente para la conexion).
Preferentemente, el selector incluye unos medios para provocar una resincronizacion de la conexion de DSL en la que realiza una transicion de un estado a otro.
Preferentemente, las conexiones de datos son lfneas de abonado digitales que incluyen unidades transceptoras remotas y centrales conectada a traves de un par de cobre y que funcionan de acuerdo con una o mas de las diversas normas de xDSL acordadas por la Union Internacional de Telecomunicaciones (ITU) (por ejemplo, G.992.x y sus anexos). Preferentemente, el dispositivo transceptor de agregacion es un Multiplexor de Acceso de Abonado Digital (DSLAM).
Preferentemente, los perfiles se clasifican de acuerdo con un nivel de agresividad, en donde, en general, perfiles mas agresivos es mas probable que den como resultado una conexion que se convierta en inestable.
Otros aspectos de la presente invencion se refieren a sistemas, dispositivos, programas de ordenador y medios portadores o soportes segun se expone en las reivindicaciones adjuntas, especialmente medios portadores tangibles, tales como dispositivos de almacenamiento optico (por ejemplo, discos compactos (CD) o DVD), o dispositivos de almacenamiento magnetico, tales como discos magneticos, o dispositivos de memoria no volatil de estado solido.
5
10
15
20
25
30
35
40
45
50
55
60
65
Breve descripcion de las figuras
Para que la presente invencion se pueda entender mejor, a continuacion se describiran formas de realizacion de la misma, unicamente a tftulo de ejemplo, y en referencia a los dibujos adjuntos en los cuales:
la Figura 1 es un diagrama de bloques esquematico que ilustra una red de telecomunicaciones que incorpora un dispositivo de gestion que funciona de acuerdo con un metodo segun la presente invencion;
la Figura 2 es un diagrama de bloques esquematico que ilustra el dispositivo de gestion de la Figura 1 de forma mas detallada; y
la Figura 3 es un diagrama de flujo que ilustra las etapas llevadas a cabo por el dispositivo de gestion de la Figura 1 con el fin de controlar el perfil de DLM aplicado a las conexiones de DSL en la red de la Figura 1.
Descripcion detallada de formas de realizacion
La forma de realizacion principal descrita a continuacion utiliza un dispositivo de gestion 100 para llevar a cabo dos funciones principales - aprovisionamiento del Servidor de Acceso Remoto de Banda Ancha (Broadband Remote Acess Server, BRAS) y Gestion Dinamica de Lfneas (DLM). El aprovisionamiento del BRAS se describe brevemente en esta solicitud, para completar la descripcion, aunque se describe de forma mas detallada en las solicitudes de patente internacional en tramite GB2006/002826 y GB2006/002818 presentadas ambas el 28 de julio de 2006, a las que se ha hecho referencia anteriormente, para lectores interesados en los detalles de los metodos preferidos de aprovisionamiento de BRAS aplicables en la forma de realizacion principal.
En cuanto a la funcion de DLM, esta es deseable en la forma de realizacion principal ya que la velocidad de sentido descendente de las conexiones de ADSL controladas por el dispositivo de gestion de la velocidad de la forma de realizacion principal se adapta a la velocidad mas alta que puede soportar la lfnea desde 2 Mb a 8 Mb. En la medida en la que las conexiones de ADSL estan trabajando en sus lfmites superiores, las mismas son mas susceptibles al ruido lo cual puede provocar errores y resincronizaciones (resyncs) espontaneas.
En lfneas generales, el papel de la funcion de DLM del dispositivo de gestion es garantizar que las conexiones de ADSL proporcionan un buen compromiso entre la estabilidad de la lfnea y el rendimiento de esta en terminos de velocidad de bits (o quizas, lo que es mas importante, la velocidad a la cual un usuario puede recibir datos deseados - despues de que, por ejemplo, se hayan vuelto a enviar todos los paquetes perdidos por causa de errores) y la latencia. La funcion de DLM lleva a cabo esto recibiendo datos de Recopiladores de Datos de DSLAM cada dfa y procesando estos datos recibidos. A continuacion, la funcion de DLM puede aumentar o reducir los margenes de ruido (es decir, los margenes de SNR) y/o intercalar niveles, segun se requiera, fijando un perfil nuevo para cada conexion de ADSL (utilizando los sistemas de aprovisionamiento existentes para fijar perfiles en los DSLAM's). Esta funcionalidad basica se potencia con modulos logicos para minimizar el embarullamiento u oscilacion de perfiles (intentando estabilizar el perfil de DSLAM para cada conexion, en lugar de reaccionar a cada cambio pertinente en el entorno de la conexion lo cual podrfa provocar el cambio del maximo perfil estable aplicable).
Forma de realizacion principal
En referencia a la Figura 1, se ilustra en lfneas generales una primera forma de realizacion de la presente invencion. Un bucle 19 de par de cobre (que forma parte de la red de acceso que se extiende entre el equipo 10 de las instalaciones del cliente y el BRAS 40) conecta el equipo 10 de las instalaciones del cliente a un DSLAM 20 situado dentro de una central local (conocida tambien como central telefonica. El DSLAM separa trafico de voz normal y trafico de datos y envfa el trafico de voz a la Red Telefonica Publica Conmutada (PSTN) 70. El trafico de datos se hace pasar a traves de una red 30 de Modo de Transferencia Asfncrono (ATM) que constituye el resto de la red de acceso 19, 20, 30 (en la presente forma de realizacion, la red de ATM 30 es la red de ATM de la Plataforma de Intranet Multi-servicio (MSiP) de British Telecom (BT)). Conectado a la red de ATM 30 se encuentra un Servidor de Acceso Remoto de Banda Ancha (BRAS) 40 en el cual por medio de una red de IP 50 (que, en este caso, es la red IP Colossus de BT) - la cual puede hacerse funcionar ella misma sobre una red o redes de ATM - se agregan (y desagregan) varios flujos de trafico IP o circuitos de ATM de (y en) multiples Proveedores de Servicio (SP's) 62, 64, 66. Dentro del equipo 10 de las instalaciones del cliente, se encuentra un filtro divisor de ADSL 18, un telefono 12, un modem de AdSl 16 y un ordenador 14.
En algunos casos, el primer salto de un paquete IP que viaja desde el ordenador 14 hacia un ISP 62, 64, 66 podrfa ser el BRAS 40; mientras que, en otros casos, el primer salto desde la perspectiva de un IP podrfa situarse mas alla del BRAS 40.
En todos los casos, el modem 16 del usuario final crea una sesion de Protocolo de Punto-a-Punto (PPP) desde el modem a otro dispositivo en la red. Esta es una conexion logica de extremo a extremo que lleva el trafico de los usuarios finales desde el modem a la red IP de destino.
5
10
15
20
25
30
35
40
45
50
55
60
65
En algunos casos (por ejemplo, en el producto Central+ de BT), la sesion de PPP se hace terminar en el BRAS, y a continuacion se encamina hacia delante directamente a Internet (por ejemplo, por medio de una red IP central, tal como la red Colossus de BT).
En una configuracion de ejemplo en la que la sesion de PPP no se hace terminar en el BRAS 40, la sesion de PPP termina en una “pasarela domestica” en el borde de la red central, conectada al Proveedor de Servicios (SP). En otra configuracion de ejemplo (por ejemplo, tal como en el producto central de BT) se usa un tunel del Protocolo de Tunelizacion de la Capa 2 (L2TP) para pasar a traves del BRAS 40 hasta un BRAS de terminacion que pertenece al SP; el tunel de L2TP tuneliza todas las sesiones de PPP hacia la red del SP para que las mismas realicen la gestion que deseen.
En todos los casos, el primer salto de IP se produce desde el usuario final al BRAS de terminacion (es decir, a traves de la conexion de PPP). Ademas, en todos los casos, el BRAS 40 es responsable de imponer polfticas sobre la cantidad de trafico que fluye en sentido descendente (es decir, desde la red hacia el equipo en las instalaciones del cliente) en direccion a cada lfnea conectada al BRAS 40, para garantizar que la misma no supere una cantidad maxima prevista para esa lfnea. Esta aplicacion de polfticas se realiza o bien en la capa de IP (donde el BRAS 40 termina una conexion de PPP proveniente del equipo 10 de instalaciones del cliente) o bien en un nivel inferior (por ejemplo, en la capa de ATM) cuando se produce cierto tipo de tunelizacion por debajo de la capa IP a traves del BRAS 40.
La disposicion mencionada anteriormente de los elementos 10, 19, 20, 30, 40, 50, 62, 64, 66 y 70 es convencional. No obstante, ademas de esta disposicion convencional, en la presente forma de realizacion existe un dispositivo de gestion 100 que se comunica tanto con el DSLAM 20 como con el BRAS 40. El funcionamiento detallado de este dispositivo (especialmente por lo que respecta a su funcion de DLM) se explica mas detalladamente a continuacion en referencia a las Figuras 2 y 3. No obstante, en lfneas generales, obtiene informacion del DSLAM 20, sobre la velocidad a la que se conecta cada Lfnea de Abonado Digital (DSL) al DSLAM, e informacion sobre eventos, tales como errores detectados y/o resincronizaciones que se producen en la lfnea/conexion, y modifica el funcionamiento de los DSLAM's en relacion con la agresividad del perfil usado por un DSLAM respectivo para una respectiva conexion de DSL.
Tal como se muestra en la Figura 2, el dispositivo de gestion 100 comprende dos partes funcionales principales, una funcion de aprovisionamiento de BRAS o control de BRAS 120 y una funcion de Gestion Dinamica de Lfneas (DLM) 110.
La funcion de aprovisionamiento de BRAS 120 procesa parte de la informacion recibida desde los DSLAM's para evaluar una velocidad de conexion congruente lograda por cada DSL. Si determina que esta velocidad congruente se ha incrementado como resultado de conexiones recientes de mayor velocidad, da ordenes al BRAS para permitir flujos de trafico pasantes mayores para ese DSL. Por otro lado, si detecta que una velocidad de conexion particular esta por debajo del valor congruente almacenado, reduce el valor congruente hasta el valor de conexion actual, e informa inmediatamente al BRAS de la nueva velocidad de valor congruente de manera que el BRAS no permite que fluya mas trafico hacia el DSL del que sea capaz de soportar el DSL en ese momento.
En las solicitudes internacionales en tramite GB2006/002826 y GB2006/002818 se describen detalles precisos de algunos de los algoritmos que pueden ser usados por la funcion de Control de BRAS 120 del dispositivo de gestion 100 para calcular una velocidad congruente en la presente forma de realizacion. No obstante, debe indicarse que la intencion de estos algoritmos es disponer que el usuario reciba datos con la velocidad mas alta que pueda obtener congruentemente su DSL, sin ser necesario que el BRAS se reconfigure cada vez que la DSL se conecte a una nueva velocidad maxima. Al mismo tiempo, los algoritmos buscan garantizar que si una DSL se conecta a una velocidad que esta por debajo de aquella a la que esta configurado en ese momento el BRAS para permitir datos a traves de el para esa DSL, entonces el BRAS se reconfigura rapidamente para evitar la sobrecarga del DSLAM.
Posteriormente se exponen detalles del algoritmo particular utilizado en la presente forma de realizacion por la funcion de DLM. No obstante, en lfneas generales, una subfuncion de recepcion de datos de DLM recibe un nuevo archivo diariamente desde cada gestor de elementos, que contiene hasta 96 intervalos de tiempo (periodo de 15 minutos) por cada conexion de DSL y por dfa, junto con informacion sobre una polftica o nivel de estabilidad asociados a cada conexion. Estos datos se usan en una subfuncion de analisis de DLM para determinar si se requieren cambios en el perfil de DSLAM con el fin de estabilizar el servicio de los usuarios finales de manera que se cumpla con la polftica o nivel de estabilidad asociado respectivo de la conexion. Si se requieren cambios, una subfuncion de salida de DLM envfa una solicitud al Sistema de Soporte de Operaciones (OSS) de la red de acceso para el perfil aplicado a la lfnea que se va a cambiar. La forma precisa en la que se realiza esto dependera de los detalles de OSS de la red de acceso en particular y no es relevante para la presente invencion por lo que no se describira de forma adicional en este documento.
5
10
15
20
25
30
35
40
45
50
55
60
65
Cada una de las subfunciones de DLM mencionadas anteriormente se implementa mediante componentes de un procesador de ordenador convencional que funcionan de acuerdo con modulos de codigo de software almacenados en una memoria 112 que forma parte de la funcion de DLM 110; en particular, un modulo de codigo de recepcion de datos de DLM 114 (ENTRADA DE DATOS) provoca la implementacion de la subfuncion de recepcion de datos de DLM, un modulo de codigo de analisis de DLM 116 (ANALISIS DE DATOS) provoca la implementacion de la subfuncion de analisis de DLM y un modulo de codigo de salida de DLM 118 (SALIDA DE DATOS) provoca la implementacion de la subfuncion de salida de DLM. Adicionalmente, la memoria 112 almacena tambien el conjunto de datos de polftica de estabilidad 115 (POLITICAS DE ESTABILIDAD) en el cual se mantiene el nivel o polftica de estabilidad asociados a cada conexion de DSL gestionada por el dispositivo de gestion. Ademas, en la presente forma de realizacion, la memoria 112 almacena tambien un modulo de estimacion de resincronizaciones forzadas 117 (EST. RESINCRONIZACIONES FORZADAS) para implementar una subfuncion con el fin de estimar el numero de resincronizaciones para cada lfnea en cada lote de datos generadas como consecuencia de algun tipo de error, por ejemplo, que se producen en la conexion en lugar de como consecuencia de acciones del usuario (por ejemplo, apagar o desconectar su modem de DSL). Esta subfuncion de estimacion de resincronizaciones forzadas se describe de forma mas detallada posteriormente.
La fuente principal de datos de entrada para la funcion de DLM es un archivo diario de cada gestor de elementos, que proporciona un informe agregado de la actividad de cada lfnea durante las 24 horas anteriores. Esto da como resultado un cambio del perfil de DSLAM que se aplica con una frecuencia no mayor que una vez cada 24 horas, lo cual resulta ventajoso puesto que evita la posibilidad de la reconfiguracion del DSLAM cada vez que una lfnea se resincroniza. No obstante, de forma adicional, la funcion de DLM recibe ademas datos de entrada que especifican un nivel de estabilidad para cada lfnea. En la presente forma de realizacion, estos se introducen desde una base de datos en la cual un operador introduce manualmente los datos como parte del proceso de aprovisionamiento de una conexion de DSL nueva y se almacenan dentro del conjunto de datos de polfticas de estabilidad 115 en la memoria de DLM 112. Asf, en la presente forma de realizacion, la intencion es que, cuando un cliente solicite una conexion de DSL, se le ofrezcan niveles diferentes de estabilidad (los cuales seran los mas adecuados para ciertos tipos diferentes de actividad); asf, los clientes que pretendan principalmente usar la conexion para flujo continuo de video se beneficiaran de una conexion estable, mientras que los clientes que usen mayormente su conexion para descargar archivos grandes, etcetera, se beneficiarfan de una velocidad de bits mas alta en lugar que de niveles de estabilidad muy elevados. Alternativamente, en lugar de proporcionar este servicio basandose en cada usuario final individual, a los clientes minoristas (es decir, Proveedores de Servicios) del operador de servicio de red (es decir, un operador de red mayorista), se les podrfa proporcionar la opcion de seleccionar un nivel de estabilidad en nombre de sus clientes y podrfan vender esto a sus clientes (usuarios finales) como una oferta de productos “especializados”.
No obstante, en formas de realizacion alternativas, el nivel de estabilidad se podrfa actualizar mas dinamicamente, como consecuencia de una solicitud por parte del usuario. En una forma de realizacion de ejemplo, se podrfa proporcionar un servidor web para recibir solicitudes de usuario para un cambio de nivel de estabilidad (quizas con una frecuencia permitida maxima de solicitudes permitidas por usuario, por ejemplo, no mas de una por hora o una por dfa, etcetera) y esto a continuacion podrfa provocar, tan pronto como fuera posible, que la funcion de DLM volviese a ejecutar su proceso de comparacion correspondiente a esa lfnea con el nivel de estabilidad recien solicitado y, si, como consecuencia de la comparacion, se determina que resulta apropiado efectuar una transicion a un perfil nuevo, entonces se realiza la transicion al perfil nuevo, otra vez lo antes posible de manera que el usuario experimente una respuesta bastante dinamica a una solicitud de cambiar el nivel de estabilidad.
Cada vez que se comprueba una lfnea para ver si se deberfa cambiar su perfil (lo cual, en la presente forma de realizacion, se produce una vez cada 24 horas como parte de una funcion de procesado por lotes), se lee el nivel de estabilidad correspondiente asociado a esa lfnea y a continuacion se fijan valores de umbral para esa lfnea en funcion del nivel de estabilidad asociado a la lfnea respectiva. A continuacion, los datos del archivo diario son procesados y los datos correspondientes a la lfnea respectiva que se esta analizando se comparan con los valores de umbral fijados para esa lfnea en funcion del nivel de estabilidad asociado a la lfnea. Si la comparacion indica que deberfa realizarse una transicion, entonces se emite una instruccion correspondiente al sistema de OSS para que se efectue una transicion correspondiente.
El perfil de DSLAM tiene los parametros que se ajustan en los diversos perfiles diferentes disponibles para que la funcion de DLM escoja entre ellos, con el fin de mejorar la estabilidad de la lfnea o a la inversa mejorar la velocidad de bits o baja latencia de la conexion; el margen objetivo y el modo de ejecucion (permitiendo este ultimo el uso de intercalacion). El perfil de lfnea por defecto que se aplica inicialmente a todas las lfneas tiene un margen objetivo de 6db y la intercalacion deshabilitada (a lo que se hace referencia normalmente como estar en el modo rapido). El cambio de estos parametros se basa en dos factores de medicion del rendimiento en la presente forma de realizacion, errores (en particular, en esta forma de realizacion, errores provocados por violaciones de codigo) y reacondicionamientos (es decir, resincronizaciones).
El numero de errores y reacondicionamientos se normaliza al tiempo de actividad (tiempo sincronizado total durante el periodo) para formar los factores de medicion reales del rendimiento utilizados para determinar la
5
10
15
20
25
30
35
40
45
50
55
60
65
estabilidad de la linea. Por ejemplo, 100 errores en 10 horas de tiempo de actividad despues de la normalizacion es muy diferente (de manera bastante notable) a 100 errores en 1 minuto de tiempo de actividad. La normalizacion se lleva a cabo calculando un tiempo-medio-entre o bien errores o bien resincronizaciones. Ademas, en la presente forma de realizacion, el parametro de reacondicionamientos tambien se procesa, antes de su uso como factor de medicion del rendimiento de la estabilidad, descontando el numero de resincronizaciones que se consideran como resincronizaciones provocadas por el usuario, antes de calcular el tiempo-medio-entre resincronizaciones. En la presente forma de realizacion, esto se logra usando el siguiente metodo, tal como se especifica a continuacion de acuerdo con el siguiente pseudocodigo:
[Observese que lo siguiente supone que se ha formado y completado una matriz tiemposdeactividad[], de tal manera que cada elemento de la matriz se corresponde con uno de los 96 compartimentos de 15 minutos por cada periodo de 24 horas (en la presente forma de realizacion) para una conexion de DSL particular - el tipo de la matriz (es decir, numeros de 1 bit, enteros de 1 byte, enteros cortos, numeros de coma flotante, etcetera) no es importante siempre que, cuando un elemento de la matriz sea cero, indique tiempo de actividad cero en el compartimento correspondiente y un valor diferente de cero indique que se produjo por lo menos cierto tiempo de actividad en ese compartimento - si se usan valores de 1 bit, los mismos se pueden considerar de manera que adoptan un valor o bien Verdadero o bien Falso, en cuyo caso uno de ellos se deberfa usar para indicar tiempo de actividad cero en lugar del cero - no obstante, en la presente forma de realizacion, cada elemento comprende un entero corto entre 0 y 900 que especifica el numero de segundos de tiempo de actividad en el compartimento respectivo de 15 minutos (es decir, 900 segundos)].
*** Comentario - metodo para contar el numero de reacondicionamientos no forzados en un periodo de 24 horas para una conexion dada
FIJAR reacondicionamientosnoforzados = 0 PARA (i = 0 a 95) (
SI (tiemposdeactividad[i] = 0 Y tiemposdeactividad[i+1] !=0) ENTONCES
reacondicionamientosnoforzados++
)
DEVOLVER reacondicionamientosnoforzados.
El pseudocodigo anterior dice basicamente que se comprueba cada compartimento y se determina si el mismo tiene un tiempo de actividad cero mientras el compartimento sucesivo tiene un tiempo de actividad diferente de cero (es decir, detectar una transicion de un compartimento sin tiempo de actividad a un compartimento con algo de tiempo de actividad), y, para cada una de estas transiciones, incrementar la variable reacondicionamientosnoforzados que, de este modo, mantiene una cuenta total del numero de (supuestas) resincronizaciones provocadas por el usuario. A continuacion, este valor se resta del numero total de reacondicionamientos detectados para la conexion respectiva en el periodo de 24 horas con el fin de obtener un numero estimado de reacondicionamientos forzados para el periodo de 24 horas, y a continuacion el tiempo de actividad total en segundos se divide por el numero estimado de reacondicionamientos forzados para obtener un tiempo medio estimado entre reacondicionamientos en segundos. En la presente forma de realizacion, la matriz tiemposdeactividad[] almacena el numero de segundos de tiempo de actividad de cada compartimento, de manera que resulta sencillo obtener el tiempo de actividad total para la conexion simplemente sumando los valores de todos los elementos de la matriz.
Tras haberse calculado los factores de medicion a usar en la evaluacion de la estabilidad de la linea, se realiza una comprobacion con respecto a los umbrales, etcetera, tal como se describe de forma mas detallada posteriormente, y se realizara un cambio en el perfil si ello se considera necesario o deseable.
En general, si se considera necesario un cambio a un perfil menos agresivo, se realiza un traslado a un perfil intercalado con preferencia a un aumento del margen objetivo. Inicialmente, un perfil intercalado se fija con el mismo margen objetivo correspondiente que el perfil previo de modo rapido (es decir, uno rapido de 6dB realizaria una transicion a uno intercalado de 6dB).
Si un cliente ha renunciado a la opcion de aplicar intercalacion (por ejemplo, debido a que una latencia baja es mas importante para el que la velocidad de bits maxima - tal como suele ser el caso de clientes que son jugadores en linea o usuarios de VOIP o de videoconferencia), entonces las transiciones se realizan solamente entre perfiles de modo rapido (unicamente se varfa el margen objetivo). Esto limita claramente la capacidad del proceso de DLM.
Antes de que se realice una transicion, se efectua una comprobacion con respecto a la velocidad de la linea para garantizar que una linea tiene la capacidad de llevar a cabo la transicion a un perfil nuevo sin padecer una cafda de la velocidad de bits tan drastica que se situase por debajo de una velocidad de bits aceptable minima predeterminada. Una transicion se efectua solamente si existe cierta confianza en que la linea tendra la capacidad de soportar el servicio por encima de esta velocidad aceptable minima una vez que se aplique el perfil nuevo. Por ejemplo, en la presente forma de realizacion una transicion a un perfil de margen de ruido superior se
5
10
15
20
25
30
35
40
45
50
55
efectua solamente si la velocidad de bits actual es aproximadamente 800 kbps mayor que una Velocidad de Umbral para Fallo (FTR) (FTR representa la velocidad de bits aceptable minima segun es determinada por el operador de la red - en la presente forma de realizacion, el operador de la red es un mayorista de servicios de red y suministra estos servicios a minoristas, o Proveedores de Servicios, de la red los cuales a su vez suministran a los consumidores; la Velocidad Estable Minima es un parametro que es determinado por el operador de la red mayorista y que se proporciona al proveedor de servicios como una indicacion de la capacidad estimada de la lfnea, la FTR esta relacionada con la MSR aunque se fija por debajo de esta y se usa para activar un informe de fallo si la velocidad de la conexion cae alguna vez por debajo de la FTR puesto que esto es una indicacion de que la lfnea esta funcionando notablemente por debajo de la velocidad a la que se cree que tiene capacidad para funcionar). Si la lfnea es inestable y sin embargo no puede realizar la transicion debido a que caerfa por debajo de su velocidad de bits aceptable minima (es decir, la FTR), entonces esto se marca con una bandera para realizar una investigacion posterior. En la presente forma de realizacion, la FTR se fija inicialmente a 2 Mbs y a continuacion se vuelve a fijar al 80% de la Velocidad Estable Maxima detectada por la red durante los primeros 10 dfas de funcionamiento de la DSL en su modo adaptativo a la velocidad.
Si una lfnea no consigue sincronizarse entonces se efectuara una transicion a un margen objetivo inferior. Si esto significa volver a un estado previamente inestable, entonces esto se marca con una bandera para realizar una investigacion posterior, ya que la lfnea no esta estabilizada de forma eficaz (aun cuando no se encuentra en el margen objetivo maximo). La lfnea se devuelve al estado inestable previo de manera que se puede proporcionar cierto nivel de servicio al cliente mientras tiene lugar una investigacion.
Si una lfnea no consigue sincronizarse ni siquiera con el margen objetivo mas bajo, entonces esto se marca con una flecha para realizar una investigacion. Por ejemplo, puede que no sea capaz de soportar el servicio requerido o la lfnea puede estar defectuosa.
De manera similar, si una lfnea sigue siendo inestable con el margen objetivo posible maximo, entonces esto se marca con una bandera para realizar una investigacion posterior. La lfnea por ejemplo puede estar defectuosa.
Si una lfnea es completamente estable, entonces en general la funcion de DLM cambia la lfnea a un margen objetivo (o profundidad de intercalacion) menor para aumentar la capacidad disponible (o reducir la latencia) en la lfnea (recuerdese, 3 dB “ 800 kbps). No obstante, estas transiciones se gestionan de manera cuidadosa para evitar cambios frecuentes en el margen objetivo (o la profundidad de intercalacion) en sentido ascendente y descendente. Asf, si una lfnea se ha cambiado previamente desde un perfil con un margen objetivo inferior mas agresivo (o menos intercalado) al margen objetivo actual (y la profundidad de intercalacion), la misma, antes de que se vuelva a realizar una transicion de ella de vuelta al perfil del margen objetivo (o profundidad de intercalacion) inferior, debe esperar un tiempo considerablemente mayor (por ejemplo, una semana, o un mes) que si no se hubiera cambiado previamente de vuelta desde el perfil del margen objetivo (o profundidad de intercalacion) menor.
En la presente forma de realizacion, hay un proceso manual para permitir la transicion entre cualquier perfil de lfnea (por ejemplo, un cambio de rapido de 3dB directo a intercalado de 15 dB es posible con intervencion manual).
En la presente forma de realizacion, aquellas lfneas que se han marcado con banderas para una investigacion posterior se reparan pro-activamente con la esperanza de que se puedan reparar antes de que se genere cualquier informe de fallo.
Las solicitudes de perfiles nuevos para cambiar a un perfil menos agresivo se pueden producir a diario. Las decisiones sobre perfiles nuevos en lfneas estables para cambiar a un perfil mas agresivo con el fin de aumentar la capacidad total se realizan durante un periodo de tiempo mas prolongado (el cual en general aumenta con el numero de veces que la lfnea ha salido previamente del perfil objetivo debido a problemas de falta de estabilidad) segun se ha descrito en el parrafo anterior.
En la presente forma de realizacion, la primera subfuncion de la funcion de DLM categoriza cada lfnea en una de cuatro categorfas diferentes en funcion del numero normalizado de errores y/o resincronizaciones segun se comunique a la funcion de DLM en el archivo en bloque. Las categorfas se corresponden con muy deficiente, deficiente, aceptable y muy estable.
El flujo basico del proceso de DLM se muestra en la siguiente Tabla 1.
5
10
15
20
25
30
35
40
imagen1
imagen2
imagen3
Tabla 1
En la presente forma de realizacion, el avance general a traves de los perfiles que se muestran en la Tabla 1 es el siguiente: si una lmea se va a cambiar a un perfil mas estable, el primer cambio es mudarse al perfil con el mismo margen objetivo aunque en modo intercalado en lugar de modo rapido, si la lmea ya esta en un modo intercalado, entonces la lmea se muda al siguiente perfil de margen objetivo mas alto tambien en el modo intercalado. Si la lmea se va a mudar en la direccion de aumentar la capacidad, la misma se mantiene en el mismo modo (es decir, rapido o intercalado) pero se muda al siguiente perfil objetivo mas bajo, a no ser que se encuentre en el margen objetivo mmimo en modo intercalado, en cuyo caso se muda al perfil de margen objetivo mmimo en modo rapido.
En la segunda subfuncion de la funcion de DLM, una lmea categorizada como muy deficiente se traslada inmediatamente dos pasos en la direccion de una mejor estabilidad (por ejemplo, desde el perfil Rapido de 6dB se trasladana al Intercalado de 9dB, desde el Intercalado de 6dB se trasladana al Intercalado de 12dB, etcetera). Una lmea categorizada como deficiente se traslada inmediatamente (aunque con una prioridad menor que el perfilado nuevo de toda lmea categorizada como muy deficiente) un paso en la direccion de una mejor estabilidad (por ejemplo, desde el Rapido de 6dB a Intercalado de 6 dB o desde intercalado de 9dB a Intercalado de 12dB). Una lmea categorizada como aceptable se mantiene en su perfil actual (es decir, no se realiza ninguna accion). Una lmea categorizada como muy estable se traslada (si se cumplen tambien los requisitos adicionales de evitar oscilaciones, etcetera) un paso en la direccion de una capacidad mayor (por ejemplo, desde el Rapido de 6dB a Rapido de 3dB, desde Intercalado de 9dB a Intercalado de 6 dB o desde Intercalado de 3dB a Rapido de 3dB).
En la presente forma de realizacion, cada lmea se procesa una vez cada 24 horas con el fin de determinar como debena categorizarse la lmea, y por lo tanto si debena seleccionarse un perfil nuevo para esa lmea. Con el fin de evitar oscilaciones frecuentes entre perfiles adyacentes, se usan un contador de retardos buenos y otro de retardos malos para imponer un retardo sobre la rapidez con la que se da un perfil nuevo a una lmea. Asf, cada vez que una lmea se categoriza como buena se incrementa un contador de retardos buenos (y se decrementa un contador de retardos deficientes), y solamente una vez que el contador de retardos buenos ha llegado a un umbral bueno (que, en la presente forma de realizacion, se fija a 13) se efectua una solicitud al OSS para que el perfil de incremente en un paso a un nivel mas agresivo, y a continuacion los contadores de retardos se reinicializan. Ademas, cada vez que una lmea se categoriza como deficiente, se incrementa un contador de retardos deficientes (y se decrementa el contador de retardos buenos) y solamente una vez que el contador de retardos deficientes llega a un umbral deficiente (el cual, en la presente forma de realizacion, se fija a 3) su perfil se deja caer en un paso a un nivel menos agresivo. Los contadores de retardos no se decrementan nunca por debajo de 0, de tal manera, que incluso si una lmea ha experimentado varios dfas buenos (de tal modo que el contador de retardos deficientes se ha decrementado hasta cero, por ejemplo, cinco dfas buenos sucesivos) solamente son necesarios 3 dfas sucesivos de la lmea que tiene un funcionamiento deficiente para alcanzar el umbral deficiente provocando un nuevo perfil. Ademas, se usa un duplicador de retardos para incrementar el retardo (es decir, incrementando el umbral bueno) requerido antes de que a una lmea que ha descendido desde un perfil mas agresivo a un nivel de perfil menos agresivo se le permita volver a realizar una transicion de vuelta al nivel mas agresivo. Por lo tanto, el duplicador de retardos se incrementa (en la presente forma de realizacion hasta un maximo de 5) cada vez que se da un perfil nuevo a la lmea en direccion a un nivel menos agresivo y a
5
10
15
20
25
30
35
40
45
50
55
continuacion los retardos se reinicializan (como en el caso en el que se da un perfil nuevo a la linea a un nivel mas agresivo). La reinicializacion de los retardos se efectua de acuerdo con las siguientes formulas:
UMBRAL BUENO = UMBRAL BUENO POR DEFECTO + 2EXP(DUPLICADOR DE RETARDOS)
CONTADOR DE RETARDOS DEFICIENTES = CONTADOR DE RETARDOS BUENOS = 0
En la presente forma de realizacion, el UMBRAL BUENO POR DEFECTO se fija a 13 (es decir, equivalente a 14 dfas), el RETARDO DEFICIENTE POR DEFECTO se fija en la presente forma de realizacion a 3 (es decir, equivalente a 3 dfas) y el DUPLICADOR DE RETARDOS se fija a 0, con lo cual el retardo bueno inicial es 13 pero cada vez que el perfil de la linea efectua una transicion a un perfil menos agresivo el DUPLICADOR DE RETARDOS se incrementa hasta que despues de 5 de estas transiciones, cada vez que se reinicializa el RETARDO se reinicializa a un valor de 448 (es decir, equivalente a aproximadamente 14 meses). En la presente forma de realizacion, si se cambia la polftica a nivel de estabilidad de un usuario el duplicador de retardos se reinicia de vuelta a cero; ademas, el duplicador de retardos e incluso el contador de retardos pueden ser reinicializados manualmente por un operador para responder a circunstancias excepcionales.
En la presente forma de realizacion, se describe a continuacion en referencia a la Figura 3 la funcionalidad especifica de la funcion de DLM para permitir que lfneas diferentes funcionen en niveles diferentes de estabilidad de acuerdo con polfticas de estabilidad fijadas para cada linea. Resumiendo, en la presente forma de realizacion, antes de que el DLM lleve a cabo su funcion de categorizacion de lfneas para una linea en particular, se determina su nivel de estabilidad asociado y a continuacion la categorizacion se basa en los valores de umbral asociados al nivel de estabilidad respectivo, presentando cada nivel de estabilidad un conjunto diferente de valores de umbral asociados para su utilizacion en la funcion de categorizacion. De este modo, en la etapa S5 se obtiene el nivel de estabilidad para la linea particular que se va a categorizar, junto con los datos de retardo almacenados para esa linea (es decir, el valor actual del contador de retardos, RETARDO, el cual, tal como se ha mencionado anteriormente, se fija inicialmente a un valor 3, y el valor actual del duplicador de retardos, DUPLICADOR DE RETARDOS, el cual se fija inicialmente a un valor de 0).
A continuacion, el proceso se desplaza a la etapa S10 en la cual se obtienen los valores de umbral asociados al nivel de estabilidad que se ha buscado en la etapa S5, para su utilizacion en el resto del proceso, y a continuacion el proceso avanza a la etapa S15.
En la etapa S15, la funcion de DLM obtiene los datos actuales de error y resincronizacion que ha recibido con respecto a la presente linea que se esta analizando. Estos se leen del archivo de datos diarios el cual se envfa a la funcion de DLM diariamente tal como se ha descrito anteriormente. A continuacion, el proceso avanza a la etapa S20.
La etapa S20 es la etapa responsable de categorizar concretamente lfneas en una de cuatro categorfas diferentes posibles: muy deficiente, deficiente, OK y buena. Para realizar esto, los dos factores de medicion utilizados en la presente forma de realizacion, a saber el numero de errores detectado (tanto en el modem de usuario como en el modem de red en el DSLAM) y el numero de resincronizaciones (segun registra el DSLAM) se comparan (despues de la normalizacion tal como se ha mencionado anteriormente) con varios umbrales correspondientes cuyos valores se fijan de acuerdo con el nivel de estabilidad tal cual se asigna la linea. La siguiente tabla 2 expone los diversos umbrales utilizados en la presente forma de realizacion.
Estabilidad
Factor de medicion Muy deficiente Deficiente OK Bueno
Agresivo
Reacondicionamientos > 10 por hora Mtb<3.600 mtb<8.640 mtb>8.640
Agresivo
Errores - Mtb<10 mtb<8.640 mtb>8.640
Normal
Recondicionamientos > 10 por hora Mtb<7.200 mtb<8.640 mtb>8.640
Normal
Errores - Mtb<300 mtb<8.640 mtb>8.640
Estable
Reacondicionamientos > 10 por hora Mtb<28.800 mtb<86.400 mtb>86.400
Estable
Errores - Mtb<1.000 mtb<28.800 mtb>28.800
Tabla 2
En la tabla 2, “mtb” significa “tiempo medio entre” y se corresponde por lo tanto con los factores de medicion normalizados que se han calculado midiendo el tiempo total en segundos durante el cual la linea respectiva ha estado sincronizada durante el ultimo periodo de 24 horas de la monitorizacion, por el numero de reacondicionamientos o errores registrados en ese periodo. Para todos los casos, en la presente forma de realizacion, si se producen mas de 10 reacondicionamientos en cualquier periodo de una hora, se supone que la linea es muy deficiente, con independencia del numero de errores registrados. Para lfneas que funcionan en un nivel de estabilidad agresivo, si el tiempo medio entre reacondicionamientos es menos que una vez por hora (3.600 segundos) (por ejemplo, 6 reacondicionamientos en menos de 5 horas de “tiempo de actividad”) o si el
5
10
15
20
25
30
35
40
45
50
55
60
65
tiempo promedio entre errores es menor de una vez cada 10 segundos de tiempo de actividad, entonces se considera que la lfnea es deficiente; si el tiempo promedio entre reacondicionamientos es menor que una vez cada 2,4 horas (pero mayor que uno cada hora) o el tiempo promedio entre errores es menor que una vez cada 2,4 horas (aunque mayor que una vez cada 10 segundos), entonces se considera que la lfnea esta ok, mientras que si el tiempo promedio entre reacondicionamientos es superior o igual a una vez cada 2,4 horas y el tiempo promedio entre errores es superior o igual a una vez cada 2,4 horas, entonces se considera que la lfnea es buena. A partir de la Tabla 2 anterior, resulta evidente de la misma manera cuales son los umbrales para los otros niveles de estabilidad.
En una forma de realizacion alternativa, los niveles de estabilidad podrfan funcionar de tal manera que, para el nivel de estabilidad mas agresivo, la funcion de DLM intenta mantener las perdidas de sincronizacion por debajo de 12 por cada periodo de 24 horas (incluyendo el apagado de modems/encaminadores lo cual cuenta como una perdida de sincronizacion) e intenta mantener la lfnea libre de errores durante el 98,3% (59/60 segundos) del tiempo de actividad, medido durante un periodo de 24 horas; para el nivel de estabilidad normal, la funcion de DLM intenta mantener las perdidas de sincronizacion por debajo de 6 por cada periodo de 24 horas e intenta mantener la lfnea libre de errores durante el 99,8% (599/600 segundos) del tiempo de actividad, medido durante un periodo de 24 horas; y para el nivel de estabilidad estable, la funcion de DLM intenta mantener las perdidas de sincronizacion por debajo de 3 por cada periodo de 24 horas e intenta mantener la lfnea libre de errores mas del 99,98% (5.999/6.000 segundos) del tiempo de actividad, medido durante un periodo de 24 horas.
Tras haber categorizado la lfnea de acuerdo con la Tabla 2 en la etapa S20, el proceso prosigue hacia la etapa S25 donde se determina si la lfnea se ha categorizado como “deficiente/muy deficiente, OK, o buena”. Si la lfnea se ha categorizado como deficiente/muy deficiente, el proceso prosigue hacia la etapa S30 en la cual se determina si la lfnea se ha categorizado como muy deficiente o deficiente. Si en la etapa S30 se determina que la lfnea se ha categorizado como muy deficiente, entonces el proceso prosigue hacia la etapa S35 en la cual se emite una solicitud de OSS para que el perfil de DLM de la lfnea efectue una transicion de 2 pasos en la direccion menos agresiva, siempre que se encuentre por lo menos dos pasos por encima del nivel mfnimamente agresivo (el cual, en la presente forma de realizacion, es Intercalado, 15 dB, tal como resulte evidente a partir de la Tabla 1), en caso contrario simplemente realiza una transicion directa a este nivel mfnimamente agresivo; si la lfnea ya se encuentra en este nivel mfnimamente agresivo, permanece en el aunque se marca como una bandera un fallo en el sistema para que sea atendido por un ingeniero. Al completarse la etapa S35, el metodo prosigue hacia la etapa S60.
Si en la etapa S30 se determina que la lfnea se ha categorizado como deficiente, el proceso prosigue hacia la etapa S40 en la cual se determina si el contador de retardos deficientes es menor que el umbral deficiente. En caso afirmativo, el metodo prosigue hacia la etapa S45 en la cual el contador de retardos deficientes se incrementa (en uno), y a continuacion el metodo prosigue hacia la etapa S50 en la cual el contador de retardos buenos se decrementa (en uno). Al completarse la etapa S50, el proceso finaliza (para la lfnea respectiva). Si en la etapa S40 se determina, por otro lado, que el contador de retardos es igual (o supera) al umbral deficiente, entonces el metodo prosigue hacia la etapa S55 en la cual se emite una solicitud de OSS para que el perfil de DLM de la lfnea efectue una transicion de 1 paso en la direccion menos agresiva, siempre que no se encuentre ya en el nivel mfnimamente agresivo (el cual, en la presente forma de realizacion es Intercalado, 15 dB, tal como se pone de manifiesto a partir de la Tabla 1), en caso contrario permanece en el (es decir, en el nivel mfnimamente agresivo) aunque se marca un fallo con una bandera en el sistema para que sea atendido por un ingeniero. Al completarse la etapa S55, el metodo prosigue hacia la etapa S60.
En la etapa S60, a la que se llega o bien despues de dar un perfil nuevo menos agresivo, de dos pasos, en la etapa S35, o bien despues de dar un perfil nuevo de un paso en la etapa S55, el duplicador de retardos se incrementa en uno (con la condicion de que no haya alcanzado ya su valor maximo de 5, en cuyo caso simplemente permanece en 5), y a continuacion el umbral nuevo se reinicializa de acuerdo con la formula UMBRAL BUENO = UMBRAL BUENO POR DEFECTO + 2EXP(DUPLICADOR DE RETARDOS). Finalmente, en la etapa S60, los contadores de retardos deficientes y buenos se reinicializan a cero. Al completarse la etapa S60, el metodo finaliza (para la lfnea respectiva que se esta procesando) y la funcion de DLM continua para analizar cualquier otra lfnea que requiera analisis en el proceso actual por lotes de periodos de 24 horas.
Si, en la etapa S25, se determina que la lfnea se ha categorizado como OK, entonces el proceso prosigue hacia la etapa S65 en la cual los contadores de retardos tanto buenos como malos se decrementan en uno (aunque si un contador ya se encuentra en cero, el mismo no se decrementan mas sino que por el contrario permanece en cero). Este decremento de los contadores de retardos para lfneas que se han categorizado como OK garantiza que lfneas que son solo ocasionalmente buenas o solo ocasionalmente malas pero que mayormente estan OK, permaneceran en su configuracion de perfil actual. Al completarse la etapa S65, el proceso (para la lfnea respectiva que se esta procesando) finaliza.
Si en la etapa S25 se determina que la lfnea es “buena”, el metodo prosigue hacia la etapa S70 en la cual se determina si el contador de retardos buenos es menor que el umbral bueno. En caso afirmativo, el proceso prosigue hacia la etapa S75 en la cual el contador de retardos buenos para la lfnea en cuestion, (RETARDO
5
10
15
20
25
30
35
40
45
BUENO) se incrementa (en uno). Al completarse la etapa S75, el proceso prosigue hacia la etapa S80 en la cual el contador de retardos deficientes (RETARDO DEFICIENTE) se decrementa; esto ayuda a evitar que lmeas que tfpicamente son buenas con la misma frecuencia que son deficientes, sean cambiadas a un perfil diferente. Al completarse la etapa S80, el proceso (para la lmea respectiva que se este procesando) finaliza.
Si en la etapa S70 se determina que el contador de retardos buenos (RETARDO BUENO) no es menor que el umbral bueno (UMBRAL BUENO) - es decir, ha alcanzado o superado el umbral - entonces, el proceso prosigue hacia la etapa S85 en la cual se realiza una solicitud de OSS para efectuar una transicion al perfil de dLm de la lmea en un paso en la direccion mas agresiva (siempre que no se encuentre ya en el perfil mas agresivo, el cual, en la presente forma de realizacion, es el modo no intercalado, de 3 dB, tal como se pone de manifiesto a partir de la Tabla 1, en cuyo caso simplemente permanece en este perfil mas agresivo). Al completarse la etapa S85, el metodo prosigue hacia la etapa S90 en la cual los contadores de retardos, RETARDO BUENO y RETARDO DEFICIENTE, correspondientes a la lmea se reinicializan, y a continuacion el proceso (para la lmea respectiva) finaliza. Tal como se ha mencionado anteriormente, una vez que el proceso finaliza para la lmea actual que esta siendo procesada, la funcion de DLM continua con el analisis de cualquier otra lmea que requiera analisis en el proceso actual por lotes de periodos de 24 horas.
Variantes
Como variante menor sobre el proceso antes descrito, se puede usar una bandera de PERFIL AGRESIVO para realizar un seguimiento de cuando se ha concedido un perfil nuevo en la direccion mas agresiva, y el duplicador de retardos se puede incrementar unicamente si se ha dado un perfil nuevo en la direccion menos agresiva (inmediatamente) despues de que se haya dado un perfil nuevo en la direccion mas agresiva. Esto ayuda a incrementar el retardo antes del cual se puede efectuar una transicion mas agresiva unicamente si hay muestras de oscilacion entre perfiles diferentes. Esta funcionalidad se puede implementar incluyendo una etapa adicional despues de la etapa S90 (es decir, tras completarse esta ultima) para fijar la bandera de PERFIL AGRESIVO a verdadera (desde una fijacion de falsa por defecto); y corrigiendo la etapa S60 de tal manera que el duplicador de retardos se incremente solamente si la bandera de PERFIL AGRESIVO se ha fijado a verdadera, y a continuacion reinicializando la bandera de PERFIL AGRESIVO de vuelta a falsa despues de incrementar el duplicador de retardos.
En formas de realizacion alternativas, se podnan usar metodos diferentes para diferenciar reacondicionamientos provocados por el usuario y reacondicionamientos forzados. Por ejemplo, se podna instalar algun software especial en el extremo del modem de usuario (es decir, ya sea para ejecutarse en el PC del usuario conectado al modem de DSL del usuario final, o para ejecutarse en el propio modem del DSL) con el fin de detectar cada vez que el modem es desconectado aparentemente por el usuario (por ejemplo, detectando que la alimentacion para el modem se ha perdido - por ejemplo, debido a que el usuario ha apagado el modem o ha desconectado el cable de alimentacion, etcetera; o detectando que un cable telefonico se ha desenchufado, etcetera). Por otra parte, las diversas normas de ADSL incluso especifican, como requisito opcional, que las ATU (es decir, los modems de ADSL) debenan monitorizar las perdidas de alimentacion y comunicarse si asf se solicitase. Desafortunadamente, esta caractenstica no ha sido implementada todavfa de manera amplia por los fabricantes de modems de ADSL. Por este motivo, se prefiere el planteamiento descrito en la anterior forma de realizacion preferida para buscar transiciones entre periodos en los cuales no se detecta la presencia de ninguna conexion y periodos en los cuales se detecta la presencia de una conexion, ya que esto se puede llevar a cabo con modems existentes comunes sin ninguna modificacion sobre ellos o sobre los PC's de los usuarios (o sobre el software que se ejecuta en los mismos).

Claims (10)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Metodo de funcionamiento de una red de acceso (19, 20, 30), que incluye una pluralidad de conexiones de datos (10, 19, 20) entre unos dispositivos de usuario final (10) y un dispositivo transceptor de agregacion (20), en el que las conexiones de datos (10, 19, 20) son agregadas para la conexion hacia delante a traves de la red de acceso, comprendiendo el metodo:
    almacenar una pluralidad de diferentes perfiles, cada uno de los cuales especifica un conjunto de valores para una pluralidad de parametros asociados con cada conexion de datos (10, 19, 20); y para cada conexion de datos (10, 19, 20),
    monitorizar el rendimiento de la conexion de datos (10, 19, 20);
    seleccionar uno de entre dichos perfiles almacenados para ser aplicados a la conexion de datos (10, 19, 20) dependiendo de los resultados de la monitorizacion de la conexion de datos (10, 19, 20); y
    aplicar el perfil seleccionado a la conexion de datos (19);
    en el que la monitorizacion de la conexion de datos (10, 19, 20) incluye estimar el numero de veces que la conexion de datos (10, 19, 20) se resincroniza, dentro un periodo de tiempo dado, como resultado de una resincronizacion automatica o forzada en lugar de como resultado de una accion del usuario, y utilizar el numero estimado de resincronizaciones automaticas o forzadas, cuando se selecciona un perfil para ser aplicado a la conexion de datos (10, 19, 20), estando el metodo caracterizado por que la estimacion del numero de veces que la conexion de datos (10, 19, 20) se resincroniza de manera automatica o forzada comprende determinar el numero total de resincronizaciones, dentro del periodo de tiempo dado, por todos los motivos, estimar el numero total de estas resincronizaciones causadas por un usuario y restar este numero estimado de resincronizaciones causadas por el usuario para obtener una estimacion del numero de resincronizaciones automaticas o forzadas, comprendiendo la estimacion del numero total de resincronizaciones causadas por un usuario detectar que ha transcurrido mas de un periodo de tiempo mfnimo predeterminado antes de una resincronizacion sin haber establecido conectividad y sin que la conexion (10, 19, 20) haya intentado automaticamente, pero sin exito, restablecer la conectividad.
  2. 2. Metodo segun la reivindicacion 1, en el que la estimacion del numero total de resincronizaciones causadas por un usuario al detectar que ha transcurrido mas de un periodo de tiempo mfnimo predeterminado antes de una resincronizacion sin haber establecido conectividad y sin que la conexion haya intentado automaticamente, pero sin exito, restablecer la conectividad comprende contar los periodos de indisponibilidad contiguos, excediendo cada uno de ellos el periodo mfnimo predeterminado, dentro del periodo de tiempo dado.
  3. 3. Metodo segun cualquiera de las reivindicaciones anteriores, en el que las conexiones de datos (10, 19, 20) son unas lfneas de abonado digitales (16, 19, 20) que incluyen unas unidades transceptoras remota (16) y central (20) conectadas a traves de un par de cobre (19) y que funcionan de acuerdo con una o mas de las diversas normas de xDSL acordadas por la Union Internacional de Telecomunicaciones.
  4. 4. Metodo segun cualquiera de las reivindicaciones anteriores, en el que el dispositivo transceptor de agregacion (20) es un Multiplexor de Acceso de Lfnea Digital de Abonado (20) que comprende una pluralidad de unidades transceptoras centrales que funcionan de acuerdo con una norma xDSL.
  5. 5. Metodo segun cualquiera de las reivindicaciones, que ademas comprende:
    almacenar, con respecto a cada conexion de datos (10, 19, 20), un nivel de estabilidad, que especifica un nivel deseado de estabilidad para la conexion de datos (10, 19, 20); y, para cada conexion de datos (10, 19, 20),
    seleccionar uno de los perfiles almacenados que deben ser aplicados a la conexion de datos (10, 19, 20) dependiendo tanto de los resultados de monitorizacion de los datos de conexion como del nivel de estabilidad asociado con la conexion de datos.
  6. 6. Metodo segun la reivindicacion 5, en el que el perfil almacenado y el nivel de estabilidad estan ambos almacenados dentro de un dispositivo controlado por el operador de la red de acceso.
  7. 7. Metodo segun la reivindicacion 5, en el que el nivel de estabilidad se almacena dentro de un dispositivo de usuario final y los mensajes enviados al dispositivo transceptor de agregacion son generados dependiendo del nivel de estabilidad almacenado.
    5
    10
    15
    20
    25
    30
    35
  8. 8. Dispositivo de gestion (100) para su utilizacion en una red de acceso (19, 20, 30) que incluye una pluralidad de conexiones de datos (10, 19, 20) entre unos dispositivos de usuario final (10) y un dispositivo transceptor de agregacion (20), en el que las conexiones de datos son agregadas para su conexion hacia delante a traves de la red de acceso (19, 20, 30), almacenando la red de acceso (19, 20, 30), en asociacion con cada conexion de datos (10, 19, 20) un perfil de Gestion Dinamica de Lfneas, DLM, que especifica un conjunto de valores para una pluralidad de parametros asociados con la respectiva conexion de datos (10, 19, 20), comprendiendo el dispositivo de gestion (100):
    un receptor para recibir unos datos de monitorizacion que especifican la estabilidad de cada respectiva conexion de datos en un periodo de tiempo dado;
    una unidad de procesador para seleccionar un perfil DLM para ser aplicado a la conexion de datos dependiendo de los datos de monitorizacion; y
    un solicitante para solicitar que un Sistema de Soporte de Operaciones, OSS, de la red de acceso aplique el perfil seleccionado a la conexion de datos; pudiendo la unidad de procesador funcionar asimismo para estimar el numero de veces que la conexion de datos se resincroniza,
    dentro de un periodo de tiempo, como resultado de una resincronizacion automatica o forzada en lugar de como resultado de una accion del usuario, y para utilizar el numero estimado de resincronizaciones automaticas o forzadas, al seleccionar un perfil para ser aplicado a la conexion de datos (10, 19, 20), estando el dispositivo caracterizado por que la unidad de procesador puede funcionar para estimar el numero de veces que la conexion de datos (10, 19, 20) se resincroniza automatica o forzadamente al determinar el numero total de resincronizaciones, dentro de un periodo de tiempo dado, por todos los motivos, estimar el numero total de estas resincronizaciones causadas por un usuario y restar este numero estimado de resincronizaciones causadas por el usuario para obtener una estimacion del numero de resincronizaciones automaticas o forzadas, en el que la estimacion del numero total de resincronizaciones causadas por un usuario comprende detectar que ha transcurrido mas de un periodo de tiempo mfnimo predeterminado antes de una resincronizacion sin que se haya establecido una conectividad y sin que la conexion de datos (10, 19, 20) intente automaticamente, pero sin exito, restablecer la conectividad.
  9. 9. Red de acceso (19, 20, 30, 100) que incluye un dispositivo de gestion (100) segun la reivindicacion 8.
  10. 10. Medios portadores que portan instrucciones implementables por ordenador para hacer que una red de acceso (19, 20, 30, 100) lleve a cabo todas las etapas del metodo segun cualquiera de las reivindicaciones 1 a 7 durante la ejecucion de las instrucciones.
ES15161548.1T 2007-12-21 2008-12-19 Comunicación de datos Active ES2636463T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP07255002A EP2073439A1 (en) 2007-12-21 2007-12-21 Data communication
EP07255002 2007-12-21

Publications (1)

Publication Number Publication Date
ES2636463T3 true ES2636463T3 (es) 2017-10-05

Family

ID=39272854

Family Applications (2)

Application Number Title Priority Date Filing Date
ES08864638.5T Active ES2549125T3 (es) 2007-12-21 2008-12-19 Comunicación de datos
ES15161548.1T Active ES2636463T3 (es) 2007-12-21 2008-12-19 Comunicación de datos

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES08864638.5T Active ES2549125T3 (es) 2007-12-21 2008-12-19 Comunicación de datos

Country Status (5)

Country Link
US (1) US8918498B2 (es)
EP (4) EP2073439A1 (es)
CN (1) CN101919206B (es)
ES (2) ES2549125T3 (es)
WO (1) WO2009081129A1 (es)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2169980A1 (en) * 2008-09-30 2010-03-31 BRITISH TELECOMMUNICATIONS public limited company Dynamic line management
EP2209324A1 (en) * 2009-01-15 2010-07-21 BRITISH TELECOMMUNICATIONS public limited company Management of telecommunications connections
EP2237478A1 (en) 2009-03-31 2010-10-06 BRITISH TELECOMMUNICATIONS public limited company Dynamic line management
EP2437434A1 (en) * 2010-09-30 2012-04-04 British Telecommunications Public Limited Company Monitoring of data traffic based on user profiles
EP2509245B1 (en) * 2011-04-08 2014-10-29 Alcatel Lucent A method and tool for automatically generating a limited set of spectrum and service profiles
EP2634964A1 (en) 2012-02-29 2013-09-04 British Telecommunications public limited company Dynamic Line Management (DLM) of digital subscriber line (DSL) connections
EP2768180A1 (en) * 2013-02-14 2014-08-20 Telefonica S.A. Method and system for fixed broadband access zero touch, self-provisioning, auto-configuration and auto-activation
US9762463B2 (en) * 2014-01-23 2017-09-12 British Telecommunications Public Limited Company Methods and apparatus for operating an access network
RU2598337C2 (ru) * 2014-12-19 2016-09-20 Закрытое акционерное общество "Лаборатория Касперского" Система и способ выбора средств перехвата данных, передаваемых по сети

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6345071B1 (en) * 1998-07-24 2002-02-05 Compaq Computer Corporation Fast retrain based on communication profiles for a digital modem
US7149223B2 (en) 2000-03-06 2006-12-12 Juniper Networks, Inc. Enhanced fiber nodes with CMTS capability
WO2002035793A1 (en) 2000-10-26 2002-05-02 British Telecommunications Public Limited Company Telecommunications routing
US7272209B2 (en) * 2004-01-20 2007-09-18 Sbc Knowledge Ventures, L.P. Automated DSL performance adjustment
US7570599B2 (en) * 2004-04-21 2009-08-04 At&T Intellectual Property I, Llp. Adaptively applying a target noise margin to a digital subscriber line (DSL) loop for DSL data rate establishment
US7460588B2 (en) * 2005-03-03 2008-12-02 Adaptive Spectrum And Signal Alignment, Inc. Digital subscriber line (DSL) state and line profile control
US8144580B2 (en) 2005-07-29 2012-03-27 British Telecommunications Public Limited Company Method and apparatus for communicating data over a data network and controlling an amount of bandwidth a user can transmit or receive over a DSL connection
DE602005000993T2 (de) * 2005-09-16 2007-09-06 Alcatel Lucent Verfahren und Modul zur Netzwerkanalyse
EP1953959A1 (en) * 2007-02-01 2008-08-06 British Telecommunications Public Limited Company Data communication
CN101072048B (zh) * 2007-06-13 2013-12-04 华为技术有限公司 信息参数的调整方法及装置
EP2169980A1 (en) * 2008-09-30 2010-03-31 BRITISH TELECOMMUNICATIONS public limited company Dynamic line management

Also Published As

Publication number Publication date
EP2922239B1 (en) 2017-05-31
WO2009081129A1 (en) 2009-07-02
EP2073439A1 (en) 2009-06-24
CN101919206B (zh) 2014-08-13
US20100293274A1 (en) 2010-11-18
EP2922239A1 (en) 2015-09-23
EP2238713B1 (en) 2015-07-29
EP2238713A1 (en) 2010-10-13
ES2549125T3 (es) 2015-10-23
EP2940932A1 (en) 2015-11-04
US8918498B2 (en) 2014-12-23
CN101919206A (zh) 2010-12-15

Similar Documents

Publication Publication Date Title
ES2636463T3 (es) Comunicación de datos
EP2232776B1 (en) Monitoring of network connections
ES2698439T3 (es) Comunicación de datos
ES2391536T3 (es) Gestión dinámica de la línea
US8792361B2 (en) Dynamic line management of digital subscriber line connections
EP2622797B1 (en) Method for operating an access network
US9154638B2 (en) Data communication