ES2866415T3 - Sistema de gestión y métodos de gestión de la transmisión dúplex de división de tiempo (TDD) sobre cobre - Google Patents

Sistema de gestión y métodos de gestión de la transmisión dúplex de división de tiempo (TDD) sobre cobre Download PDF

Info

Publication number
ES2866415T3
ES2866415T3 ES12784144T ES12784144T ES2866415T3 ES 2866415 T3 ES2866415 T3 ES 2866415T3 ES 12784144 T ES12784144 T ES 12784144T ES 12784144 T ES12784144 T ES 12784144T ES 2866415 T3 ES2866415 T3 ES 2866415T3
Authority
ES
Spain
Prior art keywords
network
user
towards
time slots
time
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
ES12784144T
Other languages
English (en)
Inventor
Kenneth Kerpez
George Ginis
Marc Goldburg
Ardavan Maleki Tehrani
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.)
Assia Spe LLC
Original Assignee
Assia Spe LLC
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=47148940&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2866415(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Assia Spe LLC filed Critical Assia Spe LLC
Application granted granted Critical
Publication of ES2866415T3 publication Critical patent/ES2866415T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/10—Arrangements for reducing cross-talk between channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H04M11/06—Simultaneous speech and data transmission, e.g. telegraphic transmission over the same conductors
    • H04M11/062—Simultaneous speech and data transmission, e.g. telegraphic transmission over the same conductors using different frequency bands for speech and other data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B3/00—Line transmission systems
    • H04B3/02—Details
    • H04B3/32—Reducing cross-talk, e.g. by compensating
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/14—Two-way operation using the same type of signal, i.e. duplex
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B3/00—Line transmission systems
    • H04B3/02—Details
    • H04B3/46—Monitoring; Testing
    • H04B3/487—Testing crosstalk effects

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Un método en un sistema de comunicaciones de datos para gestionar múltiples canales físicos de división de tiempo cableados que están sujetos a diafonía, comprendiendo el método obtener (1104) entrada en objetivos de tráfico para un primer canal físico y un segundo canal físico; programar (1106), basado al menos en la entrada, franjas temporales hacia la red para la transmisión hacia la red en el primer canal físico; y programar (1108), basado en al menos en la entrada, franjas temporales hacia el usuario para transmisión hacia el usuario en el segundo canal físico, en la que una porción de una franja temporal hacia el usuario es invariante y una porción de una franja temporal hacia el usuario varía en tiempo real, Dicha transmisión en las franjas temporales hacia la red no es sustancialmente simultánea con transmisión en las franjas temporales hacia el usuario.

Description

DESCRIPCIÓN
Sistema de gestión y métodos de gestión de la transmisión dúplex de división de tiempo (TDD) sobre cobre
Campo
La presente descripción se refiere al campo de la transmisión de datos en canales sujetos a diafonía y, en particular, a la programación de asignaciones de franjas temporales para dichos canales.
Antecedentes
Los sistemas TDD (Duplexación por División de Tiempo) transmiten datos en dirección del usuario (red a abonado) y datos en dirección de la red (abonado a red) en distintas franjas temporales del mismo canal físico. Además, a menudo hay un pequeño tiempo de protección entre distintas franjas temporales para garantizar que los datos no se superpongan. Un nuevo sistema TDD se llama 'G.fast', que actualmente está en proceso de estandarización por parte de la UIT-T (Unión Internacional de Telecomunicaciones - Sector de Estandarización de Telecomunicaciones). G.fast es para transmitir a través de bucles telefónicos de cobre y cableado de instalaciones relativamente cortos (<250 m).
La figura 1 es un diagrama de franjas en un eje de tiempo horizontal para un sistema TDD clásico, que transmite alternativamente hacia el usuario desde la red hacia el usuario y hacia la red desde el abonado hacia la red en diferentes franjas temporales de TDD Ascendentes y Descendentes. Hay una franja 12 hacia el usuario y una franja 14 hacia la red. A esto le sigue otra franja 16 hacia el usuario y luego una franja 18 hacia la red. El ciclo se repite a lo largo del eje de tiempo horizontal. La “Relación de asimetría” es la relación entre el tamaño de la franja Abajo en comparación con el tamaño de la franja Arriba. Por lo general, también hay un pequeño tiempo de guardia (no se muestra) entre cada franja temporal. Cada repetición de las dos franjas puede denominarse trama. Alternativamente, una trama puede tener múltiples repeticiones de las dos franjas.
Para reducir el consumo de energía y la interferencia en las líneas cercanas, en la Figura 2 se muestra un sistema TDD de ahorro de energía. La Figura 2 es un diagrama de franjas en un eje horizontal para el sistema TDD de ahorro de energía. Los sistemas de comunicación de datos de banda ancha a menudo están inactivos o muy infrautilizados, y la práctica actual es generalmente enviar códigos inactivos a plena potencia cuando no hay tráfico de datos. Una alternativa de ahorro de energía es suprimir la transmisión cuando no hay tráfico de datos del usuario. Como se muestra en la Figura 2, hay dos tramas 21, 22, trama1 TDD, trama2 TDD, cada una con una franja hacia el usuario, 23, 27, seguida de una franja hacia la red, 25, 29. Además, una porción de la franja hacia el usuario, en este caso la porción posterior, es una porción inactiva, D_off 24, 28, durante la cual se suprime la transmisión. Durante la porción inactiva, no se envían datos ni bits inactivos. De manera similar, la franja hacia la red, Arriba, tiene una porción de inactiva U_off 26, 30 al final de cada franja, durante la cual no se envían datos ni bits inactivos. No enviar energía durante los tiempos de inactividad “D_off” y “U_off” puede proporcionar ahorros de energía significativos. “D_off 'y” U_off' también se pueden combinar en una sola porción de inactividad.
En muchos sistemas TDD, existen múltiples canales físicos. Si estos canales están muy próximos en ubicación y se superponen en frecuencia, pueden interferir entre sí. La figura 3 es un diagrama de un sistema TDD con dos canales 31, 32. En este ejemplo, cada canal usa un par trenzado de cables de cobre y ambos canales están en el mismo cable o sujetador de cables. Como se ilustra en la Figura 3, los sistemas que transmiten en cables de cobre multipar pueden generar diafonía entre sí, se genera Near-End Crosstalk (NEXT) 33 y Far-End Crosstalk (FEXT) 34 por cada canal y dirigidos al menos en parte hacia el canal cercano.
Cada canal está conectado entre una Transmission Unit-Office (TU-O) del extremo de red 35, 36 y un transceptor 37, 38 de la Transmission Unit-Remote (TU-R) del extremo del abonado a su propia TU-R, una sola TU-O se puede conectar a una sola TU-R utilizando ambos canales. Esto permite enviar más datos a una TU-R. Una sola TU-O también puede conectarse a varias TU-R, lo que a veces se denomina “vinculación”.
NEXT puede ser muy potente y debilitar las transmisiones de alta velocidad. ADSL (Asymmetric Digital Subscriber Line) y VDSL (Very high bit rate Digital Subscriber Line) utilizan Multiplexación por División de Frecuencia (FDM) para evitar el self-NEXT. Self-NEXT 33 es la diafonía que se crea en los canales vecinos, como se muestra en la Figura 3.
El documento CA 2254807 discute técnicas mejoradas para sincronizar transmisiones y recepciones de un sistema de transmisión de datos.
El documento US 6480475 discute métodos para configurar velocidads de datos de usuario y gestionar retardo en sistemas de transmisión de datos.
Resumen
Varios aspectos y realizaciones de la invención se establecen en las reivindicaciones.
En un ejemplo, se describe un método para gestionar múltiples canales físicos en un sistema de comunicaciones de datos que está sujeto a diafonía. El método incluye la programación de asignaciones de franjas temporales para los canales físicos de modo que las transmisiones hacia la red no se produzcan al mismo tiempo que las transmisiones hacia el usuario. En otro ejemplo, el método es implementado por una máquina que opera en un medio legible por máquina que tiene instrucciones almacenadas. En otro ejemplo, un sistema de gestión de franjas temporales gestiona múltiples canales físicos en un sistema de comunicaciones de datos que están sujetos a diafonía. El sistema tiene un proceso para determinar las asignaciones de franjas temporales para los canales físicos de modo que las transmisiones hacia la red no se produzcan al mismo tiempo que las transmisiones hacia el usuario y una interfaz de comunicaciones para realizar asignaciones a los transmisores de los canales físicos.
Breve descripción de las figuras de los dibujos
Las realizaciones se ilustran a modo de ejemplo, y no a modo de limitación, y se entenderán más completamente con referencia a la siguiente descripción detallada cuando se considere en relación con las figuras en las que:
La figura 1 es un diagrama de franjas en un eje de tiempo horizontal para un sistema TDD clásico;
La Figura 2 es un diagrama de franjas en un eje horizontal para un sistema TDD de ahorro de energía;
La Figura 3 es un diagrama de dos canales físicos relacionados conectados a los nodos finales en un sistema TDD; La figura 4 es un diagrama de asignaciones de franjas para dos canales físicos relacionados de acuerdo con una realización de la invención;
La figura 5 es un diagrama de asignaciones de franjas alternativas para dos canales físicos relacionados de acuerdo con una realización de la invención;
La figura 6 es un diagrama de asignaciones de franjas alternativas adicionales para dos canales físicos relacionados de acuerdo con una realización de la invención;
La figura 7 es un diagrama de un par trenzado que tiene al menos dos canales físicos relacionados conectados entre una oficina central y un nodo final;
La figura 8 es un diagrama de flujo de proceso de un ejemplo de cálculo de franjas temporales TDD y tiempos de inactividad de acuerdo con una realización de la invención;
La figura 9 es un diagrama de flujo del proceso para calcular los tiempos de inicio y finalización de las franjas temporales de acuerdo con una realización de la invención;
La figura 10 es un diagrama de múltiples grupos TDD que tienen acoplamiento de diafonía entre algunas de sus líneas, incluida la gestión TDD autónoma de acuerdo con una realización de la invención;
La figura 11 es un diagrama de flujo de proceso de otro ejemplo de cálculo de franjas temporales TDD de acuerdo con una realización de la invención; y
La figura 12 es un diagrama de bloques de un sistema de gestión TDD de acuerdo con una realización de la invención. Descripción detallada
Las formas de realización de la invención pueden proporcionar un sistema de gestión para sistemas que transmiten por cables utilizando Dúplex por división de tiempo (TDD). El sistema de gestión recibe datos de entrada sobre niveles de servicio, tráfico, energía y otros requisitos. Luego determina una asignación de franjas temporales TDD, tiempos de inactividad y asimetría; para un rendimiento óptimo, retardos mínimos en el tráfico y un uso mínimo de energía. Las tramas TDD son flexibles y no necesitan seguir un patrón fijo.
Una forma de evitar el self-NEXT es sincronizar las transmisiones en las dos líneas para que una línea no transmita hacia el usuario mientras que otra línea transmita hacia la red. Esto es particularmente importante con los sistemas TDD que tienen canales que utilizan el mismo enlazador de cables de varios pares.
La figura 4 es un diagrama que muestra tramas TDD, traman trama2, en dos canales diferentes, Líneas Línea2, que están lo suficientemente cerca como para causar NEXT 41, 42 en la otra línea. Las tramas se muestran alineadas a lo largo de un eje de tiempo horizontal. Cada trama de cada canal tiene una franja hacia el usuario, 43-1, 43-2, 44-1, 44-2, y una franja hacia la red, 45-1,46-2, 45-2, 46-2. Aunque las tramas TDD están alineadas, en este caso las franjas no lo están. Línea1, la línea superior, está transmitiendo predominantemente en la dirección hacia la red, mientras que la Línea2 transmite predominantemente en la dirección hacia el usuario. La desalineación hacia el usuario y hacia la red provoca NEXT 41, 42 en la línea cercana. Como se muestra, la franja 45-1 hacia la red de la trama1 Linea1 comienza antes de que se complete la franja 43-2 hacia el usuario de la trama2 de la Línea2. Durante esta superposición, NEXT 41 es mucho más alto. Después de que termina la franja 43-2 hacia el usuario de la trama2 de la Línea2 y comienza la franja 45-2 hacia la red, la NEXT 41 se reduce considerablemente. Se produce una superposición similar en el trama2.
Una forma de evitar NEXT es alinear todas las tramas TDD, las franjas temporales hacia el usuario y hacia la red, y los tiempos de inactividad, como se muestra, por ejemplo, en la Figura 5. Como en la Figura 4, la estructura de la traman trama2 para dos canales cercanos Línea1, Línea2 se muestran alineados en un eje de tiempo horizontal. Tanto la línea superior, Línea1 como la línea inferior, Línea2, tienen franjas hacia el usuario 53-1, 54-1, 53-2, 54-2 y hacia la red 55-1, 56-1, 55-2, 56-2 que están alineados con respecto al tiempo. Como resultado, los dos canales transportarán datos en dirección del usuario al mismo tiempo y datos en dirección de la red al mismo tiempo. Dado que no se produce ninguna transmisión en la dirección del usuario durante una transmisión hacia la red, NEXt se minimiza.
Además, las dos tramas también tienen partes inactivadas, D_off 57-1,58-1,57-2, 58-2, en cada franja hacia el usuario de cada trama y U_off 51-1, 52-1, 51-2, 52-2 en cada franja hacia la red de cada trama. Parte de cada franja hacia la red y hacia el usuario se muestra apagada para ahorrar energía. Las porciones apagadas también están alineadas.
Una forma más flexible de evitar NEXT, en lugar de imponer una alineación perfecta de cada franja en cada trama como en la Figura 5, es hacer cumplir una alineación suficiente para evitar transmitir hacia la red y hacia el usuario al mismo tiempo en cualquier línea. Esto tiene la ventaja de que una línea puede transmitir más datos que otras líneas si tiene una gran demanda, mientras que las otras líneas pueden ser silenciosas y ahorrar energía. Además, los tiempos de trama se pueden variar. Sin embargo, esto tiene la desventaja de que requiere un alto nivel de control y coordinación. La figura 6 muestra un ejemplo de esto.
La figura 6 muestra dos canales, uno superior, Línea1, y uno inferior, Línea2, alineados en un eje de tiempo horizontal. Las porciones hacia el usuario 63-1, 64-1, 63-2, 64-2 y hacia la red 65-1, 66-1, 65-2, 66-2 de estos dos canales están alineadas como en la Figura 5. Sin embargo, las porciones de apagado, las porciones de salida hacia el usuario D_off 67-1, 68-1, 67-2, 68-2 y U_off, las porciones de salida hacia la red 61-1, 66-1, 61-2, 66-2 no están alineadas. Para eliminar NEXT, no es necesario alinear las partes inactivadas. Cuando un canal está inactivado, no genera ninguna interferencia. No es necesario alinear cada uno de estos períodos de inactividad para todas las líneas en todos los grupos TDD de un enlazador de múltiples canales. Las realizaciones de la invención ayudan a controlar los periodos de inactividad y determinar cómo adaptar los periodos de inactividad para cada canal para evitar NEXT y minimizar el uso de energía.
Un método adicional para mitigar NEXT es emplear la cancelación activa de NEXT en el extremo de la red de las líneas, donde se encuentran las TU-O. Esto es generalmente factible entre TU-Os que están en el mismo chasis de equipo, o al menos en la misma ubicación. En tal caso, las señales de datos transmitidas, las señales hacia la red recibidas más NEXT y las señales de error asociadas están disponibles para un sistema de cancelación o filtro, que resta estimaciones de NEXT de las señales recibidas en tiempo real. El cancelador NEXT puede tener una estructura de forzamiento cero, una estructura de error cuadrático medio mínimo (MMSE), una estructura de ecualizador de decisión-retroalimentación (DFE) o cualquier otra estructura de filtro de cancelación. Los coeficientes de cancelación pueden calcularse al inicio y pueden adaptarse usando señales de error mientras las líneas están activas.
La cancelación NEXT elimina la mayor parte del NEXT desde las señales hacia el usuario en las señales hacia la red, lo que permite cierta superposición entre las franjas temporales hacia el usuario y hacia la red. NEXT de señales hacia la red a señales hacia el usuario ocurre principalmente en los extremos de las líneas de abonado donde las señales hacia la red son más fuertes. La amplitud de este NEXT puede ser lo suficientemente baja como para ignorarla debido a la atenuación que se produce en los cables internos y de derivación. La transmisión simultánea hacia la red y hacia el usuario en las mismas frecuencias se conoce como operación dúplex completo y, en general, también requiere híbridos de línea y canceladores de eco. La compatibilidad con VDSL2 puede habilitarse utilizando la cancelación NEXT en el extremo TU-O de las líneas y no permitiendo la transmisión hacia la red en las bandas de frecuencia hacia el usuario VDSL2 a menos que el NEXt esté abajo en el extremo de las líneas del abonado. Se pueden utilizar diferentes cargas de bits cuando se transmite hacia la red y hacia el usuario simultáneamente, y cuando se transmite en una sola dirección.
Con la cancelación NEXT, la gestión del sistema TDD procede como se describe en otra parte aquí, excepto que se puede permitir cierta superposición entre las franjas temporales hacia el usuario y hacia la red en algunos casos o en algunas franjas temporales. La combinación de asignaciones de franjas temporales y bandas de frecuencias se puede ajustar dinámicamente para cada entorno.
Varias unidades de transmisión de extremo de red (TU-O) se encuentran a menudo en un solo nodo de acceso. Un ejemplo de un nodo de acceso único es un Multiplexor de Acceso de Línea de Abonado Digital (DSLAM). Con referencia a la Figura 7, una oficina central (CO) o central 71 está acoplada a través de un alimentador 72 a una o más cajas transversales o puntos 73 de empalme, aunque solo se muestra uno. La caja transversal está acoplada a través de una línea 74 de distribución a una o más interfaces 75 de cable de derivación, aunque solo se muestra una. La interfaz de cable derivación está acoplada a través de una o más derivaciones o cables 76 de derivaciones a una o más TU-R 77, aunque solo se muestra una. Dependiendo de la implementación del sistema, la caja 73 transversal puede ser reemplazada con o en la forma de, por ejemplo, una interfaz de distribución de alimentador (FDI), una interfaz de área de servicio (SAI), una interfaz de cable de unión (JWI) o una trama de distribución de sub bucle (SDF). La interfaz 75 de cable de derivación puede reemplazarse con o en forma de un terminal de distribución o un punto de despliegue (dP).
El nodo de acceso o DSLAM (no mostrado) se puede ubicar en el terminal de distribución o se puede ubicar en algún otro lugar de la planta de distribución, y generalmente se alimenta con fibra óptica de la Oficina Central (CO) o central. En dirección al usuario del nodo de acceso, hacia las TU-R, la diafonía puede estar solo entre líneas de un solo nodo de acceso, o puede haber diafonía entre líneas de múltiples nodos de acceso. Un conjunto de líneas que utilizan TDD que se originan todas en el mismo nodo de acceso se denominará en el presente documento un grupo TDD.
La invención puede incorporarse mediante un sistema de gestión TDD que coordina los tiempos de los intervalos TDD y los tiempos de inactividad de los diferentes canales para maximizar la transmisión del tráfico de datos del usuario mientras se minimiza la potencia. Se pueden seleccionar tiempos de encendido y apagado para garantizar que no haya posibilidad de crear NEXT entre líneas en un grupo TDD, o entre líneas en diferentes grupos TDD que tienen acoplamiento de diafonía entre sí. Los tiempos de encendido y apagado también se pueden elegir para maximizar el rendimiento del tráfico para satisfacer las demandas de los usuarios y también para minimizar el consumo de energía al estar apagado cuando sea posible.
El sistema de gestión TDD recibe información sobre los niveles de tráfico, los tipos de tráfico y los patrones de tráfico que deben proporcionarse en las líneas bajo su control. Esta entrada puede incluir uno o más de los siguientes:
a) datos estáticos (invariantes en el tiempo) sobre los niveles de suscripción del servicio y sus requisitos de tráfico, por ejemplo, un “descriptor de tráfico;
b) información de la capa de servicio de un administrador de políticas que proporciona estimaciones de alto nivel de los requisitos de velocidad de datos en función de las solicitudes de servicio;
c) datos sobre el comportamiento de diferentes tipos de tráfico, diferentes usuarios, por ejemplo, variaciones de velocidad de bits, comportamiento del tráfico o ráfagas;
d) datos de series de tiempo de la monitorización del tráfico a largo plazo que se analizan para determinar las demandas del tráfico en función de la hora del día o de la semana;
e) retroalimentación instantánea basada en las demandas de tráfico actuales o longitudes de cola (solicitudes de tráfico o longitudes de cola que pueden ser enviadas desde el extremo del cliente hasta el extremo de la red para ingresar al sistema de gestión TDD);
f) patrones de asimetría de tráfico hacia la red y hacia el usuario; y
g) solicitudes o informes de tráfico.
Además, el tráfico se puede clasificar de acuerdo con el nivel de prioridad, el tipo de servicio, la QoS (Calidad de servicio), el etiquetado, el tipo de flujo, el tipo de protocolo, etc., y esta información de clasificación se puede introducir en los algoritmos de programación TDD.
El sistema de gestión TDD utiliza esta entrada para calcular los tiempos de franja TDD y los tiempos de inactividad.
Las franjas temporales están dispuestas de tal manera que se evite o se reduzca NEXT cuando sea posible, por ejemplo, como se muestra en la Figura 6. Idealmente, dos líneas que tengan un acoplamiento de diafonía significativo entre sí no pueden transmitir hacia la red y hacia el usuario al mismo tiempo. Las franjas temporales y los tiempos de inactividad también se pueden calcular para satisfacer el tráfico solicitado por los abonados y pueden minimizar aún más el uso de energía maximizando los tiempos de inactividad.
La figura 8 es un diagrama de flujo de proceso de un ejemplo de cálculo de franjas temporales TDD y tiempos de inactividad como se describió anteriormente. En 800, los requisitos de ancho de banda o las solicitudes de los usuarios se reciben, recopilan, calculan o miden. La información puede basarse en la entrada recibida por el sistema de gestión TDD como se describió anteriormente. Esta información puede incluir cualquier número de factores diferentes, incluido el tipo de tráfico (por ejemplo, fijo, variable) y la cantidad de ancho de banda solicitado (por ejemplo, en bytes o microsegundos). Los requisitos de ancho de banda de algunos usuarios pueden fijarse con el tiempo, como para la transmisión de video, mientras que el ancho de banda de otros puede variar.
En 810, se calcula una función de agregación (máximo, promedio, etc.) de las solicitudes de ancho de banda del usuario hacia el usuario y hacia la red para diferentes tipos de tráfico. Por ejemplo, la función podría ser el máximo de las solicitudes de ancho de banda fijo hacia el usuario de todos los usuarios. En la siguiente sección se proporcionan más ejemplos.
En 820, los siguientes períodos de franja temporal hacia el usuario, hacia la red y fuera de tiempo se calculan basándose en la función de agregación calculada. Por ejemplo, la siguiente duración de la franja temporal hacia el usuario podría ser igual a la suma de las solicitudes máximas hacia el usuario para todos los tipos de tráfico. En tal caso, por ejemplo, se garantiza que ninguna solicitud de ancho de banda del usuario excedería la duración de la franja temporal asignada para ese tipo de tráfico. A continuación, se proporcionan más ejemplos.
En 830, se asignan períodos de franjas temporales hacia el usuario, hacia la red y fuera de tiempo de cada usuario y luego, si es necesario, se ajustan. Si las condiciones de las operaciones anteriores se satisfacen adecuadamente, entonces cada usuario debería poder recibir su ancho de banda solicitado, dadas las limitaciones o requisitos de su tipo de tráfico. También es posible que, por ejemplo, las asignaciones proporcionen un ancho de banda excesivo para ciertos usuarios. En tales casos, se pueden hacer ajustes para utilizar este exceso de capacidad, por ejemplo, asignando tráfico de velocidad de bits variable a franjas temporales de ancho de banda fijo en exceso, o asignando tiempo de inactividad para ahorrar energía. A continuación, se proporcionan más ejemplos. La asignación de franjas temporales puede ser interna a un transceptor, o puede transmitirse desde el sistema de gestión TDD al transceptor.
A continuación, se proporciona un ejemplo del proceso anterior, para asignar ancho de banda en un solo nodo de acceso con mezclas de asignaciones de ancho de banda fijo sensibles al retardo (por ejemplo, video, voz) y asignaciones de ancho de banda en tiempo real insensibles al retardo (por ejemplo, datos). Este ejemplo asume que las solicitudes de ancho de banda se convirtieron en solicitudes de franjas temporales en microsegundos. Si el usuario i tiene una velocidad de datos de Z Mbps y está solicitando B bits de tráfico, la solicitud es igual a B/Z microsegundos en la siguiente trama.
1) La operación de recibir, recopilar, medir o calcular en 800 se puede realizar como recepción de entrada de datos de solicitud de ancho de banda para cada usuario. Estos datos pueden incluir, por ejemplo, cualquiera de los siguientes:
a) Solicitudes fijas de ancho de banda hacia la red, por ejemplo, Microsegundos UXi dedicados para cada usuario i;
b) Solicitudes de ancho de banda hacia la red en tiempo real, por ejemplo, microsegundos UYi en la siguiente franja temporal para el usuario i;
c) Solicitudes fijas de ancho de banda hacia el usuario, por ejemplo, Microsegundos DXi dedicados para cada usuario i; y
d) Solicitudes de ancho de banda hacia el usuario en tiempo real, por ejemplo, microsegundos DYi en la siguiente franja temporal para el usuario i.
2) El cálculo de la función agregada en 810 se puede realizar en varias etapas. Primero, se calcula el ancho de banda máximo solicitado de cada tipo en la siguiente trama. Estos pueden definirse, por ejemplo, de la siguiente manera:
a) Solicitud de ancho de banda hacia la red fijo máximo, por ejemplo, MaxUX = máximo sobre i (UXi);
b) Solicitud de ancho de banda hacia la red máximo en tiempo real, por ejemplo, MaxUY = máximo sobre i (UYi);
c) Solicitud de ancho de banda fijo hacia el usuario máximo, por ejemplo, MaxDX = máximo sobre i (DXi); y
d) Solicitud de ancho de banda hacia el usuario máximo en tiempo real, por ejemplo, MaxDY = máximo sobre i (DYi)
3) La duración de la siguiente trama puede denominarse TF. Las duraciones de las franjas temporales se pueden determinar en 820 usando diferentes criterios dependiendo del abonado particular y las circunstancias de la arquitectura del sistema. A continuación, se proporcionan algunos ejemplos, donde se supone que las solicitudes de ancho de banda fijo tienen una prioridad estricta sobre las solicitudes de ancho de banda en tiempo real.
4) Si TF >= MaxUX MaxUY MaxDX MaxDY, entonces la siguiente duración de la franja temporal hacia la red es MaxUX MaxUY, la siguiente duración de la franja temporal hacia el usuario es MaxDX MaxDY, y el tiempo de inactividad en la siguiente trama TDD es TF -(MaxUX MaxUY MaxDX MaxDY).
5) De lo contrario, si MaxUX MaxUY MaxDX MaxDY > TF > MaxUX MaxDX, entonces las solicitudes de ancho de banda fijo quedarán completamente satisfechas y las solicitudes de ancho de banda en tiempo real estarán parcialmente satisfechas. Una forma de hacerlo es dividir el ancho de banda en tiempo real proporcional al ancho de banda máximo solicitado en tiempo real para que la siguiente duración de la franja temporal hacia la red sea
MaxUX (TF - MaxUX - MaxDX) * (MaxUY/(MaxUY MaxDY),
la siguiente duración de la franja temporal hacia el usuario es
MaxDX (TF - MaxUX - MaxDX) * (MaxDY/(MaxUY Max DY),
y no hay tiempo de inactivación en la próxima franja horaria.
6) De lo contrario, si TF = MaxUX MaxDX, la siguiente duración de la franja temporal hacia la red es MaxUX y la siguiente duración de la franja temporal hacia el usuario es MaxDX.
7) De lo contrario, si MaxUX MaxDX > TF, entonces las solicitudes de ancho de banda fijo se satisfacen parcialmente y las solicitudes de ancho de banda en tiempo real no se satisfacen en absoluto. Una forma de hacerlo es dividir el ancho de banda fijo proporcional al ancho de banda fijo máximo solicitado de modo que la siguiente duración de la franja temporal hacia la red sea TF*(MaxUX/(MaxUX MaxDX)), la siguiente duración de la franja temporal hacia el usuario es TF*(MaxDX/(MaxUX MaxDX)), y no hay tiempo de inactividad en la siguiente franja temporal.
8) Habiendo calculado las funciones y la duración de las franjas temporales, se realizan las operaciones en 830: asignar y ajustar el periodo de franja temporal hacia el usuario, hacia la red y fuera de tiempo de cada usuario.
Hay muchas variaciones en el proceso de ejemplo descrito anteriormente, dependiendo de la aplicación particular y la arquitectura del sistema, por ejemplo, el ancho de banda puede dividirse proporcionalmente al promedio de solicitudes hacia la red y hacia el usuario en lugar del máximo, o el ancho de banda simplemente puede dividirse por la mitad, o el ancho de banda puede dividirse a lo largo de una ventana deslizante que tiene en cuenta las solicitudes de ancho de banda en múltiples franjas temporales, o el ancho de banda puede asignarse de acuerdo con un criterio de equidad, o el ancho de banda puede asignarse de acuerdo con el nivel de suscripción, etc. Los procesos también pueden ampliarse a más de dos tipos de tráfico diferentes. El proceso puede operar en múltiples tramas TDD a la vez.
En el ejemplo de uso del ancho de banda máximo solicitado como se describió anteriormente, la franja temporal dedicada a uno o más usuarios podría exceder el ancho de banda requerido solicitado por esos usuarios. En algunos casos, el ancho de banda requerido para un usuario podría ser significativamente menor que la franja temporal asignada. Por ejemplo, MaxUX MaxUY podría ser mucho más grande que UXi UYi o MaxDX MaxDY podría ser mucho más grande que DXi DYi para un usuario específico i. En tales casos, se puede utilizar el ajuste indicado en la etapa 7 anterior.
Como ejemplo, el ancho de banda adicional se puede utilizar para ahorrar energía o mejorar la latencia o alguna combinación de ambos. La gestión de TDD, por ejemplo, puede extender el período de inactividad para esos usuarios, para reducir su consumo de energía. Alternativamente, el sistema de gestión TDD puede acomodar el ancho de banda adicional disponible que se utilizará para tráfico variable hacia la red o hacia el usuario para que esos usuarios permitan que el tráfico recién llegado se transmita inmediatamente. Por el contrario, cuando se utiliza el ancho de banda promedio solicitado en el algoritmo anterior, es posible que algunas solicitudes de los usuarios no se satisfagan. Por ejemplo, las solicitudes de ancho de banda fijo podrían satisfacerse parcialmente. En tales casos, las etapas 5-7 del proceso de 8 pasos anterior para calcular una función agregada podrían modificarse, donde en lugar de Max; se utiliza la función Promedio. Alternativamente, se pueden utilizar otras funciones para adaptarse a diferentes implementaciones y diferentes objetivos de gestión del tráfico.
Una vez calculadas las duraciones de las franjas temporales, se calculan los tiempos de inicio y finalización de cada franja temporal en la siguiente trama TDD. Esta puede ser una asignación simple anclada en un momento fijo, como el comienzo o el final de una trama TDD. O puede involucrar una solución más complicada, como una solución iterativa. La figura 9 es un diagrama de flujo de proceso de un ejemplo de cálculo de los tiempos de inicio y finalización de cada franja temporal en una trama TDD siguiente o posterior.
En 900, la siguiente franja temporal hacia el usuario (DS), la siguiente franja temporal hacia la red (US) y las siguientes ubicaciones de tiempo de inactividad se asignan a ubicaciones arbitrarias en la siguiente trama TDD.
En 910, se comprueba si la franja temporal hacia el usuario se superpone con otra franja temporal hacia la red, o viceversa, si la franja temporal hacia la red se superpone con otra franja temporal hacia el usuario. Si no hay superposición, entonces se aceptan las asignaciones en la etapa 900 y no se necesita ninguna acción adicional.
Si hay una superposición, entonces en 920, toda la asignación de franja temporal hacia el usuario o toda la asignación de franja temporal hacia la red se mueve hacia adelante o hacia atrás en el tiempo, en una cantidad predeterminada o en una cantidad aleatoria. La elección de DS o US Se basa en si la franja temporal superpuesto es un intervalo de DS o un intervalo de US de 910.
Después de este ajuste, se repiten las operaciones en 910 y, si no hay más superposiciones, no se requiere ninguna otra acción. Sin embargo, si todavía hay una superposición, ya sea con la franja temporal hacia el usuario o con la franja temporal hacia la red, entonces se repiten las operaciones en 920. Si después de los ajustes no se pueden cumplir las condiciones de no superposición, entonces la duración de la franja temporal de DS o de US se reduce (dependiendo de cuál tuvo el problema de superposición) y se repite la asignación inicial en 900.
A continuación, se proporciona un ejemplo más específico de las operaciones en el diagrama de flujo del proceso de la Figura 9. Como en la Figura 9, este es un ejemplo del proceso anterior para calcular las horas de inicio y finalización de cada franja temporal en una siguiente trama TDD. En el siguiente ejemplo se asume que ya se ha realizado el proceso anterior de la Figura 8, y por tanto la siguiente duración DS de la franja temporal hacia el usuario, la duración de la siguiente franja temporal hacia la red, y la siguiente duración de D_off, U_off de tiempo de inactivación ya se han determinado.
1) Como un ejemplo de las operaciones en 900, asigne la siguiente franja temporal hacia el usuario, la siguiente franja temporal hacia la red y el siguiente (s) tiempo (s) de inactividad a ubicaciones arbitrarias en la siguiente trama TDD. Por ejemplo, la siguiente trama TDD puede comenzar con la franja temporal hacia el usuario, luego hacer que la siguiente franja sea hacia el usuario fuera del tiempo D_off, luego tener la franja temporal hacia la red y luego hacer que la siguiente franja hacia la red sea hacia la red fuera del tiempo U_off. Alternativamente, el tiempo de inactividad puede ser contiguo y al principio, en la mitad o al final de la trama TDD.
2) Si la franja temporal hacia el usuario no se superpone con ninguna otra franja temporal hacia la red de cualquier otro sistema TDD que cruza hacia o desde este sistema TDD, el proceso finaliza hasta la próxima vez que se ajusten los intervalos en función de nuevos parámetros. Esta es la prueba en el 910.
3) De lo contrario, mueva toda la asignación de franja temporal hacia el usuario en x microsegundos hacia adelante o hacia atrás en el tiempo. Esto corresponde a la operación en 920.
4) Repita la etapa 4, variando x, hasta que se logre la condición de no superposición en la etapa 3 en la dirección hacia el usuario, x puede variarse aleatoriamente o puede variar en pasos predeterminados.
5) Si no se puede lograr la condición de la etapa 3, entonces disminuya la duración de la franja temporal hacia el usuario y repita las etapas 1 a 4.
6) Si la franja temporal hacia la red no se superpone con la franja temporal hacia el usuario, ni con ninguna otra franja temporal hacia la red de cualquier otro sistema TDD que se cruza con este sistema TDD, entonces el proceso ha finalizado.
7) De lo contrario, mueva toda la asignación de franja temporal hacia la red en y microsegundos hacia adelante o hacia atrás en el tiempo.
8) Repita la etapa 7, variando y, hasta que se logre la condición de no superposición en la etapa 6 en la dirección hacia la red, y puede variarse aleatoriamente o puede variar en etapas predeterminadas.
9) Si no se puede lograr la condición de la etapa 7, entonces disminuya la duración de la franja temporal hacia la red y repita las etapas 6 a 8.
10) Asignar el tiempo de inactividad. Por ejemplo, el tiempo de inactividad puede ser contiguo y estar al principio, en la mitad o al final de la trama TDD; o puede dividirse en dos tiempos antes o después de las franjas temporales hacia la red y hacia el usuario de modo que encaje en la trama TDD.
11) Este procedimiento puede repetirse para asignar tiempos de inactividad a cada línea, o cada línea puede asignar tiempos de inactividad de forma autónoma.
12) Configure los tiempos para las siguientes franjas, ya sea internamente o comunicándose con equipos externos. Si los transceptores son externos al sistema de gestión, el sistema de gestión notifica a los transceptores de una o más de las asignaciones futuras: comienzo de la franja temporal hacia la red, finalización de la franja temporal hacia la red, duración de la franja temporal hacia la red, comienzo de la franja temporal hacia el usuario, finalización de la franja temporal hacia el usuario, duración de la franja temporal hacia el usuario, comienzo de la franja temporal de inactividad, finalización de las franjas temporales de inactividad, duración de las franjas temporales de inactividad,
El cálculo de los tiempos de franja de TDD y los tiempos de inactividad también se puede realizar de varias otras formas, mediante un cálculo directo que maximiza la proyección de las demandas del usuario en el espacio alcanzable, ajustando iterativamente los límites de franja de trama a trama, a través de heurísticas, mediante la selección de entre un conjunto almacenado de tiempos, un algoritmo generalizado que utiliza varios de estos enfoques, etc. Además, la longitud de la trama puede ser variable, los tiempos de inicio y finalización de la franja temporal no necesitan ser periódicos, y estos no necesitan estar alineados. Las longitudes de las tramas se pueden variar para cumplir con los requisitos de retardo, por ejemplo, una trama corta cuando se utilizan aplicaciones de bajo retardo. El cálculo puede aplicarse simultáneamente a múltiples tramas TDD. Todo esto puede ser determinado por el sistema de gestión TDD.
Se puede hacer que el sistema de gestión TDD sea capaz de convertir solicitudes de tráfico y consumo de energía de alto nivel en programación TDD de bajo nivel. Las solicitudes de alto nivel pueden ser, por ejemplo, un esquema de los requisitos de tráfico y energía, o una indicación general de la compensación entre el retardo del tráfico y el uso de energía. El sistema de gestión TDD también puede coordinar los ahorros de energía que se logran al entrar, salir o hacer la transición entre múltiples estados de líneas eléctricas. Además de los tiempos de inactividad de TDD, estos estados de línea de eléctricas pueden ahorrar energía al transmitir una velocidad de bits más baja con una carga de bits más baja utilizando un espectro de transmisión más bajo.
Parte de cada tiempo de trama puede reservarse a largo plazo para franjas temporales de bajada y subida, con una parte adicional variada dinámicamente a medida que el tráfico va y viene. El sistema de gestión TDD optimiza la asignación de franjas temporales utilizando variaciones a corto y largo plazo.
Las franjas temporales de subida y bajada de TDD y la relación de asimetría se puede variar para minimizar los retardos de tráfico medio y maximizar el rendimiento medio en todas las líneas del grupo de t Dd . La relación de asimetría se puede definir en términos de tiempo para cada intervalo o en términos del número de posiciones de símbolo DMT (Discrete Multi-Tone) utilizadas por un usuario particular hacia la red o hacia el usuario. Alternativamente, se puede maximizar el rendimiento de algún conjunto de servicios premium. Como alternativa adicional, se puede maximizar el rendimiento en el peor de los casos. Como alternativa adicional, se puede aplicar un criterio de equidad más general, como “equidad alfa” para maximizar cualquier combinación ponderada arbitrariamente de diferentes demandas de tráfico de usuarios.
Las TU-R a menudo se sincronizan con la temporización de la TU-O. Esta temporización puede ser asistida enviando regularmente un “símbolo de sincronización” hacia el usuario que las TU-R pueden bloquear para mantener un nivel de sincronización de temporización. El sistema de gestión TDD puede determinar los tiempos para enviar símbolos de sincronización y la duración de los símbolos de sincronización. Cuando hay muy poco tráfico, la línea puede estar apagada durante una franja temporal completo hacia arriba o hacia abajo, o durante una trama TDD completa, o incluso durante varias tramas TDD. Luego, el sistema de gestión TDD puede programar la VTU-O para enviar suficientes símbolos de sincronización, con suficiente duración, para que la TU-R mantenga o recupere la sincronización. Estos símbolos de sincronización pueden enviarse solo en algunas franjas temporales, solo en algunas tramas TDD e incluso utilizando solo algunas subportadoras. Los símbolos de sincronización pueden usar una modulación de bajo nivel para mayor robustez. Esto permite que una TU-R inactiva mantenga la temporización de la trama TDD para que la TU-R pueda transmitir durante una franja temporal hacia la red cuando se activa.
Un transceptor, como un TU-R o TU-O puede permanecer en modo de solo recepción, con el transmisor apagado. Esto permite ahorrar energía al apagar el transmisor. En este modo, el transceptor también puede escuchar recepciones que ocurren regularmente para mantener la sincronización y escuchar el tráfico o las instrucciones para activarse.
Un procedimiento de activación alternativo es que una TU-R escuche el ruido en la línea y determine cuándo hay NEXT al leer el ruido de alta potencia que ocurre regularmente una vez cada trama TDD o en cualquier otro intervalo adecuado. La TU-R transmite señales de arranque cuando estima que este NEXT está activo, que debería ser durante una franja temporal hacia la red.
Puede haber un proceso de dos etapas para la activación de TU-R:
1: La TU-R permanece aproximadamente sincronizada a través de mantenimientos periódicos lentos desde la TU-O;
2: Cuando la TU-R desea comenzar a transmitir después de un período de tiempo de inactividad hacia la red y hacia el usuario (y, por lo tanto, la sincronización es solo aproximada):
a) La TU-R envía una solicitud de sincronización corta en lo que cree que es la mitad del período de trama hacia la red (el envío del mensaje corto en el medio asegura que la transmisión está completamente dentro del período hacia la red);
b) La TU-0 responde con una transmisión que la TU-R puede utilizar para recuperar la sincronización;
c) La transmisión procede con normalidad.
Los sistemas de transmisión se adaptan al entorno de ruido en la línea, y las técnicas descritas pueden garantizar que la adaptación se realice mientras las líneas de diafonía crean diafonía de forma activa y no durante tiempos de silencio.
La tecnología de vectorización, como se ejemplifica en el estándar ITU-T G.993.5, se usa para cancelar al menos algunos FEXT. Para que la vectorización sea efectiva, si se aplica a un grupo TDD, NEXT debe mantenerse bajo. Por lo tanto, evitar NEXT también permite que la vectorización funcione mejor. Las técnicas descritas pueden coordinar la temporización TDD con el motor de vectorización. El sistema de gestión TDD puede reasignar recursos de vectorización en tiempo real cuando cambia la relación de asimetría TDD.
El sistema de gestión TDD también puede programar cuándo enviar unidades de retransmisión. Las unidades de retransmisión pueden enviarse en cualquier momento. En algunas realizaciones, las unidades de retransmisión se envían en momentos que no causan problemas NEXT en una parte de lo que habría sido un tiempo de inactividad, o las unidades de retransmisión se envían con múltiples retransmisiones en otros tiempos de trama.
Las retransmisiones pueden ser incrementales, con la totalidad o parte de los datos originales retransmitidos, o enviando bits de paridad adicionales. Se pueden programar múltiples retransmisiones y un bloque de datos originales se puede retransmitir en uno o más bloques de datos o paridad. La invención también puede programar reconocimientos (ACK) o reconocimientos negativos (NACK) relacionados con la retransmisión.
Evitar NEXT entre líneas en un solo grupo TDD es relativamente sencillo en comparación con evitar NEXT con varias líneas. La coordinación TDD simplemente necesita hacer cumplir esto entre las líneas desde un solo nodo de acceso, que se originan en la misma ubicación y, por lo tanto, son relativamente fáciles de controlar de manera conjunta.
La figura 10 es un diagrama de una implementación de sistema más compleja en la que hay varios grupos TDD que tienen acoplamiento de diafonía entre algunas de sus líneas, por ejemplo, entre los dos grupos TDD en un Cable 3 Compartido en la figura 10. En este caso, el TDD la gestión puede abarcar varios nodos de acceso, ya sea explícitamente con un elemento de gestión centralizado o de forma autónoma mediante la detección de diafonía.
La gestión centralizada de TDD permite coordinar directamente varios grupos de TDD. La gestión de TDD centralizada puede utilizar información de temporización explícita y retroalimentación de los nodos de acceso, EMS u otros elementos de red para luego optimizar de forma centralizada todos los grupos TDD que interactúan.
Como se muestra en la Figura 10, la gestión 111 de TDD centralizada puede acoplarse a través de una red 112 a múltiples nodos 113-1, 113-2 de acceso. Si bien solo se muestran dos, puede haber muchos más. La gestión TDD centralizada recibe datos de tráfico como se describió anteriormente, realiza las asignaciones y luego envía asignaciones de franjas temporales a los nodos de acceso. Los nodos de acceso están acoplados a través de canales de comunicación a uno o más nodos finales o TU-R 116-1, 116-2, 116-3, 116-4. Los canales de comunicación pueden ser en forma de cableado de par 117-1 trenzado, 117-2, 117-3, 117-4, o en cualquier otra forma y puede estar en uno o más enlazadores 115-1, 115-2, 115-3. Los enlazadores pueden tener la forma de un cable conductor múltiple compartido con líneas para cuatro o para cientos de canales.
La figura 10 ilustra que dos canales 117-1, 117-2 que inicialmente están en un enlace o cable común y que pueden generar interferencias entre sí, pueden luego separarse y combinarse con otros canales en otros enlaces. Como se muestra, el segundo par 117-2 trenzado se separa del primer par 117-1 trenzado y luego se combina con un tercer par 117-3 trenzado en un tercer 115-3 aglutinante. Estas dos líneas ahora generan diafonía entre sí. Este tercer par trenzado se originó con un segundo aglutinante 115-2. La segunda y tercera líneas también pueden encaminarse a estaciones finales comunes o diferentes 116-2 116-3. La diafonía generada en cualquier punto entre dos canales cercanos puede propagarse a lo largo de cualquier canal y afectar a otros canales. Como ejemplo, la diafonía generada por la primera línea 117-1 y recibida por la segunda línea 117-2 se puede acoplar a la tercera línea 117-3 en el tercer cable compartido. La tercera línea 117-3 puede acoplar esa misma diafonía de la primera línea 117-1 a una cuarta línea 117-4.
Las conexiones entre líneas en diferentes cables o enlazadores pueden ocurrir en interruptores, empalmes, cajas transversales, tramas de distribución, pedestales u otros tipos de terminales, incluidos terminales de extremo de red, como TU-R, o en puntos de empalme. En estos canales de ubicaciones se pueden separar de sus enlazadores originales y luego recombinarse en diferentes enlazadores o combinarse en un punto de terminación. Los sistemas TDD pueden no asignarse alternativamente a carpetas independientes en absoluto, en cuyo caso la diafonía generalmente surgirá entre ellos, lo que dará como resultado esencialmente la misma configuración que en la Figura 10.
La gestión autónoma de TDD 114-1, 114-2 en cada nodo 113-1, 113-2 de acceso o en cualquier otro punto en el sistema puede coordinar varios grupos de TDD incluso aunque lea datos de un solo grupo de TDD y los controle. La sincronización también se puede realizar midiendo la serie de tiempo de diafonía variable en el tiempo y sincronizándola con sus patrones. Como otra alternativa, la sincronización se realiza midiendo la serie temporal de eventos de error y sincronizándola con sus patrones. Esto se puede hacer leyendo el patrón de ruido o errores que varían en el tiempo en las líneas del grupo TDD. La diafonía de otro sistema TDD “ajeno”, como el de un nodo de acceso diferente, crea un patrón de ruido que ocurre con regularidad, ya que se transmite alternativamente en ambas direcciones, primero en una dirección y luego en la otra. Esta diafonía se puede medir leyendo el ruido en las líneas o leyendo la serie temporal de patrones de error. Estos se pueden analizar en ambos extremos de la línea para identificar el patrón de las franjas temporales de subida y bajada de los grupos alienígenas TDD. Por ejemplo, los errores que ocurren en una dirección una vez cada milisegundo indican que la diafonía se genera una vez cada milisegundo de los grupos TDD alienígenas. El sistema de gestión TDD puede sincronizar sus propias transmisiones con esta diafonía.
Las figuras 3, 7 y 10 muestran diferentes perspectivas del mismo sistema de comunicación. Si bien la asignación de la franja temporal se puede realizar en cualquiera de una variedad de ubicaciones diferentes, en cada caso, las transmisiones se controlan directamente o el controlador envía las asignaciones al transmisor apropiado. Las asignaciones pueden enviarse, por ejemplo, a una unidad transceptora (TU), a una caja transversal, a un interruptor, a un empalme, a un pedestal o a otro tipo de transmisor, ya sea una fuente de señal original o un repetidor en cualquier punto en el canal. De manera similar, el controlador puede proporcionar señales de sincronización que permitan coordinar las señales hacia la red y hacia el usuario. La sincronización también puede basarse en señales de una unidad de vectorización, de un nodo de acceso, una caja transversal o algún otro punto de unión o de un reloj externo o una fuente de sincronización. En un ejemplo, los símbolos de sincronización se envían a las fuentes de transmisiones hacia la red, como TU-R.
La gestión TDD puede dividirse más generalmente entre métodos centralizados y autónomos, utilizando datos de tráfico e información de sincronización TDD de:
a) Uso explícito de datos de gestión y datos de sincronización de DSLAM, EMS, OSS u otros elementos de red;
b) Datos de sincronización global que utilizan datos de satélite de posicionamiento global (GPS) o protocolos de temporización de red;
c) Estimación autónoma utilizando datos de monitorización sobre patrones de diafonía o leyendo recuentos de errores o ruido que varían en el tiempo;
d) Pueden introducirse estimaciones explícitas de los acoplamientos de diafonía entre líneas, por ejemplo, las líneas vectorizadas pueden proporcionar datos como los valores Xlin informados.
El sistema de gestión TDD puede ajustar una o más de las siguientes cantidades u otras cantidades que no se enumeran para una o más líneas:
a) relación de asimetría,
b) horarios hacia la red y hacia el usuario,
c) tiempos de inactivación; y
d) uso de estados inactivos o de baja potencia;
con el objetivo de cumplir con los requisitos y solicitudes de velocidad de bits y, opcionalmente, minimizar la energía. Estos también se pueden configurar indirectamente a través de especificaciones de control de nivel superior o inferior. Estos se pueden controlar cambiándolos lentamente según lo programado o según sea necesario después de cruzar un umbral de tráfico; o pueden variar en tiempo real. La Asignación Dinámica de Ancho de Banda (DBA) o la Asignación Dinámica de Recursos (DRA) también pueden ser todo o parte de este control. El sistema de gestión TDD también puede interactuar con, o contener, una Entidad de Control de Temporización (TCE).
La capacidad del sistema de gestión TDD para detectar y adaptarse a la diafonía TDD puede ayudar a habilitar la compatibilidad espectral de los sistemas TDD con los sistemas FDM (Multiplexación por división de frecuencia) como VDSL2 (Línea de abonado digital de muy alta velocidad de bits, versión 2). Esto se puede hacer mediante la identificación de diafonía automatizada, la coordinación de tiempos TDD y la Gestión dinámica del espectro (DSM) para permitir que el sistema TDD sea compatible con VDSL2. Las asignaciones de bandas de frecuencia pueden además coordinarse para permitir la compatibilidad espectral.
La figura 11 es un diagrama de flujo del proceso de programación de franjas temporales hacia la red y hacia el usuario de acuerdo con otra realización. El flujo de proceso está específicamente diseñado para su uso en la gestión de múltiples canales físicos de división de tiempo que están sujetos a diafonía, sin embargo, la invención no está tan limitada. La programación se describe aquí en el contexto de dos canales físicos que están sujetos a diafonía, sin embargo, puede haber muchos más de dos canales.
En 1104, el sistema de gestión TDD recibe información sobre los objetivos de tráfico para la programación de las franjas temporales. Esta operación es opcional. La entrada generalmente se recibe de un controlador externo, aunque el sistema de gestión TDD puede monitorizar los canales o usar parámetros preestablecidos en lugar de cualquier entrada recibida. En un sistema DSL típico los controladores externos ya generan parámetros de datos del Sistema de Soporte de Operaciones (OSS) y la Base de Datos de Información (MIB). Esta información puede proporcionarse al sistema de gestión TDD para que la utilice en la asignación de franjas temporales. También se pueden utilizar otros tipos de información. La entrada recibida puede ser de una variedad de tipos diferentes y puede incluir niveles de tráfico deseados, datos de suscripción estáticos, información de la capa de servicio de un administrador de políticas, datos de comportamiento para tipos de tráfico y usuarios de los canales físicos, datos de comportamiento de tráfico a largo plazo como función de tiempo, demandas de tráfico actuales, longitudes de cola, solicitudes de tráfico, asimetría hacia la red/hacia el usuario y descriptores de tráfico. La entrada recibida también puede incluir solicitudes de transmisión de elementos de red en el extremo de la red o en el extremo remoto.
En 1106, el sistema de gestión TDD programa franjas temporales hacia la red para la transmisión hacia la red en uno o más canales físicos. En 1108, el sistema de gestión TDD programa las franjas temporales hacia el usuario para la transmisión hacia el usuario en uno o más canales físicos. Estos pueden ser los mismos canales que los canales hacia la red o diferentes canales, dependiendo de la naturaleza del sistema TDD y la asignación de canales. Los canales hacia la red pueden asignarse antes o después o al mismo tiempo que los canales hacia el usuario. En estas asignaciones, la transmisión en las franjas temporales hacia la red no es sustancialmente simultánea con la transmisión en las franjas temporales hacia el usuario. Para realizar estas asignaciones, se pueden utilizar todos o algunos de los diversos tipos de información en la entrada recibida. Estos se pueden combinar de diferentes formas. En un ejemplo, se utilizan criterios de optimización que ponderan diferentes factores.
Hay factores adicionales que también se pueden considerar en la programación, como el uso de energía o una relación de asimetría de destino hacia la red/hacia el usuario del rendimiento de datos. El rendimiento de datos se puede definir o medir como un rendimiento promedio en todas las líneas, una coincidencia de demanda de tráfico, un rendimiento mínimo para cada canal físico, una calidad de experiencia percibida, un retardo promedio o un retardo mínimo.
Como se mencionó anteriormente, la programación puede permitir alguna transmisión simultánea en las franjas temporales hacia la red y hacia el usuario. El NEXT que puede ser causado por la transmisión simultánea puede ignorarse o el sistema TDD también puede usar la cancelación de NEXT activa para cancelar NEXT en el extremo de la red de los canales.
Como parte de la programación, el sistema de gestión TDD normalmente enviará asignaciones de franjas temporales a un elemento de red correspondiente. En 1110, el sistema de gestión TDD también puede sincronizar opcionalmente franjas temporales entre diferentes transmisores. El sistema de gestión TDD puede enviar símbolos de sincronización a la fuente de transmisiones hacia la red o hacia el usuario. También puede medir una serie temporal de diafonía variable en el tiempo y luego sincronizar las franjas temporales con los patrones variables en el tiempo medidos. En lugar de patrones de diafonía, se puede medir una serie temporal de eventos de error y usarla para sincronizar.
En 1112, el sistema de gestión TDD puede ajustar opcionalmente la programación de las franjas temporales hacia la red y hacia el usuario. El ajuste se puede aplicar a la siguiente trama o tramas, o a las asignaciones actuales. El ajuste puede adaptarse a los requisitos de retardo para una fuente de tráfico hacia la red o descendente. Se pueden realizar muchos ajustes diferentes, como mover las franjas temporales hacia la red y hacia el usuario a tiempo para reducir la transmisión simultánea hacia la red y hacia el usuario, moverse solo si las transmisiones hacia la red se superponen en el tiempo con las transmisiones hacia el usuario y reducir la duración de al menos una franja temporal hacia el usuario para reducir la transmisión hacia la red y hacia el usuario.
La figura 12 es un diagrama de bloques de un sistema 1200 de gestión TDD en un ejemplo. El sistema 1200 incluye una memoria 1295 acoplada directamente o mediante un bus a un procesador o procesadores 1296. La memoria puede ser un disco duro, una memoria no volátil, una memoria de estado sólido o una combinación de diferentes tipos de memoria para diferentes propósitos. El procesador también puede incluir su propia memoria interna. La memoria puede, por ejemplo, almacenar instrucciones a ejecutar y el procesador puede ejecutar las instrucciones almacenadas. El procesador también puede implementar o ejecutar la lógica 1260 de implementación que tiene lógica para implementar las metodologías discutidas en este documento. El sistema 1200 incluye uno o más buses 1215 de comunicaciones para conectar los diversos componentes ilustrados y transferir transacciones, instrucciones, solicitudes y datos dentro del sistema entre los componentes y otros dispositivos periféricos. El sistema incluye además una interfaz 1225 de gestión acoplada al bus y a dispositivos de gestión externos, por ejemplo, para recibir solicitudes, devolver respuestas y, de otro modo, interactuar con elementos de red ubicados por separado del sistema. Esta información puede incluir datos del sistema de soporte de operaciones (OSS) y parámetros de la base de datos de información de gestión (MIB). Estos elementos de red pueden incluir nodos de acceso, una oficina central, unidades de vectorización, cajas transversales, TU-R y TU-O.
El sistema incluye además una interfaz 1230 LAN (Red de Área Local) acoplada al bus y externamente para comunicar información a través de una conexión basada en LAN, incluida la recopilación de información de red, la transmisión de información y diagnósticos a otras entidades dentro de la red, y para iniciar instrucciones y comandos a través de la red. El sistema incluye además una interfaz 1235 WAN (Red de Área Amplia) acoplada al bus y a una WAN externa, para comunicar información a través de una conexión basada en WAN para propósitos similares y para llegar a otros dispositivos más remotos.
En algunas realizaciones, la interfaz 1225 de gestión comunica información a través de una conexión fuera de banda separada de las comunicaciones basadas en LAN y/o WAN, donde las comunicaciones “dentro de banda” son comunicaciones que atraviesan los mismos medios de comunicación que los datos de carga útil (por ejemplo, contenido ) que se intercambian entre dispositivos en red y donde las comunicaciones “fuera de banda” son comunicaciones que atraviesan un medio de comunicación aislado, separado del mecanismo para comunicar los datos de carga útil. Una conexión fuera de banda puede servir como una interfaz redundante o de respaldo sobre la cual comunicar datos de control entre un dispositivo 1201 de gestión y otros dispositivos en red o entre el dispositivo de gestión y un proveedor de servicios externo.
El sistema incluye además información 1250 histórica almacenada que puede almacenarse dentro de la memoria 1295 o como un componente separado acoplado a la memoria o al bus. La información histórica puede ser analizada o referenciada cuando se realiza un análisis de tendencias a largo plazo para programar franjas temporales y para informes. De manera similar, los eventos 1255 de gestión pueden almacenarse dentro de la memoria o como un componente separado acoplado al bus o a la memoria. Los eventos de gestión pueden iniciarse en respuesta a la identificación de una condición operativa. Por ejemplo, acciones correctivas, diagnósticos adicionales, sondas de información, solicitudes de cambio de configuración, comandos locales, comandos de ejecución remota y similares pueden especificarse y activarse como un evento 1255 de gestión. De manera similar, informes operativos, informes de configuración, informes de actividad de red y Los informes de diagnóstico se pueden generar y enviar de acuerdo con los eventos 1255 de gestión almacenados.
Un dispositivo 1201 de gestión acoplado al bus incluye un módulo de recogida 1270, un módulo 1275 de análisis, un módulo 1280 de diagnóstico y un módulo 1285 de implementación. El dispositivo 1201 de gestión puede instalarse y configurarse en un sistema 1200 compatible como se muestra en la Figura 12A, o puede suministrarse por separado para operar en conjunto con la lógica 1260 de implementación u otro software.
El módulo 1270 de recopilación recopila información de fuentes disponibles, como información de gestión, información de LAN e información de WAN a través de las interfaces externas. El módulo 1275 de programación analiza la información recuperada por el módulo de recopilación y genera programas de franjas temporales hacia la red y hacia el usuario que incluyen, según corresponda, tiempos de inactividad y tiempos de transmisión activa. El módulo de programación puede realizar además análisis de tendencias a largo plazo basado en información 1250 histórica almacenada o realizar análisis de vecindad basados en datos de agregación obtenidos de múltiples informes separados y distintos, o realizar otro análisis conjunto basado en información recopilada. El módulo 1280 de ajuste ajusta las programaciones para adaptarse mejor a la información recopilada y los parámetros internos, como el uso de energía y los objetivos de relación de asimetría. Los resultados del módulo de ajuste pueden devolverse al módulo de programación, dependiendo de la realización. El módulo 1285 de sincronización sincroniza las franjas temporales programadas a través de las conexiones 1225, 1230, 1235 externas para que todos los nodos de acceso, unidades de transmisión u otros componentes transmitan en los momentos apropiados.
Los módulos del dispositivo 1201 de gestión pueden proporcionarse como componentes separados acoplados al bus 1215 como se muestra o pueden incorporarse en el procesador o la memoria u otro componente. El dispositivo de gestión puede incluir sus propios recursos de procesamiento y memoria que interactúan con el procesador y las interfaces externas. El dispositivo de gestión puede incluir más o menos módulos que los mostrados. El sistema de gestión TDD de la Figura 12 se proporciona sólo como ejemplo y puede modificarse para adaptarse a diferentes implementaciones. También puede incorporarse a otro componente, como un nodo de acceso o una TU-O. En una realización, el sistema de gestión se proporciona como una tarjeta en un bastidor del sistema con una interfaz de plano posterior para comunicarse con elementos de red locales y remotos.
Hay una serie de ventajas y características opcionales y adicionales para las técnicas y sistemas descritos anteriormente. Estos pueden entenderse en las declaraciones a continuación, entre otras, que pueden combinarse de una variedad de formas diferentes.
Se ha descrito anteriormente un sistema para gestionar múltiples líneas TDD, en parte, determinando los límites de las franjas temporales. El sistema proporciona suficiente coordinación para evitar NEXT al garantizar que dos líneas con un acoplamiento de diafonía significativo no transmitan hacia el usuario y hacia la red al mismo tiempo. El sistema además asigna franjas temporales y la relación de asimetría hacia el usuario/hacia la red para maximizar una medida de rendimiento. La medida maximizada de rendimiento es uno o más de: el promedio máximo o promedio mínimo en todas las líneas; elegido para adaptarse mejor a las demandas del tráfico; elegido para proporcionar un nivel de servicio mínimo a todas las líneas; elegido para garantizar la calidad de experiencia percibida por el usuario; elegido para minimizar los retardos medios o máximos; o elegido para cumplir con cualquier criterio de equidad. Se pueden usar otras medidas de rendimiento como alternativas o adiciones, dependiendo de la implementación. La asignación de franjas temporales puede ser interna a un transceptor, o puede transmitirse desde el sistema de gestión TDD a un transceptor. El sistema de gestión TDD puede realizar además la Asignación Dinámica de Ancho de Banda (DBA) o la Asignación Dinámica de Recursos (d Ra ).
El sistema de gestión TDD puede optimizar aún más la programación de las franjas temporales de inactividad para minimizar el uso de energía. El sistema de gestión TDD puede programar además tiempos de inactividad durante poco tráfico que suprimen la transmisión durante toda la franja temporal, tramas TDD o múltiples tramas TDD. Puede ahorrar energía controlando entradas, salidas y transiciones entre estados de baja energía. Los estados de bajo consumo ahorran energía al transmitir una velocidad de bits más baja con una carga de bits más baja utilizando un espectro de transmisión más bajo.
El sistema de gestión TDD puede calcular un conjunto óptimo de tiempos de franja de subida y bajada y tiempos de inactividad de acuerdo con un criterio de optimización, este criterio puede sopesar de manera flexible diferentes compensaciones entre diferentes usuarios, compensaciones entre diferentes servicios y compensaciones entre rendimiento y ahorro de energía.
El sistema de gestión TDD ajusta una o más de las siguientes u otras cantidades para una o más líneas: a) relación de asimetría, b) duraciones de franjas hacia la red y hacia el usuario, c) tiempo de franjas arriba y abajo, y d) tiempos de inactividad. El sistema de gestión TDD controla los límites de las franjas temporales TDD y los tiempos de inactividad. Esta puede ser una asignación fija, una asignación que varía lentamente según la hora del día o una asignación que varía en tiempo real. Uno o más parámetros de control, como cualquier punto de inicio o finalización de una franja temporal, longitud de franja, asimetría, tiempo de franja arriba, el tiempo de franja abajo, un tiempo de inactivación único y el tiempo de inactivación total, se pueden variar mientras que otros parámetros permanecen fijos. El sistema de gestión TDD puede emplear límites de tiempo de franja flexible, con tramas de longitud variable, franjas temporales arriba y franjas temporales abajo.
El sistema de gestión TDD recibe información sobre los niveles de tráfico que deben proporcionarse en las líneas bajo su control. Esta entrada puede incluir uno o más de los siguientes: datos estáticos (invariantes en el tiempo) sobre los niveles de suscripción de servicio y sus requisitos de tráfico; información de la capa de servicio de un administrador de políticas que proporciona estimaciones de alto nivel de los requisitos de velocidad de datos en función de las solicitudes de servicio; datos sobre el comportamiento de diferentes tipos de tráfico, por ejemplo, ráfagas, para diferentes usuarios; datos de series de tiempo de la monitorización del tráfico a largo plazo que se analizan para determinar las demandas del tráfico en función de la hora del día o de la semana; retroalimentación instantánea basada en las demandas de tráfico actuales o la longitud de las colas; y solicitudes de tráfico o informes enviados desde el extremo del cliente.
El sistema de gestión TDD puede controlarse aún más mediante Sistemas de Soporte de Operaciones (OSS) externos o leyendo y escribiendo parámetros de la Base de Datos de Información de Gestión (MIB). Se puede gestionar un solo grupo TDD o se pueden gestionar varios grupos TDD. El sistema de gestión de TDD puede ser un controlador centralizado que controle varias líneas y/o varios grupos de TDD. Alternativamente, el sistema de gestión TDD puede distribuirse entre varias piezas de equipos.
El sistema de gestión TDD puede controlar la sincronización de un grupo TDD. Esta sincronización puede ser asistida mediante el uso de uno o más de los siguientes datos de entrada: uso explícito de datos de gestión y datos de sincronización de DSLAM, EMS (Sistemas de Gestión de Elementos), OSS (Sistemas de Soporte de Operaciones) u otros elementos de red; datos de sincronización global que utilizan datos de satélites de posicionamiento global (GPS) o protocolos de temporización de red; ruido variable en el tiempo de lectura de estimación autónoma, que contiene patrones de diafonía o mediante el uso de datos de monitorización, como el recuento de errores. La referencia de temporización se puede utilizar además para controlar la sincronización de múltiples grupos TDD. El sistema de gestión TDD puede proporcionar información para ayudar a la sincronización de múltiples líneas y/o múltiples grupos TDD.
El sistema de gestión TDD puede determinar los tiempos para enviar símbolos de sincronización y la duración de los símbolos de sincronización. El sistema de gestión TDD puede programar la VTU-O para enviar símbolos de sincronización con suficiente frecuencia y duración, para que las VTU-R mantengan sincronización con la VTU-O. Estos símbolos de sincronización pueden enviarse solo en algunas franjas temporales, en algunas tramas TDD y solo utilizando algunas subportadoras. Los símbolos de sincronización pueden usar una modulación de bajo nivel para mayor robustez. Los símbolos de sincronización larga se pueden programar para que se envíen desde la VTU-O para recuperar la sincronización después de largos períodos de inactividad. El sistema de gestión TDD puede coordinar aún más los tiempos de inactividad indicando a uno o más transceptores que estén en modo de solo recepción, con el transmisor apagado durante un período de tiempo, o hasta que reciba una señal, o hasta que el tráfico en una cola cruce un umbral.
Una TU-R inactiva puede escuchar el ruido en la línea y determinar cuándo hay NEXT al leer el ruido de alta potencia que ocurre regularmente una vez cada trama TDD. Luego, la TU-R transmite señales de arranque cuando estima que este NEXT está activo, lo que debería ser durante una franja temporal hacia la red.
El sistema de gestión TDD puede utilizar varios componentes distribuidos, cada uno de los cuales funciona de forma autónoma. El sistema TDD autónomo puede leer más datos de acoplamiento de diafonía. Los datos de diafonía se pueden utilizar para determinar qué grupos TDD y qué líneas coordinar. Se puede admitir una combinación de gestión TDD centralizada y autónoma.
El sistema de gestión TDD puede controlar aún más la cancelación de FEXT utilizando, por ejemplo, vectorización. Los recursos de vectorización se pueden reasignar en tiempo real cuando cambia la relación de asimetría TDD. El sistema de gestión TDD puede adaptarse para satisfacer diversos requisitos de retardo para diferentes líneas, abonados, servicios y en diferentes momentos. El sistema de gestión TDD puede ayudar a la compatibilidad con sistemas FDM (por ejemplo, G.fast y VDSL2), utilizar identificación de diafonía y “huellas digitales” de diafonía FDM y TDD. El sistema de gestión TDD puede controlar la retransmisión, asignar franjas temporales de retransmisión, coordinar la retransmisión Híbrida que puede volver a enviar varias partes de un bloque de datos y/o varios bits de paridad.
El sistema de gestión TDD puede gestionar la asignación de franjas temporales para mensajes de confirmación (ACK) y/o mensajes de confirmación negativos (NACK). El sistema de gestión TDD puede coordinar aún más los grupos TDD que tienen una cancelación NEXT o una cancelación NEXT parcial, lo que permite cierta superposición entre las franjas temporales arriba y abajo que tienen dicha cancelación.
En esta descripción, se establecen numerosos detalles específicos tales como implementaciones lógicas, códigos de operación, medios para especificar operandos, implementaciones de partición/uso compartido/duplicación de recursos, tipos e interrelaciones de componentes del sistema, y opciones de partición/integración lógica. Será apreciado, sin embargo, por un experto en la técnica que las diferentes implementaciones pueden practicarse sin tales detalles específicos. En otros casos, las estructuras de control, los circuitos de nivel de puerta y las secuencias de instrucciones de software completas no se han mostrado en detalle para no oscurecer la descripción.
Las referencias en la especificación a “una realización”, “una realización”, “una realización de ejemplo”, etc., indican que la realización descrita puede incluir una rasgo, estructura o característica particular, pero cada realización puede no incluir necesariamente la característica particular, estructura o característica. Además, tales frases no se refieren necesariamente a la misma realización. Además, cuando se describe una rasgo, estructura o característica particular en relación con una realización, se afirma que está dentro del conocimiento de un experto en la técnica realizar dicha rasgo, estructura o característica en relación con otras realizaciones, ya sea que se describa explícitamente.
En esta descripción y reivindicaciones, pueden usarse los términos “acoplado” y “conectado”, junto con sus derivados. Debe entenderse que estos términos no pretenden ser sinónimos entre sí. “Acoplado” se utiliza para indicar que dos o más elementos, que pueden estar o no en contacto físico o eléctrico directo entre sí, cooperan o interactúan entre sí. “Conectado” se utiliza para indicar el establecimiento de comunicación entre dos o más elementos que están acoplados entre sí. Las operaciones de los diagramas de flujo y señalización se describen con referencia a ejemplos de realización. Sin embargo, debe entenderse que las operaciones de los diagramas de flujo se pueden realizar mediante variaciones distintas de las discutidas con referencia a estos otros diagramas, y las variaciones discutidas con referencia a estos otros diagramas pueden realizar operaciones diferentes a las discutidas con referencia a los diagramas de flujo.
Como se describe en este documento, las instrucciones pueden referirse a configuraciones específicas de hardware, tales como circuitos integrados específicos de aplicación (ASIC) configurados para realizar ciertas operaciones o que tienen una funcionalidad predeterminada o instrucciones de software almacenadas en la memoria incorporadas en un medio legible por ordenador no transitorio. Por tanto, las técnicas mostradas en las figuras pueden implementarse usando código y datos almacenados y ejecutados en uno o más dispositivos electrónicos (por ejemplo, un UE, un eNB, etc.). Dichos dispositivos electrónicos almacenan y comunican (internamente y/o con otros dispositivos electrónicos a través de una red) código y datos utilizando medios legibles por máquina, como medios de almacenamiento no transitorios legibles por máquina (por ejemplo, discos magnéticos; discos ópticos; memoria de acceso aleatorio; memoria de solo lectura; dispositivos de memoria flash; memoria de cambio de fase) y medios de comunicación transitorios legibles por máquina (por ejemplo, señales eléctricas, ópticas, acústicas u otras formas de propagación, como ondas portadoras, señales infrarrojas, señales digitales, etc.).
Además, tales dispositivos electrónicos incluyen típicamente un conjunto de uno o más procesadores acoplados a uno o más de otros componentes, tales como uno o más dispositivos de almacenamiento (medios de almacenamiento no transitorios legibles por máquina), dispositivos de entrada/salida del usuario (por ejemplo, un teclado, pantalla táctil y/o pantalla) y conexiones de red. El acoplamiento del conjunto de procesadores y otros componentes se realiza típicamente a través de uno o más buses y puentes (también denominados controladores de bus). Por tanto, el dispositivo de almacenamiento de un dispositivo electrónico dado normalmente almacena códigos y/o datos para su ejecución en el conjunto de uno o más procesadores de ese dispositivo electrónico. Por supuesto, una o más partes de una realización de la invención pueden implementarse usando diferentes combinaciones de software, firmware y/o hardware.
Si bien los diagramas de flujo en las figuras muestran un orden particular de operaciones realizadas por ciertas realizaciones de la invención, debe entenderse que dicho orden es ejemplar (por ejemplo, realizaciones alternativas pueden realizar las operaciones en un orden diferente,
Si bien la invención se ha descrito en términos de varias realizaciones, los expertos en la técnica reconocerán que la invención no se limita a las realizaciones descritas, sino que se puede poner en práctica con modificaciones y alteraciones. Por tanto, la descripción debe considerarse ilustrativa en lugar de limitante.

Claims (16)

REIVINDICACIONES
1. Un método en un sistema de comunicaciones de datos para gestionar múltiples canales físicos de división de tiempo cableados que están sujetos a diafonía, comprendiendo el método
obtener (1104) entrada en objetivos de tráfico para un primer canal físico y un segundo canal físico;
programar (1106), basado al menos en la entrada, franjas temporales hacia la red para la transmisión hacia la red en el primer canal físico; y
programar (1108), basado en al menos en la entrada, franjas temporales hacia el usuario para transmisión hacia el usuario en el segundo canal físico, en la que una porción de una franja temporal hacia el usuario es invariante y una porción de una franja temporal hacia el usuario varía en tiempo real,
Dicha transmisión en las franjas temporales hacia la red no es sustancialmente simultánea con transmisión en las franjas temporales hacia el usuario.
2. El método de la reivindicación 1, en el que
a) las franjas temporales hacia la red y hacia el usuario tienen una parte activa durante la cual se transmiten las señales y una porción inactiva durante la cual no se transmiten señales y en la que las partes activas de las franjas temporales hacia la red no son sustancialmente simultáneas con las porciones activas de las franjas temporales hacia el usuario; o
b) la programación de las franjas temporales hacia la red y hacia el usuario se realiza además para minimizar la diafonía en las líneas VDSL2 cercanas.
3. El método de la reivindicación 1, en el que la programación de franjas temporales hacia la red y hacia el usuario comprende programar límites de franja temporal hacia la red y hacia el usuario, en el que, opcionalmente, los límites de franja temporal son flexibles y, además, opcionalmente, tienen uno o más de:
tramas de longitud variable;
longitudes variables de las franjas temporales hacia la red; y
longitudes variables de las franjas temporales hacia el usuario.
4. El método de la reivindicación 1, que además comprende cualquiera de:
a) asignar franjas temporales a un elemento de red en base a la programación y transmitir las asignaciones desde un sistema de gestión a un elemento de red;
b) adaptar la programación de al menos una de las franjas temporales hacia la red y hacia el usuario para adaptarse a los requisitos de retardo para el otro de una fuente de tráfico hacia el usuario y hacia la red;
c) recibir solicitudes de transmisión hacia la red y hacia el usuario y en el que la programación de las franjas temporales hacia la red se basa en las solicitudes de transmisión hacia la red recibidas; y
d) en el que la programación de las franjas temporales hacia la red y hacia el usuario se realiza basándose en la entrada y al menos en parte en el uso de energía.
5. El método de la reivindicación 1, en el que la entrada comprende al menos uno de datos de suscripción estáticos, información de la capa de servicio de un administrador de políticas, datos de comportamiento para tipos de tráfico y usuarios de los canales físicos, datos de comportamiento de tráfico a largo plazo en función del tiempo, demandas de tráfico actuales, longitudes de colas, solicitudes de tráfico, asimetría hacia la red/hacia el usuario y descriptores de tráfico.
6. El método de la reivindicación 1 o la reivindicación 5, en el que la programación de franjas temporales hacia la red y hacia el usuario comprende asignar franjas temporales para lograr una relación de asimetría objetivo de flujo hacia la red/hacia el usuario de rendimiento de datos.
7. El método de la reivindicación 6, en el que:
a) la relación de asimetría hacia la red/hacia el usuario se define en número de posiciones de símbolo multitono discretas; y/o
b) la medida del rendimiento es al menos una de:
un rendimiento medio en todas las líneas,
una coincidencia de demanda de tráfico,
un rendimiento mínimo para cada canal físico,
una calidad de experiencia percibida,
un retardo medio, y
un retardo mínimo.
8. El método de la reivindicación 1, en el que la programación de franjas temporales hacia la red y hacia el usuario comprende asignar franjas temporales basados al menos en parte en el uso de energía, en el que, opcionalmente, asignar franjas temporales basados en el uso de energía comprende:
a) asignar por programación de entradas, salidas y transiciones entre estados de enlace de baja potencia y estados inactivados; o
b) asignar al menos un elemento de red a un modo de sólo recepción, con un transmisor del elemento de red apagado.
9. El método de la reivindicación 1, en el que
a) la programación de franjas temporales hacia la red y hacia el usuario comprende la asignación de franjas temporales utilizando un criterio de optimización que pondera diferentes factores; y/o
b) las franjas temporales se definen dentro de una trama de división de tiempo, en el que obtener entrada comprende recibir entrada durante una trama, y en el que la programación de franjas temporales hacia la red y hacia el usuario comprende la programación de franjas temporales hacia la red y hacia el usuario de una trama inmediatamente posterior.
10. El método de la reivindicación 9, en el que obtener una entrada comprende recibir una entrada de un controlador externo, y, opcionalmente, al menos uno de:
Datos del Sistema de Soporte de Operaciones,
Datos del Sistema de Gestión de Elementos, y
Parámetros de la Base de Datos de Información de Gestión.
11. El método de la reivindicación 1, en el que la transmisión en las franjas temporales hacia la red proviene de una pluralidad de diferentes fuentes de transmisión de extremo de red.
12. El método de la reivindicación 11, que comprende además sincronizar la transmisión hacia la red y la transmisión hacia el usuario entre una pluralidad de diferentes fuentes de transmisión de extremo de red, en el que, opcionalmente, sincronizar:
a) comprende el envío de símbolos de sincronización a una fuente de transmisiones hacia la red; y/o
b) comprende medir una serie de tiempo de diafonía variable en el tiempo y sincronizar con patrones de diafonía variables en el tiempo; y/o
c) se realiza midiendo una serie temporal de eventos de error y sincronizándose con patrones variables en el tiempo de los eventos de error.
13. El método de la reivindicación 1, en el que la programación de franjas temporales hacia la red y hacia el usuario comprende determinar una duración de las franjas temporales hacia la red y hacia el usuario y mover los tiempos de inicio de las franjas temporales hacia la red y hacia el usuario para reducir la transmisión simultánea hacia la red y hacia el usuario.
14. El método de la reivindicación 13, en el que
a) determinar una duración comprende ajustar una duración predeterminada en función de las solicitudes de ancho de banda, y/o
b) mover comprende mover sólo si las transmisiones hacia la red se superponen en el tiempo con las transmisiones hacia el usuario.
15. El método de la reivindicación 13, que comprende además reducir la duración de al menos una franja temporal hacia el usuario para reducir la transmisión simultánea hacia la red y hacia el usuario.
16. Un sistema dispuesto para realizar un método de acuerdo con una cualquiera de las reivindicaciones 1 a 15.
ES12784144T 2012-07-27 2012-10-12 Sistema de gestión y métodos de gestión de la transmisión dúplex de división de tiempo (TDD) sobre cobre Active ES2866415T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261676862P 2012-07-27 2012-07-27
PCT/US2012/060115 WO2014018072A1 (en) 2012-07-27 2012-10-12 Management system and methods of managing time-division duplex (tdd) transmission over copper

Publications (1)

Publication Number Publication Date
ES2866415T3 true ES2866415T3 (es) 2021-10-19

Family

ID=47148940

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12784144T Active ES2866415T3 (es) 2012-07-27 2012-10-12 Sistema de gestión y métodos de gestión de la transmisión dúplex de división de tiempo (TDD) sobre cobre

Country Status (10)

Country Link
US (2) US9954631B2 (es)
EP (2) EP3879803A1 (es)
JP (1) JP2015527823A (es)
KR (2) KR101759467B1 (es)
CN (2) CN109802701B (es)
AU (2) AU2012385953A1 (es)
BR (1) BR112015001818A2 (es)
CA (2) CA3047928A1 (es)
ES (1) ES2866415T3 (es)
WO (1) WO2014018072A1 (es)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6262737B2 (ja) * 2012-09-10 2018-01-17 テレフオンアクチーボラゲット エルエム エリクソン（パブル） マルチラインｔｄｄシステムのための帯域幅の割振り
FR3001311B1 (fr) * 2013-01-21 2016-05-20 Commissariat Energie Atomique Interface reseau d'un soc comportant un controleur de communication ameliore
US9614581B2 (en) * 2013-03-11 2017-04-04 Futurewei Technologies, Inc. Control and management of power saving link states in vectored TDD transmission systems
EP3020138B1 (en) * 2013-04-23 2018-06-06 Assia Spe, Llc Methods systems, and apparatuses for implementing upstream power control for dsl
US20140359113A1 (en) * 2013-05-30 2014-12-04 Sap Ag Application level based resource management in multi-tenant applications
US9722765B2 (en) * 2013-10-17 2017-08-01 Ikanos Communications, Inc. Method and apparatus for managing processing in TDD frames to enable power dissipation reduction
WO2015123815A1 (zh) * 2014-02-19 2015-08-27 华为技术有限公司 信号处理方法、装置及系统
WO2015127624A1 (zh) * 2014-02-27 2015-09-03 华为技术有限公司 串扰信道估计方法、矢量化控制实体及osd系统
WO2015156718A1 (en) * 2014-04-11 2015-10-15 Telefonaktiebolaget L M Ericsson (Publ) Controlling time division duplex operation
EP3012979B1 (en) 2014-10-24 2019-03-13 Lantiq Beteiligungs-GmbH & Co.KG Communication coexistence of tdd and fdd systems having an overlap spectrum
US10437510B2 (en) 2015-02-03 2019-10-08 Netapp Inc. Monitoring storage cluster elements
US9794979B2 (en) * 2015-04-13 2017-10-17 Qualcomm Incorporated Method for arbitration and adaptive power-cycling in a multi-channel network
US10454660B2 (en) 2015-10-08 2019-10-22 Nippon Telegraph And Telephone Corporation Transmission system, transmission method and transmission device
US10574430B2 (en) 2015-10-29 2020-02-25 Nippon Telegraph And Telephone Corporation Relay transmission system, relay transmission method, and relay transmission device
US10826671B2 (en) * 2016-01-18 2020-11-03 Sckipio Technologies S.I Ltd Dynamic resource allocation (DRA) for communication systems
CN107294685B (zh) * 2016-04-01 2020-05-12 上海诺基亚贝尔股份有限公司 Ul传输的tti长度和dl传输的tti长度不对称时的通信方法
US10306076B2 (en) 2016-08-15 2019-05-28 The Directv Group, Inc. Triplexer signal combiner
CN107979551B (zh) * 2016-10-25 2022-04-15 中兴通讯股份有限公司 一种信道误差获取方法及装置
WO2018087104A1 (en) 2016-11-08 2018-05-17 British Telecommunications Public Limited Company Method and apparatus for operating a digital subscriber line arrangement
US11201969B2 (en) 2016-11-08 2021-12-14 British Telecommunications Public Limited Company Method and apparatus for operating a digital subscriber line arrangement
EP3340519B1 (en) * 2016-12-20 2022-04-27 Alcatel Lucent Method and apparatus for full-duplex communication over wired transmission media
EP3343826B1 (en) * 2016-12-28 2022-02-23 Intel Corporation Discontinuous operation and dynamic time division duplexing for a multi-line communication system
CN106792827B (zh) * 2017-01-04 2021-10-22 惠州Tcl移动通信有限公司 一种移动终端吞吐量测试方法及系统
CN110235415B (zh) * 2017-02-13 2021-08-27 日本电信电话株式会社 带宽分配装置和带宽分配方法
WO2018166922A1 (en) 2017-03-14 2018-09-20 British Telecommunications Public Limited Company Digital subscriber line transceiver
GB2560537B (en) * 2017-03-14 2020-04-15 British Telecomm Digital subscriber line transceiver
CN108882372B (zh) * 2017-05-16 2020-11-13 大唐移动通信设备有限公司 一种时隙分配的方法和装置
WO2019055062A1 (en) * 2017-09-15 2019-03-21 Intel Corporation DEVICE FOR TRANSMITTING AND RECEIVING ON A COPPER WIRE INSTALLED IN A SUBSCRIBER LOCAL
US11621793B2 (en) * 2017-09-22 2023-04-04 Adtran, Inc. Time-division duplexing systems and methods for reducing crosstalk associated with signals communicated by coordinated dynamic time assignment transceivers
US10924253B2 (en) * 2017-12-18 2021-02-16 Arris Enterprises Llc Full duplex expander in a full duplex network
US10742508B2 (en) * 2018-02-27 2020-08-11 Intel Corporation Customer bandwidth re-distribution in point-to-multipoint access
US10873366B2 (en) * 2018-04-16 2020-12-22 Intel Corporation Virtual distribution point architecture
CN108933697B (zh) * 2018-06-30 2021-02-19 江苏有线数据网络有限责任公司 一种宽带质量检测方法
JP6821096B2 (ja) * 2018-07-11 2021-01-27 三菱電機株式会社 無線通信システム、無線通信方法およびプログラム
US12418386B2 (en) * 2019-09-27 2025-09-16 Intel Corporation Apparatuses for full duplex data transmission over a wired communication link and methods for an apparatus for full duplex data transmission coupleable to a wired communication link
WO2020053452A2 (en) * 2019-12-19 2020-03-19 Adtran GmbH COORDINATION OF DPUs IN A CROSSTALK ENVIRONMENT
US11973350B2 (en) * 2020-04-10 2024-04-30 Tigo Energy, Inc. Synchronization of signals transmitted over power lines
CN111636865B (zh) * 2020-06-04 2023-04-07 河南理工大学 一种测井电缆上数据传输系统
WO2022051404A1 (en) 2020-09-01 2022-03-10 Kumu Networks, Inc. System and method for repeater tdd synchronization
US11616736B2 (en) 2020-12-17 2023-03-28 Nokia Solutions And Networks Oy Dynamic resource allocation aided by reinforcement learning
US11848722B2 (en) * 2021-04-22 2023-12-19 Maxlinear, Inc. Mitigating next interference

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7321611B2 (en) * 1994-09-20 2008-01-22 Alereen, Inc. Method and transceiver for full duplex communication of ultra wideband signals
US5680394A (en) * 1995-07-11 1997-10-21 Amati Communications Corporation Time division duplexed high speed data transmission system and method
GB2311196A (en) * 1996-03-16 1997-09-17 Northern Telecom Ltd Minimizing crosstalk in twisted pair wires carrying TDD multitone signals
US5887032A (en) * 1996-09-03 1999-03-23 Amati Communications Corp. Method and apparatus for crosstalk cancellation
DE69829725T2 (de) 1997-11-18 2006-02-09 Amati Communications Corp., San Jose Synchronisierung von Mehrträgersendempfängern über Zeitduplexkanäle
US6480475B1 (en) 1998-03-06 2002-11-12 Texas Instruments Incorporated Method and system for accomodating a wide range of user data rates in a multicarrier data transmission system
JP2000101675A (ja) * 1998-09-21 2000-04-07 Mitsubishi Electric Corp 通信装置および通信方法
EP1037426A1 (en) * 1998-10-27 2000-09-20 Texas Instruments Incorporated Data allocation in multicarrier commumication systems
DE19852690A1 (de) 1998-11-16 2000-05-18 Mueller Umwelttechnik Verfahren und Vorrichtung zum Sanieren eines im Erdreich verlegten Altrohrstranges
US6353628B1 (en) * 1998-12-15 2002-03-05 Nortel Networks Limited Apparatus, method and system having reduced power consumption in a multi-carrier wireline environment
US6819716B1 (en) * 2000-04-04 2004-11-16 Nortel Networks Limited System, device, and method for time-domain equalizer training using injected out-of-band noise
ATE345610T1 (de) * 2000-06-16 2006-12-15 Cit Alcatel Verfahren zur übertragung eines referenztaktsignals
GB2376602B (en) 2001-06-15 2003-06-18 Motorola Inc A method for providing a communication channel in time division duplexing (TDD) mode between a TDD mobile and a TDD base station
JP2003087200A (ja) * 2001-09-07 2003-03-20 Rohm Co Ltd 光送受信装置
US7394752B2 (en) 2001-11-06 2008-07-01 The Board Of Trusttees Of The Leland Stanford Junior University Joint reduction of NEXT and FEXT in xDSL systems
US6999433B2 (en) * 2002-10-17 2006-02-14 Coppergate Communication Ltd. Method of reducing near-end crosstalk in an MxU networking architecture
KR100556843B1 (ko) * 2003-04-18 2006-03-10 엘지전자 주식회사 이동 통신 단말기의 업/다운 링크 동기화 장치 및 방법
KR20120053543A (ko) * 2003-07-11 2012-05-25 팬듀트 코포레이션 개선된 패치 코드를 갖는 타선로 누화 억제 시스템
US7366202B2 (en) * 2003-12-08 2008-04-29 Colubris Networks, Inc. System and method for interference mitigation for wireless communication
US7274734B2 (en) * 2004-02-20 2007-09-25 Aktino, Inc. Iterative waterfiling with explicit bandwidth constraints
CN1324824C (zh) * 2004-11-19 2007-07-04 中兴通讯股份有限公司 多时隙通信系统中终端同步控制命令的映射方法
US8355404B2 (en) * 2006-09-06 2013-01-15 Broadcom Corporation Method and system for an asymmetric PHY in extended range ethernet LANs
JP4907260B2 (ja) * 2006-08-18 2012-03-28 富士通株式会社 無線中継システム、無線中継局装置及び無線通信方法
AU2007308107B2 (en) * 2006-10-11 2012-08-30 Adaptive Spectrum And Signal Alignment, Incorporated High speed multiple user multiple loop DSL system
US7949005B2 (en) * 2007-09-25 2011-05-24 Intel Corporation Device, system, and method of wireless communication of base stations
CN101483511B (zh) * 2008-01-09 2013-09-18 三星电子株式会社 适用于多tdd系统共存的方法
WO2010075656A1 (zh) * 2009-01-05 2010-07-08 上海贝尔股份有限公司 用于多带时分双工系统的通信方法及装置
US20120121029A1 (en) * 2009-07-13 2012-05-17 Nokia Siemens Networks Oy Near end cross talk reduction for a mimo system
US9042211B2 (en) * 2009-12-17 2015-05-26 Ikanos Communications, Inc. Systems and methods of resource allocation for cancellation of crosstalk
US9137485B2 (en) * 2010-01-21 2015-09-15 Cadence Design Systems, Inc. Home network architecture for delivering high-speed data services
CN102487294B (zh) * 2010-12-01 2014-12-10 华为技术有限公司 中继通信方法和中继站
US9294212B2 (en) * 2011-02-15 2016-03-22 Adtran, Inc. Systems and methods for avoiding crosstalk
DE102013002388A1 (de) * 2012-02-13 2013-08-14 Lantiq Deutschland Gmbh Elektronisches Zeitanteilskommunikationsverfahren, Apparatur und System
US8817903B2 (en) * 2012-02-17 2014-08-26 Alcatel Lucent Methods and systems for reducing crosstalk
US9288032B2 (en) * 2012-04-13 2016-03-15 Futurewei Technologies, Inc. Dynamic frame structure for synchronous time-division duplexing digital subscriber lines
CN102823193A (zh) * 2012-04-28 2012-12-12 华为技术有限公司 数字用户线的信号处理方法、装置及数字用户线系统
US9577954B2 (en) * 2012-06-29 2017-02-21 Cable Television Laboratories, Inc. Time domain duplex (TDD) switching system
US9825666B2 (en) 2014-01-28 2017-11-21 Maxlinear Asia Singapore Private Limited Communication system for telephone line access with crosstalk stability

Also Published As

Publication number Publication date
US9954631B2 (en) 2018-04-24
CA2880267C (en) 2019-08-20
EP2878118B1 (en) 2021-04-07
WO2014018072A1 (en) 2014-01-30
US20180219640A1 (en) 2018-08-02
US11057137B2 (en) 2021-07-06
KR20150067133A (ko) 2015-06-17
CA2880267A1 (en) 2014-01-30
US20150215059A1 (en) 2015-07-30
CN109802701A (zh) 2019-05-24
EP3879803A1 (en) 2021-09-15
KR101759467B1 (ko) 2017-07-18
KR20170040375A (ko) 2017-04-12
EP2878118A1 (en) 2015-06-03
BR112015001818A2 (pt) 2017-08-08
CN104813646B (zh) 2018-09-21
AU2012385953A1 (en) 2015-02-26
AU2016204999A1 (en) 2016-08-04
JP2015527823A (ja) 2015-09-17
CN109802701B (zh) 2021-12-28
AU2016204999B2 (en) 2018-05-31
CN104813646A (zh) 2015-07-29
CA3047928A1 (en) 2014-01-30

Similar Documents

Publication Publication Date Title
ES2866415T3 (es) Sistema de gestión y métodos de gestión de la transmisión dúplex de división de tiempo (TDD) sobre cobre
US9288032B2 (en) Dynamic frame structure for synchronous time-division duplexing digital subscriber lines
KR101888888B1 (ko) 통신 시스템을 위한 송신 방법
DK2828977T3 (en) System for diagnosing and optimizing vectorized DSL line
EP3531609B1 (en) Customer bandwidth re-distribution in point-to-multipoint access
US20160036491A1 (en) Method and apparatus for crosstalk management among different vectored groups
CN107925599A (zh) 全双工电缆网络环境中的干扰关系表示
CN107925598A (zh) 电缆网络环境中的全双工网络架构
CN107925436A (zh) 全双工电缆网络环境中的干扰抑制
JP2018529246A (ja) 全二重ケーブルネットワーク環境内のスケジューリング機構
US9912376B2 (en) Managing crosstalk in vectored transmissions
US9866271B2 (en) Interference mitigation apparatus and interference mitigation method for home network transmission line, and communication system using same
KR101474520B1 (ko) 홈 네트워크 전송 선로의 간섭 완화 장치, 간섭 완화 방법 및 이를 이용한 통신 시스템
AU2020100539A4 (en) Coordination of DPUs in a crosstalk environment
US12375126B2 (en) Coordination of DPUs in a crosstalk environment
CN103460646A (zh) 用于在订户驻地网络中执行频谱管理的方法
CN103095337A (zh) 提高消除串扰稳定性方法、装置及局端