ES2549125T3 - Comunicación de datos - Google Patents

Comunicación de datos Download PDF

Info

Publication number
ES2549125T3
ES2549125T3 ES08864638.5T ES08864638T ES2549125T3 ES 2549125 T3 ES2549125 T3 ES 2549125T3 ES 08864638 T ES08864638 T ES 08864638T ES 2549125 T3 ES2549125 T3 ES 2549125T3
Authority
ES
Spain
Prior art keywords
stability
connection
data 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
ES08864638.5T
Other languages
English (en)
Inventor
Philip Anthony Everett
Christopher Marcus Croot
Trevor Philip 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 ES2549125T3 publication Critical patent/ES2549125T3/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, que incluye una pluralidad de conexiones de datos (19) entre unos dispositivos de usuario final (14) y un dispositivo transceptor de agregación (20), en el que las conexiones se agregan para la conexión hacia delante a través de la red de acceso, comprendiendo el método: almacenar una pluralidad de perfiles, cada uno de los cuales especifica un conjunto de valores para una pluralidad de parámetros asociados a las conexiones de datos (19); para cada conexión de datos (19), monitorizar la estabilidad de la conexión (19); seleccionar uno de entre dichos perfiles almacenados para su aplicación a la conexión (19); y aplicar el perfil seleccionado a la conexión de datos (19); caracterizado por que comprende asociar un nivel de estabilidad (115), que especifica un nivel deseado de estabilidad, a cada conexión de datos (19), de entre una pluralidad de niveles de estabilidad diferentes (115) de manera que los niveles de estabilidad diferentes (115) controlen las circunstancias bajo las cuales se efectúa una transición de una conexión (19) entre perfiles diferentes; y por que la etapa de selección se lleva a cabo en función tanto de los resultados de la monitorización de la conexión (19), como del nivel de estabilidad (115) asociado a la conexión de datos (19).

Description

15
25
35
45
55
65 E08864638
05-10-2015
DESCRIPCIÓN
Comunicación de datos.
Campo de la invención
La presente invención se refiere a la comunicación de datos. En particular, se refiere a la gestión de una red de acceso que incluye conexiones de Línea de Abonado Digital (DSL).
Antecedentes de la invención
La Gestión Dinámica de Líneas (DLM) es una técnica para mejorar la estabilidad de conexiones de DSL. Resulta particularmente útil cuando se trabaja con conexiones de DSL cerca de su velocidad máxima, ya que, en estas condiciones, el ruido externo que afecta a la señal transmitida puede provocar que los transceptores sean incapaces de recuperar satisfactoriamente la señal a transmitir, con la suficiente fiabilidad para permitir el mantenimiento de la conexión. Si se produce esto, es necesario volver a establecer la conexión. A esto se le hace referencia como resincronización y el usuario percibe una pérdida temporal de servicio mientras la conexión se vuelve a establecer. En general, las re-sincronizaciones son percibidas como particularmente molestas por los usuarios finales.
La DLM busca minimizar dichas re-sincronizaciones analizando automáticamente conexiones de DSL (especialmente la tasa de aparición de re-sincronización) y variando ciertos parámetros que pueden afectar a la probabilidad de aparición de resincronizaciones (por ejemplo, la profundidad de intercalación, la cantidad de redundancia incorporada en la codificación usada, etcétera). Típicamente, esto se realiza utilizando varios perfiles diferentes que presentan varios conjuntos diferentes de valores para los parámetros que es más probable que tengan un impacto sobre la estabilidad o alternativamente de una conexión de DSL, y cambiando una conexión 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 telefónica (central office)) habitualmente en un equipo conocido como Multiplexor de Acceso de Línea de Abonado Digital (DSLAM) el cual alberga varias unidades transceptoras de DSL tal como es sabido ampliamente en la técnica.
Típicamente, en términos conceptuales se puede considerar que los perfiles están dentro de una gama que los califica de más agresivos a menos agresivos, donde los perfiles más agresivos tienden a proporcionar servicios mejores al usuario (en términos de velocidades de bit especialmente mayores y latencias menores), aunque presentan una mayor probabilidad de dar como resultado inestabilidades en la línea, mientras que los perfiles menos agresivos tienden a ofrecer velocidades de bits y/o latencias inferiores aunque estabilidades mayores.
Un Libro Blanco de Tecnología 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_tcm172228691635.pdf describe la DLM y sugieren en líneas generales una implementación en la cual se producen una Fase de Validación y una Fase de Operaciones. En la fase de validación, una conexión se monitoriza de forma bastante exhaustiva para identificar un perfil apropiado para la línea y, a continuación, se monitoriza menos exhaustivamente para garantizar que el perfil seleccionado originalmente continúa siendo válido. Este documento menciona también que operadores definen “un conjunto de políticas para cada clase de servicio”; esto implica que clases de servicio diferentes pueden presentar perfiles posibles diferentes entre los cuales pueden realizar transiciones. Así, por ejemplo, para una clase de servicio asociada al vídeo en flujo continuo hacia un usuario final, el operador puede imponer una intercalación puesto que, rara vez, se produce una necesidad de un retardo muy bajo, aunque la fiabilidad es importante para mantener una imagen de buena calidad. Además, tampoco se requiere frecuentemente un ancho de banda muy alto y, por lo tanto, el operador puede eliminar perfiles de margen muy bajo como opción para dicha clase de servicio (incluso en el caso de que una línea pudiera soportarlos).
La solicitud de patente europea en trámite n.º 07250428.5 describe una solución 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 acción 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 monitorización más minuciosa en una escala de tiempo mayor.
La solicitud de patente publicada US n.º 2006/0198430 describe una solución de DLM en la cual se usan varias reglas, tales como matrices de transición, para determinar bajo qué circunstancias debería realizarse una transición desde un perfil a otro.
Todas las soluciones de DLM conocidas para los presentes solicitantes pueden fijar varios parámetros con el fin de intentar mantener las líneas en los que se considera como un nivel aceptable de estabilidad. No obstante, los presentes inventores han observado actualmente que esto da como resultado una solución inflexible que resulta adecuada en un nivel inferior al óptimo, para una red de acceso en la cual se puedan usar conexiones de DSL diferentes para finalidades diferentes.
15
25
35
45
55
65 E08864638
05-10-2015
Sumario de la invención
De acuerdo con un primer aspecto de la invención, se proporciona un método de funcionamiento de una red de acceso de acuerdo con lo que se expone en la reivindicación 1.
Así, el método de la presente invención permite la aplicación de políticas 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 conexión que pueden imponer valores diferentes sobre los méritos relativos de estabilidad de la línea, ancho de banda y latencia. Preferentemente, las diferentes políticas de estabilidad controlan las circunstancias bajo las cuales una conexión realizará una transición entre perfiles diferentes (por ejemplo, tolerando un número mayor de errores o re-sincronizaciones por unidad de tiempo antes de efectuar una transición a un perfil menos agresivo y viceversa).
La asignación de una política de estabilidad a una línea particular se puede basar en varios factores diferentes. Preferentemente las preferencias de los usuarios finales a este respecto serán un factor importante, y preferentemente se pueden aplicar políticas de estabilidad diferentes a líneas que funcionen con la misma clase de servicio básica. Así, por ejemplo, dos usuarios que tengan una conexión de banda ancha básica (es decir, destinada a un uso general de Internet en lugar de una línea dedicada a proporcionar vídeo al flujo continuo, etcétera) podrían usar dichas conexión para finalidades diferentes. Por ejemplo, un usuario puede realizar simplemente una navegación por internet y una transmisión de vídeo en flujo continuo que consuman un ancho de banda bastante bajo, otro puede usarla para efectuar grandes descargas de datos, y otro podría usarla con finalidades relacionadas con el juego en línea. Estos usuarios diferentes pueden tener claramente tolerancias a los niveles de estabilidad muy diferentes. Por ejemplo, el primer usuario, que en general no impone ninguna gran exigencia sobre la conexión de banda ancha, puede ser claramente menos tolerante a errores e interrupciones y, por lo tanto, preferiría en general obtener una mayor estabilidad con el riesgo de disponer quizás de un ancho de banda máximo disponible ligeramente inferior, en comparación con el segundo usuario el cual en conjunto prefería tener una conexión ligeramente menos estable pero que pueda lograr (cuando esté conectada) caudales elevados.
Preferentemente, los resultados de la monitorización de la estabilidad de cada línea incluyen un parámetro que representa el número de resincronizaciones forzadas que se producen en un periodo de tiempo predeterminado (por ejemplo, en un periodo de 24 horas), y el nivel de estabilidad determina un par de umbrales para cada uno de estos parámetros que, si son superados, provocarán que se realice una transición de esa conexión particular desde un perfil de DLM a otro. Por ejemplo, un nivel de estabilidad agresivo (relativamente inestable) podría requerir que se produjeran más de 10 resincronizaciones forzadas dentro de cualquier periodo dado de 24 horas, para que el sistema decidiera realizar una transición de la conexión desde su perfil de DLM actual a un perfil de DLM más estable, mientras que una transición para una conexión asociada a un nivel de estabilidad normal se podría activar al detectar más de 5 resincronizaciones forzadas dentro de un periodo cualquiera de 24 horas; y una asociada a un nivel de estabilidad deseado muy estable podría realizar una transición a un perfil nuevo de DLM más estable si se detectan más de 1 resincronización forzada en cualquier periodo dado de 24 horas. Posteriormente se ofrece una descripción más detallada de este mecanismo. Si no se ha superado dicho umbral, entonces la conexión permanece en su perfil actual. Por otro lado, si se supera un umbral en la otra dirección (obsérvese que esto podría funcionar en una escala de tiempo diferente – normalmente mayor), entonces se podría realizar la transición de la conexión a un perfil menos estable con el fin de mejorar el ancho de banda o latencia, etcétera. Así, por ejemplo, si una conexión asociada a un nivel agresivo (es decir, un nivel de estabilidad deseado relativamente bajo) determina que no se ha producido más de un error forzado cada 24 horas durante, por ejemplo, 6 periodos consecutivos de 24 horas, entonces se puede realizar una transición de la misma a un perfil más agresivo, mientras que una conexión que desee un rendimiento muy estable únicamente podría realizar una transición a un perfil más agresivo si se detecta que no se han producido resincronizaciones forzadas en un periodo de 30 días, etcétera.
Preferentemente se varían dos parámetros principales que controlan el funcionamiento de conexiones de xDSL para generar perfiles diferentes, el margen de la Relación Señal/Ruido (SNR) y el modo rápido/de intercalación. Obsérvese que en general las políticas de estabilidad no afectan a los perfiles que están disponibles para que una línea particular realice una transición entre ellos, sino que más bien influyen las circunstancias bajo las cuales se producirá dicha transición. En las soluciones de la técnica anterior, de las cuales tiene conocimiento el solicitante, se usan los mismos umbrales (por ejemplo, en términos del número de errores y/o interrupciones por unidad de tiempo) para determinar que un perfil particular es viable o no ha sido usado, con independencia de la clase de servicio, etcétera. Esto ha conducido a un sistema inflexible en el cual resulta imposible permitir que algunos clientes especifiquen que desean líneas muy estables, al mismo tiempo que otros tienen líneas que son menos estables (aunque con las expectativas consiguientes de obtener velocidades mayores del ancho de banda). Por contraposición, en formas de realización preferidas de la presente invención, se usan umbrales diferentes para determinar cuándo realizar una transición desde un perfil a otro en función del nivel de estabilidad asociado de la línea en cuestión.
El margen de SNR representa la cantidad de redundancia incorporada a la velocidad de bits seleccionada (y otras opciones de la conexión) para la conexión, dado el valor medido de la SNR concreta que experimenta el módem.
15
25
35
45
55
65 E08864638
05-10-2015
Así, cada conjunto posible de valores significativos para los parámetros de la conexión (es decir, la velocidad de bits, el nivel de la codificación reticulada, el nivel de intercalación, etcétera) tiene una SNR de línea basal correspondiente que representa el valor mínimo de la SNR en el cual se esperaría que funcionase la conexión con una Tasa de Errores de Bit (BER) de 10-7 (es decir, se espera 1 bit erróneo por cada 107); a esta BER de 10-7 se le denomina tasa objetivo en la medida en la que se espera que la conexión 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 línea basal en el momento de establecer la conexión. Así, la SNR recibida real puede variar con el tiempo, después de establecer la conexión, por debajo de la cantidad medida en el establecimiento de la conexión hasta en una cantidad correspondiente al margen y se seguiría esperando todavía que la conexión funcionase con una BER inferior o igual a la cantidad objetivo (es decir, por lo menos tan buena como la cantidad objetivo).
La definición de margen de SNR que se proporciona en la norma de xDSL ITU G992.1 Sección 9.5.1 es: “Margen de la Relación Señal/Ruido (SNR): el margen de la relación de señal/ruido representa la cantidad de aumento de ruido recibido (en dB) con respecto a la potencia de ruido que está diseñado para tolerar el sistema y cumplir todavía con la BER objetivo de 10-7, teniendo en cuenta todas las ganancias de codificación (por ejemplo, codificación reticulada, RS FEC) incluidas en el diseño. El margen de la SNR varía de -64,0 dB a +63,5 dB con pasos de 0,5 dB”.
De este modo, se apreciará que cuanto menor sea el Margen de SNR, mayor será la velocidad de bits significativa que se podrá alcanzar (es decir, suponiendo que no se produzcan errores). En cambio, cuanto mayor sea el Margen de la SNR, más probable será que la conexión funcione de una manera estable, incluso en un entorno de ruido fluctuante.
El modo rápido/de intercalación conmuta la profundidad de intercalación entre intercalación no existente (modo RÁPIDO) y cualquiera de las profundidades de intercalación definidas en las normas de ADSL aplicables actualmente (por ejemplo, las normas ITU G.992.x). En muchas implementaciones, por el momento se usa únicamente el nivel de intercalación más bajo (una profundidad de 2, en donde unidades de una única palabra de código que son adyacentes antes de la intercalación se separan por una unidad intercalada, con respecto a otra palabra, después de la intercalación); no obstante, esto puede cambiar en el futuro. Tal como es bien sabido en la técnica, el uso de la intercalación ofrece protección contra picos de ruido de corta duración intercalando unidades (por ejemplo, bytes) de un cierto número (en función de la profundidad de intercalación) de palabras de código (que comprenden, cada una de ellas, varias unidades), donde cada palabra de código tiene una cierta cantidad de protección contra errores, de tal manera que un número relativamente pequeño de unidades con error por cada palabra de código puede ser recuperado por el mecanismo de protección contra errores para recuperar completamente la palabra de código original (por ejemplo, si hay 5 unidades (por ejemplo, bytes) por cada palabra de código y el mecanismo de corrección de errores puede recuperar palabras de código en donde una unidad es errónea, una profundidad de intercalación de 2 permitiría recuperar las dos palabras intercaladas si un ruido provocase la alteración de dos unidades adyacentes dentro de un periodo de transmisión de dos palabras). La intercalación proporciona protección contra ruidos impulsivos a costa del aumento de la latencia (y requisitos más elevados de almacenamiento temporal de los equipos de red).
La funcionalidad (o sub-componentes de esta funcionalidad) de la presente invención puede ser realizada por varios dispositivos diferentes. En particular, el nivel de estabilidad se puede almacenar dentro del dispositivo transceptor de agregación (por ejemplo, el DSLAM) o un dispositivo asociado al mismo. Esto se correspondería con una forma de realización en la cual el controlador/operador de la red de acceso asume la responsabilidad de implementar políticas 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 conexión diferentes (tal como se produce generalmente) y para casos en los que la conexión no desea realizar una transición entre políticas de estabilidad diferentes de una manera muy frecuente (por ejemplo, en función de la aplicación particular que es usada por el dispositivo de usuario en cualquier momento particular), puesto que provocaría dificultades para un sistema centralizado que debe de hacer frente de una manera muy rápida a lo que potencialmente podría ser muchos clientes.
No obstante, en una forma de realización alternativa, las políticas de estabilidad se pueden almacenar en el dispositivo de usuario final respectivo. Basándose en la política de estabilidad seleccionada (y con un conocimiento adecuado del nivel de estabilidad que está intentando proporcionar el DSLAM para esa conexión de datos), el dispositivo de usuario puede incluir cierta funcionalidad (por ejemplo, proporcionada por un programa de ordenador adecuado) que intercepte mensajes del módem de DSL del dispositivo de usuario final destinados al módem de DSL del lado de la red (por ejemplo, ubicado en el dispositivo transceptor de agregación) y modifique estos mensajes para conseguir que el módem de DSL del lado de la red establezca una conexión de DSL que sea más o menos agresiva (en términos de ancho de banda o de latencia o de ambos aspectos) que si los mensajes no hubieran sido modificados así. De manera equivalente, el funcionamiento normal del módem de DSL simplemente se podría modificar de tal modo que para políticas o niveles de estabilidad diferentes el módem genere mensajes diferentes que serán devueltos al módem de DSL del lado de la red.
Un ejemplo de un programa de ordenador que funciona de esta manera general y el cual se podría usar (preferentemente con algunas modificaciones adecuadas que se describen posteriormente) para esta finalidad es la “herramienta de DMT” la cual está disponible para su descarga en http://dmt.mhilfe.de/. Este programa funciona
15
25
35
45
55
65 E08864638
05-10-2015
enviando información sobre características de la conexión (especialmente la SNR) que no se basa puramente en lo que ha sido detectado por el módem de acuerdo con el funcionamiento normal de este último. En su lugar, con la herramienta de DMT, esta información puede ser introducida directamente por un usuario de la herramienta, sobrescribiendo así la información que sería enviada normalmente por el módem. No obstante, en una forma de realización preferida de la presente invención, este programa no se usaría para modificar los valores de SNR (o no se usaría solamente para modificar los valores de SNR) comunicados por el módem de usuario final al módem del lado de la red, sino más bien (o adicionalmente) el número de errores (especialmente el número de segundos con errores) que se producen en la dirección del sentido descendente y los cuales dependen de las características medidas reales así como el nivel de estabilidad asociado a la política de estabilidad actualmente en vigor para la conexión.
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 conexión, aunque esto se realiza habitualmente al menos de forma parcial como respuesta a mensajes provenientes del módem de DSL del usuario final. Preferentemente, los parámetros usados para determinar si se debería realizar o no un cambio de perfil incluyen el número de veces que se ha producido una re-sincronización sobre una conexión DSL dentro de un cierto periodo de tiempo y el número de segundos con errores que se han producido dentro de un cierto periodo de tiempo (por ejemplo, dentro de las últimas 24 horas).
Preferentemente, el sistema incluye de manera adicional un selector de políticas de estabilidad que selecciona una política de estabilidad apropiada basándose en el uso (o uso deseado o solicitado) de la conexión. Preferentemente el selector es configurable por el usuario u operador, y preferentemente actúa como una máquina de estados, con lo cual algunas circunstancias pueden dar como resultado la adopción de una política 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 está en el estado estable y el usuario conmuta de una aplicación de flujo continuo de vídeo a navegación web, el selector puede cambiar el estado de estable a normal, mientras que si el selector está en el estado agresivo y el usuario conmuta de una aplicación de juego a navegación web, el selector puede que no cambie de estado, etcétera. Igual que con el almacenamiento del nivel de estabilidad política, este selector también se podría implementar o bien en el lado de la conexión de DSL correspondiente al usuario final (que se corresponde con la forma de realización en la que el control de la política de estabilidad reside en el dispositivo de usuario final) o bien en el lado de la conexión de DSL correspondiente a la red/DSLAM (que se corresponde con la forma de realización en la que el operador de la red tiene la responsabilidad de la política o nivel de estabilidad aplicados actualmente para la conexión).
Preferentemente, el selector incluye medios para provocar una re-sincronización de la conexión de DSL en la que realiza una transición de un estado a otro.
Preferentemente, las conexiones de datos son líneas de abonado digitales que incluyen unidades transceptoras remotas y centrales conectada a través de un par de cobre y que funcionan de acuerdo con una o más de las diversas normas de xDSL acordadas por la Unión Internacional de Telecomunicaciones (ITU) (por ejemplo, G.992.x y sus anexos). Preferentemente, el dispositivo transceptor de agregación 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 más agresivos es más probable que den como resultado una conexión que se convierta en inestable.
Preferentemente, la monitorización de la conexión incluye determinar o estimar el número de veces que la conexión respectiva resincroniza, en un periodo de tiempo dado, como consecuencia de una resincronización automática o forzada y usar el número determinado o estimado de resincronizaciones forzadas cuando se determina si realizar o no una transición a un perfil nuevo.
Preferentemente, el factor de medición del número de resincronizaciones por unidad de tiempo se modifica para eliminar (hablando en términos generales, por lo menos algunas de) las resincronizaciones provocadas por la acción del usuario, en lugar de por causa de que la línea experimente problemas técnicos o inestabilidad, etcétera, proporcionando así un factor de medición más útil para su uso en la ejecución de la Gestión Dinámica de Líneas.
Una re-sincronización automática o forzada es aquella que se produce debido a que errores en la conexión provocan una pérdida completa de la conexión. Cuando esto ocurre, los módems finales vuelven a un estado inicial en el que se vuelve a establecer una conexión desde cero, en lugar de intentar rescatar la conexión previa. Esto se expone 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 Toma de Contacto para transceptores de líneas de abonado digitales (DSL).
Preferentemente, la determinación o estimación del número de resincronizaciones forzadas comprende determinar el número total de resincronizaciones (en el periodo de tiempo dado de interés) por todos los motivos, estimar el número total de aquellas resincronizaciones provocadas por un usuario y restar este número estimado de
15
25
35
45
55
65 E08864638
05-10-2015
resincronizaciones provocadas por el usuario para obtener una estimación del número de resincronizaciones forzadas.
Preferentemente, la etapa de estimar el número de resincronizaciones provocadas por el usuario comprende detectar que ha transcurrido más de un periodo de tiempo mínimo predeterminado antes o después de una resincronización sin que se haya establecido una conexión y sin que la línea intente automáticamente volver a establecer la conexión, aunque no consiguiéndolo. Así, si el usuario simplemente apaga o desenchufa el módem durante un periodo de tiempo mayor que el periodo de tiempo mínimo, se determina que la re-sincronización resultante es una re-sincronización provocada por un usuario en lugar de una resincronización forzada. Preferentemente, esto se logra contando los periodos contiguos de tiempo de indisponibilidad que superan el periodo mínimo predeterminado dentro del periodo dado (más largo).
En una forma de realización, se mantiene un registro de cada periodo (compartimento) de 15 minutos durante el cual no hay ninguna conexión en marcha, y el número de conjuntos de periodos contiguos en los cuales no se registra ninguna conexión en marcha dentro de cualquier periodo de 24 horas (lote) se toma como el número estimado de resincronizaciones provocadas por el usuario en ese periodo de 24 horas; naturalmente, en formas de realización 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, etcétera). El número de periodos contiguos (compartimentos) se puede determinar convenientemente contando el número de transiciones entre periodos (compartimentos) en los cuales no se registran conexiones como presentes, y periodos (compartimentos) en los cuales se registra una conexión como presente.
Otros aspectos de la presente invención se refieren a sistemas, dispositivos, programas de ordenador y medios portadores o soportes según se expone en las reivindicaciones adjuntas, especialmente medios portadores tangibles, tales como dispositivos de almacenamiento óptico (por ejemplo, discos compactos (CD’s) o DVD’s), o dispositivos de almacenamiento magnético, tales como discos magnéticos, o dispositivos de memoria no volátil de estado sólido.
Breve descripción de las figuras
Para que la presente invención se pueda entender mejor, a continuación se describirán formas de realización de la misma, únicamente a título de ejemplo, y en referencia a los dibujos adjuntos en los cuales:
la Figura 1 es un diagrama de bloques esquemático que ilustra una red de telecomunicaciones que incorpora un dispositivo de gestión que funciona de acuerdo con un método según la presente invención;
la Figura 2 es un diagrama de bloques esquemático que ilustra el dispositivo de gestión de la Figura 1 de forma más detallada; y
la Figura 3 es un diagrama de flujo que ilustra las etapas llevadas a cabo por el dispositivo de gestión 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.
Descripción detallada de formas de realización
La forma de realización principal que se describe a continuación utiliza un dispositivo de gestión 100 para llevar a cabo dos funciones principales – aprovisionamiento del Servidor de Acceso Remoto de Banda Ancha (BRAS) y Gestión Dinámica de Líneas (DLM). El aprovisionamiento del BRAS se describe brevemente en esta solicitud, para completar la descripción, aunque se describe de forma más detallada en las solicitudes de patente internacional en trámite 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 métodos preferidos de aprovisionamiento de BRAS aplicables en la forma de realización principal.
En cuanto a la función de DLM, esta es deseable en la forma de realización principal ya que la velocidad de sentido descendente de las conexiones de ADSL controladas por el dispositivo de gestión de la velocidad de la forma de realización principal se adapta a la velocidad más alta que puede soportar la línea desde 2 Mb a 8 Mb. En la medida en la que las conexiones de ADSL están trabajando en sus límites superiores, las mismas son más susceptibles al ruido lo cual puede provocar errores y resincronizaciones (resyncs) espontáneas.
En líneas generales, el papel de la función de DLM del dispositivo de gestión es garantizar que las conexiones de ADSL proporcionan un buen compromiso entre la estabilidad de la línea y el rendimiento de esta en términos de velocidad de bits (o quizás, lo que es más importante, la velocidad a la cual un usuario puede recibir datos deseados
– después de que, por ejemplo, se hayan vuelto a enviar todos los paquetes perdidos por causa de errores) y la latencia. La función de DLM lleva a cabo esto recibiendo datos de Recopiladores de Datos de DSLAM cada día y procesando estos datos recibidos. A continuación, la función de DLM puede aumentar o reducir los márgenes de ruido (es decir, los márgenes de SNR) y/o intercalar niveles, según se requiera, fijando un perfil nuevo para cada conexión de ADSL (utilizando los sistemas de aprovisionamiento existentes para fijar perfiles en los DSLAM’s). Esta
15
25
35
45
55
65 E08864638
05-10-2015
funcionalidad básica se potencia con módulos lógicos para minimizar el embarullamiento u oscilación de perfiles (intentando estabilizar el perfil de DSLAM para cada conexión, en lugar de reaccionar a cada cambio pertinente en el entorno de la conexión lo cual podría provocar el cambio del máximo perfil estable aplicable).
Forma de realización principal
En referencia a la Figura 1, se ilustra en líneas generales una primera forma de realización de la presente invención. 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 también como central telefónica. El DSLAM separa tráfico de voz normal y tráfico de datos y envía el tráfico de voz a la Red Telefónica Pública Conmutada (PSTN) 70. El tráfico de datos se hace pasar a través de una red 30 de Modo de Transferencia Asíncrono (ATM) que constituye el resto de la red de acceso 19, 20, 30 (en la presente forma de realización, 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 tráfico IP o circuitos de ATM de (y en) múltiples 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 teléfono 12, un módem 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 podría ser el BRAS 40; mientras que, en otros casos, el primer salto desde la perspectiva de un IP podría situarse más allá del BRAS 40.
En todos los casos, el módem 16 del usuario final crea una sesión de Protocolo de Punto-a-Punto (PPP) desde el módem a otro dispositivo en la red. Esta es una conexión lógica de extremo a extremo que lleva el tráfico de los usuarios finales desde el módem a la red IP de destino.
En algunos casos (por ejemplo, en el producto Central+ de BT), la sesión de PPP se hace terminar en el BRAS, y a continuación 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 configuración de ejemplo en la que la sesión de PPP no se hace terminar en el BRAS 40, la sesión de PPP termina en una “pasarela doméstica” en el borde de la red central, conectada al Proveedor de Servicios (SP). En otra configuración de ejemplo (por ejemplo, tal como en el producto central de BT) se usa un túnel del Protocolo de Tunelización de la Capa 2 (L2TP) para pasar a través del BRAS 40 hasta un BRAS de terminación que pertenece al SP; el túnel de L2TP tuneliza todas las sesiones de PPP hacia la red del SP para que las mismas realicen la gestión que deseen.
En todos los casos, el primer salto de IP se produce desde el usuario final al BRAS de terminación (es decir, a través de la conexión de PPP). Además, en todos los casos, el BRAS 40 es responsable de imponer políticas sobre la cantidad de tráfico que fluye en sentido descendente (es decir, desde la red hacia el equipo en las instalaciones del cliente) en dirección a cada línea conectada al BRAS 40, para garantizar que la misma no supere una cantidad máxima prevista para esa línea. Esta aplicación de políticas se realiza o bien en la capa de IP (donde el BRAS 40 termina una conexión 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 tunelización por debajo de la capa IP a través del BRAS 40.
La disposición antes mencionada de los elementos 10, 19, 20, 30, 40, 50, 62, 64, 66 y 70 es convencional. No obstante, además de esta disposición convencional, en la presente forma de realización existe un dispositivo de gestión 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 función de DLM) se explica más detalladamente a continuación en referencia a las Figuras 2 y 3. No obstante, en líneas generales, obtiene información del DSLAM 20, sobre la velocidad a la que se conecta cada Línea de Abonado Digital (DSL) al DSLAM, e información sobre eventos, tales como errores detectados y/o resincronizaciones que se producen en la línea/conexión, y modifica el funcionamiento de los DSLAM’s en relación con la agresividad del perfil usado por un DSLAM respectivo para una conexión de DSL respectiva.
Tal como se muestra en la Figura 2, el dispositivo de gestión 100 comprende dos partes funcionales principales, una función de aprovisionamiento de BRAS o control de BRAS 120 y una función de Gestión Dinámica de Líneas (DLM)
110.
La función de aprovisionamiento de BRAS 120 procesa parte de la información recibida desde los DSLAM’s para evaluar una velocidad de conexión congruente lograda por cada DSL. Si determina que esta velocidad congruente se ha incrementado como resultado de conexiones recientes de mayor velocidad, da órdenes al BRAS para permitir flujos de tráfico pasantes mayores para ese DSL. Por otro lado, si detecta que una velocidad de conexión particular
15
25
35
45
55
65 E08864638
05-10-2015
está por debajo del valor congruente almacenado, reduce el valor congruente hasta el valor de conexión actual, e informa inmediatamente al BRAS de la nueva velocidad de valor congruente de manera que el BRAS no permite que fluya más tráfico hacia el DSL del que sea capaz de soportar el DSL en ese momento.
En las solicitudes internacionales en trámite GB2006/002826 y GB2006/002818 se describen detalles precisos de algunos de los algoritmos que pueden ser usados por la función de Control de BRAS 120 del dispositivo de gestión 100 para calcular una velocidad congruente en la presente forma de realización. No obstante, debe indicarse que la intención de estos algoritmos es disponer que el usuario reciba datos con la velocidad más 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 máxima. Al mismo tiempo, los algoritmos buscan garantizar que si una DSL se conecta a una velocidad que está por debajo de aquella a la que está configurado en ese momento el BRAS para permitir datos a través de él para esa DSL, entonces el BRAS se reconfigura rápidamente para evitar la sobrecarga del DSLAM.
Posteriormente se exponen detalles del algoritmo particular utilizado en la presente forma de realización por la función de DLM. No obstante, en líneas generales, una sub-función de recepción 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 conexión de DSL y por día, junto con información sobre una política o nivel de estabilidad asociados a cada conexión. Estos datos se usan en una sub-función de análisis 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 política o nivel de estabilidad asociado respectivo de la conexión. Si se requieren cambios, una subfunción de salida de DLM envía una solicitud al Sistema de Soporte de Operaciones (OSS) de la red de acceso para el perfil aplicado a la línea que se va a cambiar. La forma precisa en la que se realiza esto dependerá de los detalles de OSS de la red de acceso en particular y no es relevante para la presente invención por lo que no se describirá de forma adicional en este documento.
Cada una de las sub-funciones de DLM mencionadas anteriormente se implementa mediante componentes de un procesador de ordenador convencional que funcionan de acuerdo con módulos de código de software almacenados en una memoria 112 que forma parte de la función de DLM 110; en particular, un módulo de código de recepción de datos de DLM 114 (ENTRADA DE DATOS) provoca la implementación de la sub-función de recepción de datos de DLM, un módulo de código de análisis de DLM 116 (ANÁLISIS DE DATOS) provoca la implementación de la subfunción de análisis de DLM y un módulo de código de salida de DLM 118 (SALIDA DE DATOS) provoca la implementación de la sub-función de salida de DLM. Adicionalmente, la memoria 112 almacena también el conjunto de datos de política de estabilidad 115 (POLÍTICAS DE ESTABILIDAD) en el cual se mantiene el nivel o política de estabilidad asociados a cada conexión de DSL gestionada por el dispositivo de gestión. Además, en la presente forma de realización, la memoria 112 almacena también un módulo de estimación de resincronizaciones forzadas 117 (EST. RESINCRONIZACIONES FORZADAS) para implementar una sub-función con el fin de estimar el número de resincronizaciones para cada línea en cada lote de datos generadas como consecuencia de algún tipo de error, por ejemplo, que se producen en la conexión en lugar de como consecuencia de acciones del usuario (por ejemplo, apagar o desconectar su módem de DSL). Esta sub-función de estimación de resincronizaciones forzadas se describe de forma más detallada posteriormente.
Debe indicarse que, en la presente forma de realización, la sub-función de recepción de datos (114) constituye el receptor reivindicado para recibir datos de monitorización que especifican la estabilidad de cada conexión de datos durante un periodo de tiempo predeterminado, el módulo de código de análisis de DLM constituye el módulo de código de programa de ordenador destinado a provocar que el procesador determine si se debería realizar una transición de cada una de las conexiones de datos a un perfil nuevo en función tanto de los datos de monitorización como del nivel de estabilidad asociados a la conexión de datos, y el módulo de código de programa de ordenador destinado a provocar que el procesador seleccione un perfil de DLM nuevo a aplicar en cada conexión en caso de que el procesador determine que se debería realizar una transición de la conexión de datos correspondiente a un perfil de DLM nuevo; y la sub-función de salida de DLM (118) constituye el solicitante reivindicado (véase la reivindicación 10).
La fuente principal de datos de entrada para la función de DLM es un archivo diario de cada gestor de elementos, que proporciona un informe agregado de la actividad de cada línea 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 reconfiguración del DSLAM cada vez que una línea se resincroniza. No obstante, de forma adicional, la función de DLM recibe además datos de entrada que especifican un nivel de estabilidad para cada línea. En la presente forma de realización, estos se introducen desde una base de datos en la cual un operador introduce manualmente los datos como parte del proceso de aprovisionamiento de una conexión de DSL nueva y se almacenan dentro del conjunto de datos de políticas de estabilidad 115 en la memoria de DLM 112. Así, en la presente forma de realización, la intención es que, cuando un cliente solicite una conexión de DSL, se le ofrezcan niveles diferentes de estabilidad (los cuales serán los más adecuados para ciertos tipos diferentes de actividad); así, los clientes que pretendan principalmente usar la conexión para flujo continuo de vídeo se beneficiarán de una conexión estable, mientras que los clientes que usen mayormente su conexión para descargar archivos grandes, etcétera, se beneficiarían de una velocidad de bits más alta en lugar que de niveles de estabilidad muy elevados. Alternativamente, en lugar de proporcionar este servicio basándose en cada usuario final
15
25
35
45
55
65 E08864638
05-10-2015
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 podría proporcionar la opción de seleccionar un nivel de estabilidad en nombre de sus clientes y podrían vender esto a sus clientes (usuarios finales) como una oferta de productos “especializados”.
No obstante, en formas de realización alternativas, el nivel de estabilidad se podría actualizar más dinámicamente, como consecuencia de una solicitud por parte del usuario. En una forma de realización de ejemplo, se podría proporcionar un servidor web para recibir solicitudes de usuario para un cambio de nivel de estabilidad (quizás con una frecuencia permitida máxima de solicitudes permitidas por usuario, por ejemplo, no más de una por hora o una por día, etcétera) y esto a continuación podría provocar, tan pronto como fuera posible, que la función de DLM volviese a ejecutar su proceso de comparación correspondiente a esa línea con el nivel de estabilidad recién solicitado y, si, como consecuencia de la comparación, se determina que resulta apropiado efectuar una transición a un perfil nuevo, entonces se realiza la transición al perfil nuevo, otra vez lo antes posible de manera que el usuario experimente una respuesta bastante dinámica a una solicitud de cambiar el nivel de estabilidad.
Cada vez que se comprueba una línea para ver si se debería cambiar su perfil (lo cual, en la presente forma de realización, se produce una vez cada 24 horas como parte de una función de procesado por lotes), se lee el nivel de estabilidad correspondiente asociado a esa línea y a continuación se fijan valores de umbral para esa línea en función del nivel de estabilidad asociado a la línea respectiva. A continuación, los datos del archivo diario son procesados y los datos correspondientes a la línea respectiva que se está analizando se comparan con los valores de umbral fijados para esa línea en función del nivel de estabilidad asociado a la línea. Si la comparación indica que debería realizarse una transición, entonces se emite una instrucción correspondiente al sistema de OSS para que se efectúe una transición correspondiente.
El perfil de DSLAM tiene los parámetros que se ajustan en los diversos perfiles diferentes disponibles para que la función de DLM escoja entre ellos, con el fin de mejorar la estabilidad de la línea o a la inversa mejorar la velocidad de bits o baja latencia de la conexión; el margen objetivo y el modo de ejecución (permitiendo este último el uso de intercalación). El perfil de línea por defecto que se aplica inicialmente a todas las líneas tiene un margen objetivo de 6db y la intercalación deshabilitada (a lo que se hace referencia normalmente como estar en el modo rápido). El cambio de estos parámetros se basa en dos factores de medición del rendimiento en la presente forma de realización, errores (en particular, en esta forma de realización, errores provocados por violaciones de código) y reacondicionamientos (es decir, re-sincronizaciones).
El número de errores y re-acondicionamientos se normaliza al tiempo de actividad (tiempo sincronizado total durante el periodo) para formar los factores de medición reales del rendimiento utilizados para determinar la estabilidad de la línea. Por ejemplo, 100 errores en 10 horas de tiempo de actividad después de la normalización es muy diferente (de manera bastante notable) a 100 errores en 1 minuto de tiempo de actividad. La normalización se lleva a cabo calculando un tiempo-medio-entre o bien errores o bien re-sincronizaciones. Además, en la presente forma de realización, el parámetro de re-acondicionamientos también se procesa, antes de su uso como factor de medición del rendimiento de la estabilidad, descontando el número de resincronizaciones que se consideran como resincronizaciones provocadas por el usuario, antes de calcular el tiempo-medio-entre resincronizaciones. En la presente forma de realización, esto se logra usando el siguiente método, tal como se especifica a continuación de acuerdo con el siguiente seudo-código:
[Obsérvese 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 realización) para una conexión de DSL particular – el tipo de la matriz (es decir, números de 1 bit, enteros de 1 byte, enteros cortos, números de coma flotante, etcétera) 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 debería usar para indicar tiempo de actividad cero en lugar del cero – no obstante, en la presente forma de realización, cada elemento comprende un entero corto entre 0 y 900 que especifica el número de segundos de tiempo de actividad en el compartimento respectivo de 15 minutos (es decir, 900 segundos)].
*** Comentario – método para contar el número de re-acondicionamientos no forzados en un periodo de 24 horas para una conexión dada
FIJAR reacondicionamientosnoforzados = 0
PARA (i =0a95) (
SI (tiemposdeactividad[i] = 0 Y tiemposdeactividad[i+1] !=0) ENTONCES reacondicionamientosnoforzados++
) DEVOLVER reacondicionamientosnoforzados.
El seudo-código anterior dice básicamente 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
15
25
35
45
55
65 E08864638
05-10-2015
decir, detectar una transición 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 número de (supuestas) re-sincronizaciones provocadas por el usuario. A continuación, este valor se resta del número total de reacondicionamientos detectados para la conexión respectiva en el periodo de 24 horas con el fin de obtener un número estimado de reacondicionamientos forzados para el periodo de 24 horas, y a continuación el tiempo de actividad total en segundos se divide por el número estimado de reacondicionamientos forzados para obtener un tiempo medio estimado entre re-acondicionamientos en segundos. En la presente forma de realización, la matriz tiemposdeactividad[] almacena el número de segundos de tiempo de actividad de cada compartimento, de manera que resulta sencillo obtener el tiempo de actividad total para la conexión simplemente sumando los valores de todos los elementos de la matriz.
Tras haberse calculado los factores de medición a usar en la evaluación de la estabilidad de la línea, se realiza una comprobación con respecto a los umbrales, etcétera, tal como se describe de forma más detallada posteriormente, y se realizará 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 rápido (es decir, uno rápido de 6dB realizaría una transición a uno intercalado de 6dB).
Si un cliente ha renunciado a la opción de aplicar intercalación (por ejemplo, debido a que una latencia baja es más importante para él que la velocidad de bits máxima – tal como suele ser el caso de clientes que son jugadores en línea o usuarios de VOIP o de videoconferencia), entonces las transiciones se realizan solamente entre perfiles de modo rápido (únicamente se varía el margen objetivo). Esto limita claramente la capacidad del proceso de DLM.
Antes de que se realice una transición, se efectúa una comprobación con respecto a la velocidad de la línea para garantizar que una línea tiene la capacidad de llevar a cabo la transición a un perfil nuevo sin padecer una caída de la velocidad de bits tan drástica que se situase por debajo de una velocidad de bits aceptable mínima predeterminada. Una transición se efectúa solamente si existe cierta confianza en que la línea tendrá la capacidad de soportar el servicio por encima de esta velocidad aceptable mínima una vez que se aplique el perfil nuevo. Por ejemplo, en la presente forma de realización una transición a un perfil de margen de ruido superior se efectúa 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 mínima según es determinada por el operador de la red – en la presente forma de realización, 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 Mínima es un parámetro que es determinado por el operador de la red mayorista y que se proporciona al proveedor de servicios como una indicación de la capacidad estimada de la línea, la FTR está 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 conexión cae alguna vez por debajo de la FTR puesto que esto es una indicación de que la línea está funcionando notablemente por debajo de la velocidad a la que se cree que tiene capacidad para funcionar). Si la línea es inestable y sin embargo no puede realizar la transición debido a que caería por debajo de su velocidad de bits aceptable mínima (es decir, la FTR), entonces esto se marca con una bandera para realizar una investigación posterior. En la presente forma de realización, la FTR se fija inicialmente a 2 Mbs y a continuación se vuelve a fijar al 80% de la Velocidad Estable Máxima detectada por la red durante los primeros 10 días de funcionamiento de la DSL en su modo adaptativo a la velocidad.
Si una línea no consigue sincronizarse entonces se efectuará una transición a un margen objetivo inferior. Si esto significa volver a un estado previamente inestable, entonces esto se marca con una bandera para realizar una investigación posterior, ya que la línea no está estabilizada de forma eficaz (aún cuando no se encuentra en el margen objetivo máximo). La línea se devuelve al estado inestable previo de manera que se puede proporcionar cierto nivel de servicio al cliente mientras tiene lugar una investigación.
Si una línea no consigue sincronizarse ni siquiera con el margen objetivo más bajo, entonces esto se marca con una flecha para realizar una investigación. Por ejemplo, puede que no sea capaz de soportar el servicio requerido o la línea puede estar defectuosa.
De manera similar, si una línea sigue siendo inestable con el margen objetivo posible máximo, entonces esto se marca con una bandera para realizar una investigación posterior. La línea por ejemplo puede estar defectuosa.
Si una línea es completamente estable, entonces en general la función de DLM cambia la línea a un margen objetivo (o profundidad de intercalación) menor para aumentar la capacidad disponible (o reducir la latencia) en la línea (recuérdese, 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 intercalación) en sentido ascendente y descendente. Así, si una línea se ha cambiado previamente desde un perfil con un margen objetivo inferior más agresivo (o menos intercalado) al margen objetivo actual (y la profundidad de intercalación), la misma, antes de que se vuelva a realizar una transición de ella de vuelta al perfil del margen objetivo (o profundidad de intercalación) inferior, debe esperar un
E08864638
05-10-2015
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 intercalación) menor.
En la presente forma de realización, hay un proceso manual para permitir la transición entre cualquier perfil de línea 5 (por ejemplo, un cambio de rápido de 3dB directo a intercalado de 15 dB es posible con intervención manual).
En la presente forma de realización, aquellas líneas que se han marcado con banderas para una investigación posterior se reparan pro-activamente con la esperanza de que se puedan reparar antes de que se genere cualquier informe de fallo.
10 Las solicitudes de perfiles nuevos para cambiar a un perfil menos agresivo se pueden producir a diario. Las decisiones sobre perfiles nuevos en líneas estables para cambiar a un perfil más agresivo con el fin de aumentar la capacidad total se realizan durante un periodo de tiempo más prolongado (el cual en general aumenta con el número de veces que la línea ha salido previamente del perfil objetivo debido a problemas de falta de estabilidad) según se
15 ha descrito en el párrafo anterior.
En la presente forma de realización, la primera sub-función de la función de DLM categoriza cada línea en una de cuatro categorías diferentes en función del número normalizado de errores y/o re-sincronizaciones según se comunique a la función de DLM en el archivo en bloque. Las categorías se corresponden con muy deficiente,
20 deficiente, aceptable y muy estable.
El flujo básico del proceso de DLM se muestra en la siguiente Tabla 1.
imagen1
25 Tabla 1
En la presente forma de realización, el avance general a través de los perfiles que se muestran en la Tabla 1 es el siguiente: si una línea se va a cambiar a un perfil más estable, el primer cambio es mudarse al perfil con el mismo margen objetivo aunque en modo intercalado en lugar de modo rápido, si la línea ya está en un modo intercalado,
30 entonces la línea se muda al siguiente perfil de margen objetivo más alto también en el modo intercalado. Si la línea se va a mudar en la dirección de aumentar la capacidad, la misma se mantiene en el mismo modo (es decir, rápido o intercalado) pero se muda al siguiente perfil objetivo más bajo, a no ser que se encuentre en el margen objetivo mínimo en modo intercalado, en cuyo caso se muda al perfil de margen objetivo mínimo en modo rápido.
35 En la segunda sub-función de la función de DLM, una línea categorizada como muy deficiente se traslada inmediatamente dos pasos en la dirección de una mejor estabilidad (por ejemplo, desde el perfil Rápido de 6dB se trasladaría al Intercalado de 9dB, desde el Intercalado de 6dB se trasladaría al Intercalado de 12dB, etcétera). Una línea categorizada como deficiente se traslada inmediatamente (aunque con una prioridad menor que el perfilado nuevo de toda línea categorizada como muy deficiente) un paso en la dirección de una mejor estabilidad (por
40 ejemplo, desde el Rápido de 6dB a Intercalado de 6 dB o desde intercalado de 9dB a Intercalado de 12dB). Una línea categorizada como aceptable se mantiene en su perfil actual (es decir, no se realiza ninguna acción). Una línea categorizada como muy estable se traslada (si se cumplen también los requisitos adicionales de evitar oscilaciones, etcétera) un paso en la dirección de una capacidad mayor (por ejemplo, desde el Rápido de 6dB a Rápido de 3dB, desde Intercalado de 9dB a Intercalado de 6 dB o desde Intercalado de 3dB a Rápido de 3dB).
45
15
25
35
45
55
65 E08864638
05-10-2015
En la presente forma de realización, cada línea se procesa una vez cada 24 horas con el fin de determinar cómo debería categorizarse la línea, y por lo tanto si debería seleccionarse un perfil nuevo para esa línea. 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 línea. Así, cada vez que una línea 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 realización, se fija a 13) se efectúa una solicitud al OSS para que el perfil de incremente en un paso a un nivel más agresivo, y a continuación los contadores de retardos se reinicializan. Además, cada vez que una línea 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 realización, 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 línea ha experimentado varios días buenos (de tal modo que el contador de retardos deficientes se ha decrementado hasta cero, por ejemplo, cinco días buenos sucesivos) solamente son necesarios 3 días sucesivos de la línea que tiene un funcionamiento deficiente para alcanzar el umbral deficiente provocando un nuevo perfil. Además, se usa un duplicador de retardos para incrementar el retardo (es decir, incrementando el umbral bueno) requerido antes de que a una línea que ha descendido desde un perfil más agresivo a un nivel de perfil menos agresivo se le permita volver a realizar una transición de vuelta al nivel más agresivo. Por lo tanto, el duplicador de retardos se incrementa (en la presente forma de realización hasta un máximo de 5) cada vez que se da un perfil nuevo a la línea en dirección a un nivel menos agresivo y a continuación los retardos se reinicializan (como en el caso en el que se da un perfil nuevo a la línea a un nivel más agresivo). La reinicialización de los retardos se efectúa de acuerdo con las siguientes fórmulas:
UMBRAL BUENO = UMBRAL BUENO POR DEFECTO + 2EXP(DUPLICADOR DE RETARDOS)
CONTADOR DE RETARDOS DEFICIENTES = CONTADOR DE RETARDOS BUENOS = 0
En la presente forma de realización, el UMBRAL BUENO POR DEFECTO se fija a 13 (es decir, equivalente a 14 días), el RETARDO DEFICIENTE POR DEFECTO se fija en la presente forma de realización a 3 (es decir, equivalente a 3 días) 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 línea efectúa una transición a un perfil menos agresivo el DUPLICADOR DE RETARDOS se incrementa hasta que después 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 realización, si se cambia la política a nivel de estabilidad de un usuario el duplicador de retardos se reinicia de vuelta a cero; además, 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 realización, se describe a continuación en referencia a la Figura 3 la funcionalidad específica de la función de DLM para permitir que líneas diferentes funcionen en niveles diferentes de estabilidad de acuerdo con políticas de estabilidad fijadas para cada línea. Resumiendo, en la presente forma de realización, antes de que el DLM lleve a cabo su función de categorización de líneas para una línea en particular, se determina su nivel de estabilidad asociado y a continuación la categorización 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 uso en la función de categorización. De este modo, en la etapa S5 se obtiene el nivel de estabilidad para la línea particular que se va a categorizar, junto con los datos de retardo almacenados para esa línea (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 continuación, 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 uso en el resto del proceso, y a continuación el proceso avanza a la etapa S15.
En la etapa S15, la función de DLM obtiene los datos actuales de error y re-sincronización que ha recibido con respecto a la presente línea que se está analizando. Estos se leen del archivo de datos diarios el cual se envía a la función de DLM diariamente tal como se ha descrito anteriormente. A continuación, el proceso avanza a la etapa S20.
La etapa S20 es la etapa responsable de categorizar concretamente líneas en una de cuatro categorías diferentes posibles: muy deficiente, deficiente, OK y buena. Para realizar esto, los dos factores de medición utilizados en la presente forma de realización, a saber el número de errores detectado (tanto en el módem de usuario como en el módem de red en el DSLAM) y el número de re-sincronizaciones (según registra el DSLAM) se comparan (después de la normalización 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 línea. La siguiente tabla 2 expone los diversos umbrales utilizados en la presente forma de realización.
5
10
15
20
25
30
35
40
45
50
55 E08864638
05-10-2015
Estabilidad
Factor de medición Muy deficiente Deficiente OK Bueno
Agresivo
Re-Acondicionamientos > 10 por hora Mtb<3.600 mtb<8.640 mtb≥8.640
Agresivo
Errores - Mtb<10 mtb<8.640 mtb≥8.640
Normal
Re-Acondicionamientos > 10 por hora Mtb<7.200 mtb<8.640 mtb≥8.640
Normal
Errores - Mtb<300 mtb<8.640 mtb≥8.640
Estable
Re-Acondicionamientos > 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 medición normalizados que se han calculado midiendo el tiempo total en segundos durante el cual la línea respectiva ha estado sincronizada durante el último periodo de 24 horas de la monitorización, por el número de reacondicionamientos o errores registrados en ese periodo. Para todos los casos, en la presente forma de realización, si se producen más de 10 re-acondicionamientos en cualquier periodo de una hora, se supone que la línea es muy deficiente, con independencia del número de errores registrados. Para líneas que funcionan en un nivel de estabilidad agresivo, si el tiempo medio entre reacondicionamientos es menor de 3.600 segundos (= 1 hora) (es decir, si por norma general se produce más de un re-acondicionamiento por cada hora de tiempo de actividad, por ejemplo, 6 re-acondicionamientos en menos de 5 horas de “tiempo de actividad”) (pero el mtb reacondicionamientos debería ser mayor de 360 segundos – que se corresponde con el umbral de 10 re-acondicionamientos por hora para determinar que la línea es muy deficiente) o si el tiempo promedio entre errores es menor de 10 segundos (de tiempo de actividad), entonces se considera que la línea es deficiente; si el tiempo promedio entre reacondicionamientos es menor de 2,4 horas (pero mayor de una hora) o el tiempo promedio entre errores es menor de una vez cada 2,4 horas (aunque mayor de una vez cada 10 segundos), entonces se considera que la línea está ok, mientras que si el tiempo promedio entre re-acondicionamientos es superior o igual a 2,4 horas y el tiempo promedio entre errores es superior o igual a 2,4 horas, entonces se considera que la línea es buena. A partir de la Tabla 2 anterior, resulta evidente de la misma manera cuáles son los umbrales para los otros niveles de estabilidad.
En una forma de realización alternativa, los niveles de estabilidad podrían funcionar de tal manera que, para el nivel de estabilidad más agresivo, la función de DLM intenta mantener las pérdidas de sincronización por debajo de 12 por cada periodo de 24 horas (incluyendo el apagado de módems/encaminadores lo cual cuenta como una pérdida de sincronización) e intenta mantener la línea 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 función de DLM intenta mantener las pérdidas de sincronización por debajo de 6 por cada periodo de 24 horas e intenta mantener la línea 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 función de DLM intenta mantener las pérdidas de sincronización por debajo de 3 por cada periodo de 24 horas e intenta mantener la línea libre de errores más del 99,98% (5.999/6.000 segundos) del tiempo de actividad, medido durante un periodo de 24 horas.
Tras haber categorizado la línea de acuerdo con la Tabla 2 (o algún mecanismo similar) en la etapa S20, el proceso prosigue hacia la etapa S25 donde se determina si la línea se ha categorizado como “deficiente/muy deficiente, OK,
o buena”. Si la línea se ha categorizado como deficiente/muy deficiente, el proceso prosigue hacia la etapa S30 en la cual se determina si la línea se ha categorizado como muy deficiente o deficiente. Si en la etapa S30 se determina que la línea 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 línea efectúe una transición de 2 pasos en la dirección menos agresiva, siempre que se encuentre por lo menos dos pasos por encima del nivel mínimamente agresivo (el cual, en la presente forma de realización, es Intercalado, 15 dB, tal como resulte evidente a partir de la Tabla 1), en caso contrario simplemente realiza una transición directa a este nivel mínimamente agresivo; si la línea ya se encuentra en este nivel mínimamente agresivo, permanece en él aunque se marca como una bandera un fallo en el sistema para que sea atendido por un ingeniero. Al completarse la etapa S35, el método prosigue hacia la etapa S60.
Si en la etapa S30 se determina que la línea 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 método prosigue hacia la etapa S45 en la cual el contador de retardos deficientes se incrementa (en uno), y a continuación el método 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 línea 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 método prosigue hacia la etapa S55 en la cual se emite una solicitud de OSS para que el perfil de DLM de la línea efectúe una transición de 1 paso en la dirección menos agresiva, siempre que no se encuentre ya en el nivel mínimamente agresivo (el cual, en la presente forma de realización es Intercalado, 15 dB, tal como se pone de manifiesto a partir de la Tabla 1), en caso contrario permanece en él (es decir, en el nivel mínimamente 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 método prosigue hacia la etapa S60.
15
25
35
45
55
65 E08864638
05-10-2015
En la etapa S60, a la que se llega o bien después de dar un perfil nuevo menos agresivo, de dos pasos, en la etapa S35, o bien después de dar un perfil nuevo de un paso en la etapa S55, el duplicador de retardos se incrementa en uno (con la condición de que no haya alcanzado ya su valor máximo de 5, en cuyo caso simplemente permanece en 5), y a continuación el umbral nuevo se reinicializa de acuerdo con la fórmula 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 método finaliza (para la línea respectiva que se está procesando) y la función de DLM continúa para analizar cualquier otra línea que requiera análisis en el proceso actual por lotes de periodos de 24 horas.
Si, en la etapa S25, se determina que la línea 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 más sino que por el contrario permanece en cero). Este decremento de los contadores de retardos para líneas que se han categorizado como OK garantiza que líneas que son solo ocasionalmente buenas o solo ocasionalmente malas pero que mayormente están OK, permanecerán en su configuración de perfil actual. Al completarse la etapa S65, el proceso (para la línea respectiva que se está procesando) finaliza.
Si en la etapa S25 se determina que la línea es “buena”, el método 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 línea en cuestión, (RETARDO 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 líneas que típicamente son buenas con la misma frecuencia que son deficientes, sean cambiadas a un perfil diferente. Al completarse la etapa S80, el proceso (para la línea respectiva que se esté 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 transición al perfil de DLM de la línea en un paso en la dirección más agresiva (siempre que no se encuentre ya en el perfil más agresivo, el cual, en la presente forma de realización, 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 más agresivo). Al completarse la etapa S85, el método prosigue hacia la etapa S90 en la cual los contadores de retardos, RETARDO BUENO y RETARDO DEFICIENTE, correspondientes a la línea se reinicializan, y a continuación el proceso (para la línea respectiva) finaliza. Tal como se ha mencionado anteriormente, una vez que el proceso finaliza para la línea actual que está siendo procesada, la función de DLM continúa con el análisis de cualquier otra línea que requiera análisis 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 cuándo se ha concedido un perfil nuevo en la dirección más agresiva, y el duplicador de retardos se puede incrementar únicamente si se ha dado un perfil nuevo en la dirección menos agresiva (inmediatamente) después de que se haya dado un perfil nuevo en la dirección más agresiva. Esto ayuda a incrementar el retardo antes del cual se puede efectuar una transición más agresiva únicamente si hay muestras de oscilación entre perfiles diferentes. Esta funcionalidad se puede implementar incluyendo una etapa adicional después de la etapa S90 (es decir, tras completarse esta última) para fijar la bandera de PERFIL AGRESIVO a verdadera (desde una fijación 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 continuación reinicializando la bandera de PERFIL AGRESIVO de vuelta a falsa después de incrementar el duplicador de retardos.
En formas de realización alternativas, se podrían usar métodos diferentes para diferenciar re-acondicionamientos provocados por el usuario y re-acondicionamientos forzados. Por ejemplo, se podría instalar algún software especial en el extremo del módem de usuario (es decir, ya sea para ejecutarse en el PC del usuario conectado al módem de DSL del usuario final, o para ejecutarse en el propio módem del DSL) con el fin de detectar cada vez que el módem es desconectado aparentemente por el usuario (por ejemplo, detectando que la alimentación para el módem se ha perdido – por ejemplo, debido a que el usuario ha apagado el módem o ha desconectado el cable de alimentación, etcétera; o detectando que un cable telefónico se ha desenchufado, etcétera). Por otra parte, las diversas normas de ADSL incluso especifican, como requisito opcional, que las ATU’s (es decir, los módems de ADSL) deberían monitorizar las pérdidas de alimentación y comunicarse si así se solicitase. Desafortunadamente, esta característica no ha sido implementada todavía de manera amplia por los fabricantes de módems de ADSL. Por este motivo, se prefiere el planteamiento descrito en la anterior forma de realización preferida para buscar transiciones entre periodos en los cuales no se detecta la presencia de ninguna conexión y periodos en los cuales se detecta la presencia de una conexión, ya que esto se puede llevar a cabo con módems existentes comunes sin ninguna modificación sobre ellos o sobre los PC’s de los usuarios (o sobre el software que se ejecuta en los mismos).

Claims (10)

  1. 5
    15
    25
    35
    45
    55
    65
    REIVINDICACIONES
    1. Método de funcionamiento de una red de acceso, que incluye una pluralidad de conexiones de datos (19) entre unos dispositivos de usuario final (14) y un dispositivo transceptor de agregación (20), en el que las conexiones se agregan para la conexión hacia delante a través de la red de acceso, comprendiendo el método:
    almacenar una pluralidad de perfiles, cada uno de los cuales especifica un conjunto de valores para una pluralidad de parámetros asociados a las conexiones de datos (19);
    para cada conexión de datos (19), monitorizar la estabilidad de la conexión (19);
    seleccionar uno de entre dichos perfiles almacenados para su aplicación a la conexión (19); y
    aplicar el perfil seleccionado a la conexión de datos (19); caracterizado por que comprende
    asociar un nivel de estabilidad (115), que especifica un nivel deseado de estabilidad, a cada conexión de datos (19), de entre una pluralidad de niveles de estabilidad diferentes (115) de manera que los niveles de estabilidad diferentes (115) controlen las circunstancias bajo las cuales se efectúa una transición de una conexión (19) entre perfiles diferentes; y por que la etapa de selección se lleva a cabo en función tanto de los resultados de la monitorización de la conexión (19), como del nivel de estabilidad (115) asociado a la conexión de datos (19).
  2. 2.
    Método según la reivindicación 1, en el que los resultados de monitorizar la estabilidad de la conexión (19) comprenden un valor para cada uno de entre uno o más parámetros de los resultados de monitorización, y en el que la etapa de seleccionar un perfil almacenado comprende comparar el valor del parámetro del resultado de monitorización o de cada uno de entre los parámetros de los resultados de monitorización con un umbral correspondiente, y efectuar una transición de la conexión de datos (19) hacia uno nuevo de entre los perfiles almacenados en caso de que la comparación indique que el umbral, o uno de los umbrales, ha sido superado, en el que los diferentes umbrales correspondientes se asocian a niveles de estabilidad diferentes (115).
  3. 3.
    Método según la reivindicación 2, en el que el parámetro del resultado de monitorización, o uno de entre los parámetros de los resultados de monitorización, es o depende del número de resincronizaciones forzadas que se producen en la conexión de datos (19) en un periodo de tiempo predeterminado.
  4. 4.
    Método según cualquiera de las reivindicaciones anteriores, en el que las conexiones de datos (19) son unas líneas de abonado digitales (19) que incluyen unas unidades transceptoras remotas (16) y centrales (20) conectadas a través de un par de cobre (19) y que funcionan de acuerdo con una o más de las diversas normas de xDSL acordadas por la Unión Internacional de Telecomunicaciones.
  5. 5.
    Método según la reivindicación 4, en el que el dispositivo transceptor de agregación (20) es un Multiplexor de Acceso de Línea Digital de Abonado (20) que comprende una pluralidad de unidades transceptoras centrales que funcionan de acuerdo con una norma xDSL.
  6. 6.
    Método según cualquiera de las reivindicaciones anteriores, en el que el perfil asociado a una conexión de datos dada (19) y el nivel de estabilidad (115) asociado a esa conexión (19) ambos se almacenan en un dispositivo (100) que forma parte de la red de acceso.
  7. 7.
    Método según cualquiera de las reivindicaciones 1 a 5, en el que el nivel de estabilidad asociado a una conexión de datos dada se almacena en un dispositivo de usuario final (14), y en el que se envían mensajes al dispositivo transceptor de agregación (20), cuyo valor depende del nivel de estabilidad almacenado (115).
  8. 8.
    Dispositivo de gestión (100) para su uso en una red de acceso, que incluye una pluralidad de conexiones de datos
    (19) entre unos dispositivos de usuario final (14) y un dispositivo transceptor de agregación (20), en el que las conexiones se agregan para su conexión hacia delante a través de la red de acceso, almacenando la red de acceso, en asociación con cada conexión de datos (19), un perfil que especifica un conjunto de valores para una pluralidad de parámetros asociados a la conexión de datos respectiva (19), comprendiendo el dispositivo:
    unos medios para recibir unos datos de monitorización que especifican la estabilidad de cada conexión de datos durante un periodo de tiempo predeterminado;
    unos medios para determinar si se debería efectuar una transición de cada conexión de datos a un perfil nuevo en función de los datos de monitorización asociados a la conexión de datos;
    unos medios para seleccionar un nuevo perfil que se debe aplicar a cada conexión en caso de que los medios de determinación determinen que se debería efectuar una transición de la conexión de datos correspondiente a un perfil nuevo; y
    15
    unos medios para solicitar a un sistema de soporte de operaciones de la red de acceso que aplique el perfil seleccionado a la conexión de datos; estando caracterizado el dispositivo por que
    comprende además unos medios (112) para almacenar, en asociación con cada conexión de datos (19), un nivel
    5 de estabilidad (115), que especifica un nivel deseado de estabilidad para la conexión de datos (19), de entre una pluralidad de niveles de estabilidad diferentes (115) de manera que los niveles de estabilidad diferentes (115) controlan las circunstancias bajo las cuales se efectúa una transición de una conexión (19) entre perfiles diferentes; y
    10 los medios de determinación se pueden hacer funcionar para determinar si se debería efectuar una transición de cada conexión de datos a un perfil nuevo en función tanto de los datos de monitorización recibidos asociados a la conexión de datos, como del nivel de estabilidad (115) asociado a la conexión de datos (19).
  9. 9. Red de acceso, que incluye un dispositivo de gestión (100) según la reivindicación 8. 15
  10. 10. Dispositivo de usuario final (14) para su uso con una red de acceso, que incluye un dispositivo transceptor de agregación (20), en el que una conexión de datos (19) del dispositivo de usuario final (14) se agrega con otras conexiones de datos similares de otros dispositivos de usuario final similares para su conexión hacia delante a través de la red de acceso, almacenando la red de acceso, en asociación con cada conexión de datos, un perfil que
    20 especifica un conjunto de valores para una pluralidad de parámetros asociados a la conexión de datos respectiva, comprendiendo el dispositivo (14):
    unos medios de almacenamiento para almacenar un nivel de estabilidad que especifica un nivel deseado de estabilidad para la conexión de datos; y
    25 unos medios para provocar que los mensajes que especifican los datos de monitorización indicativos de la estabilidad de la conexión de datos durante un periodo predeterminado de tiempo sean enviados al dispositivo de agregación (20), dependiendo los mensajes del nivel de estabilidad almacenado.
    30 11. Medios portadores tangibles que son portadores de un programa de ordenador o un conjunto de programas de ordenador para conseguir llevar a cabo el método según cualquiera de las reivindicaciones 1 a 7 durante la ejecución del programa o programas.
    16
ES08864638.5T 2007-12-21 2008-12-19 Comunicación de datos Active ES2549125T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP07255002A EP2073439A1 (en) 2007-12-21 2007-12-21 Data communication
EP07255002 2007-12-21
PCT/GB2008/004211 WO2009081129A1 (en) 2007-12-21 2008-12-19 Data communication

Publications (1)

Publication Number Publication Date
ES2549125T3 true ES2549125T3 (es) 2015-10-23

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 After (1)

Application Number Title Priority Date Filing Date
ES15161548.1T Active ES2636463T3 (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
ES2636463T3 (es) 2017-10-05
EP2238713A1 (en) 2010-10-13
EP2940932A1 (en) 2015-11-04
US8918498B2 (en) 2014-12-23
CN101919206A (zh) 2010-12-15

Similar Documents

Publication Publication Date Title
ES2549125T3 (es) Comunicación de datos
US8537701B2 (en) Monitoring data communications in an access network
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