ES2821768T3

ES2821768T3 - Control de transmisión de datos en redes de acceso por radio

Info

Publication number: ES2821768T3
Application number: ES16873637T
Authority: ES
Inventors: Vedat Eyuboglu
Original assignee: Commscope Technologies LLC
Current assignee: Commscope Technologies LLC
Priority date: 2015-12-07
Filing date: 2016-12-02
Publication date: 2021-04-27
Anticipated expiration: 2036-12-02
Also published as: WO2017100096A1; CN108541360A; EP3387775A1; EP3387775A4; EP3387775B1; CN108541360B; US10785791B1

Abstract

Un sistema de comunicación que comprende: unidades (26a-26i, 128a-128l) remotas, cada una de las unidades (26a-26i, 128a-1281) remotas comprende una o más unidades de radiofrecuencia, RF, para intercambiar señales de RF con dispositivos móviles, comprendiendo al menos algunas de las señales información destinada para, o procedente de, un dispositivo móvil; y un controlador (22, 24, 124) separado de las unidades (26a-26i, 128a-1281) remotas por una o más redes (28), estando el controlador (22, 24, 124) conectado a una red externa, el controlador (22, 24, 124) para implementar un programador, el programador para asignar recursos para la transmisión de datos que representan la información, y estando el programador configurado para anular una transmisión de solicitud de repetición automática híbrida pendiente, HARQ, enviada por el dispositivo móvil en un proceso de HARQ programando una nueva transmisión de HARQ en el proceso de HARQ; y en el que el controlador (22, 24, 124) está configurado para acelerar la retransmisión de datos en la transmisión de HARQ anulada enviada por el dispositivo móvil realizando operaciones que comprenden: detectar, en una instancia de control de acceso al medio del controlador (22, 24, 124), un error irrecuperable para la transmisión de HARQ anulada enviada por el dispositivo móvil; enviar indicaciones en capas cruzadas a una instancia de control de enlace de radio en el controlador (22, 24, 124) para colocar un temporizador en un estado expirado, dando como resultado la transmisión de un mensaje de estado al dispositivo móvil, indicando el mensaje de estado un error en los datos; y recibir, desde el dispositivo móvil, una retransmisión de los datos en respuesta al mensaje de estado.

Description

DESCRIPCIÓN

Control de transmisión de datos en redes de acceso por radio

Campo técnico

Esta divulgación se refiere al control de transmisiones de datos en redes de acceso por radio (RANs).

Antecedentes

El uso extendido de dispositivos móviles, tales como teléfonos inteligentes, ha aumentado la demanda de capacidad de transmisión de datos móviles y de una cobertura de radiofrecuencia (RF) constante y de alta calidad en edificios y otras ubicaciones densamente pobladas. Está siendo considerado que los sistemas de red de acceso por radio centralizada (C-RAN) satisfagan esta demanda. En algunas implementaciones de C-RAN, una unidad controladora (CU) realiza la mayor parte del procesamiento de banda base, y las unidades remotas (RUs) realizan el procesamiento de RF y la parte restante del procesamiento de banda base. En los sistemas de C-RAN que soportan el estándar de evolución a largo plazo (LTE), el procesamiento de banda base en la CU puede incluir funciones críticas de terminación de programación en tiempo real y solicitud de repetición automática híbrida (HARQ). Esto puede imponer una restricción a la latencia máxima de ida y vuelta que puede ser tolerada en la red de porción delantera que es usada para conectar la CU y las RUs. En algunos casos, la latencia de ida y vuelta debe estar por debajo de un cierto umbral, tal como un milisegundo (ms), para satisfacer el requisito de tiempo más estricto para HARQ. Tal baja latencia puede ser lograble cuando la red de porción delantera usa enlaces punto a punto de alta velocidad dedicados o una red Ethernet conmutada con conmutadores de baja latencia. Pero, en otras redes de datos que pueden ser usadas en la red de porción delantera en un sistema de C-RAN, la latencia de ida y vuelta puede exceder el umbral. Los documentos WO 2014/153125, US 2009/310534, US 2009/149189 y US 2009/307554 cada uno representa la técnica anterior.

Resumen

Se da un sistema de comunicación de ejemplo de la invención en la reivindicación 1. La reivindicación 2 proporciona una realización preferida.

Los detalles de una o más implementaciones se describen en los dibujos acompañantes y la descripción a continuación. Otras características y ventajas serán evidentes a partir de la descripción y dibujos, y de las reivindicaciones.

Descripción de los dibujos

La figura 1 es un diagrama de bloques de un ejemplo de una red de radio.

La figura 2 es un diagrama de bloques que muestra el despliegue de una red de radio de ejemplo del tipo mostrado en la figura 1 en un sitio, tal como un edificio u otra área.

La figura 3 es un diagrama de bloques que muestra un ejemplo de comunicaciones entre una unidad controladora CU/remota (RU) y un dispositivo móvil.

La figura 4 es un diagrama de bloques que muestra comunicaciones de ejemplo a través de diferentes capas de comunicación de un dispositivo de red.

La figura 5 es un diagrama de bloques que muestra las comunicaciones entre una RU/CU y el equipo de usuario (UE), tal como un dispositivo móvil.

La figura 6 es un diagrama de bloques que muestra la comunicación entre las capas de control de acceso al medio (MAC) y control de enlace de radio (RLC) en una RU/CU y UE, y comunicaciones entre la RU/CU y el UE.

Las figuras 7 y 8 son diagramas de bloques que muestran ejemplos de comunicaciones de enlace ascendente entre una RU/CU y UE.

La figura 9 es un diagrama de bloques que muestra acciones de ejemplo realizadas en un proceso para relajar la restricción de latencia en HARQ de enlace descendente.

La figura 10 es un diagrama de bloques que muestra acciones de ejemplo realizadas en un proceso para relajar la restricción de latencia en HARQ de enlace ascendente.

La figura 11 es un diagrama de bloques que muestra acciones de ejemplo realizadas en un proceso para relajar la restricción de latencia en HARQ de enlace ascendente.

Los mismos números de referencia en diferentes figuras indican elementos similares.

Descripción detallada

La invención está definida por un sistema de comunicación de acuerdo con la reivindicación 1. Cualquier referencia a realizaciones y aspectos que no caigan dentro del alcance de la reivindicación independiente debe considerarse como referencia a ejemplos relacionados útiles para entender la invención.

Los sistemas y técnicas que se describen a continuación son implementaciones de ejemplo de características que pueden incluirse en una red de acceso por radio. Las reivindicaciones hechas en este documento no están limitadas a las implementaciones de ejemplo que se describen a continuación.

Con referencia a la figura 1, se despliega una red 12 de radio de ejemplo en un sitio 10 de tal manera que uno o más operadores móviles, tales como operador A 14 u operador B 16, puedan proporcionar acceso a la red móvil a una o más instancias de equipo de usuario (UE(s)) 18, 20, tales como teléfonos inteligentes, en el sitio 10. La red 12 de radio de la figura 1 puede ser implementada con diversas tecnologías de interfaz aérea. Por ejemplo, puede ser usada 4G LTE. LTE es un estándar desarrollado por 3GPP, una organización de estándares. El sitio puede ser un edificio empresarial o corporativo, un lugar público, tal como un hotel, hospital, campus universitario, o incluso un área al aire libre tal como un área de esquí, un estadio, o un área en el centro densamente poblada o una ciudad.

La red 12 de radio incluye controladores, cada uno de los cuales también se denomina como una unidad controladora (CU). Las CUs pueden contener uno o más procesadores u otros dispositivos de procesamiento en los cuales es ejecutado un código para realizar al menos algunas funciones de red y módem de banda base. Los procesadores pueden incluir hardware formado por circuitos integrados (ICs) y/u otros componentes eléctricos, tal como sistema en chips (SoCs). Cada CU 22, 24 puede contener uno o más procesadores de módem de banda base o puede estar configurada para realizar las funciones de uno o más módems de banda base. En alguna implementación, una o más de las CUs puede ser implementada usando la virtualización de funciones de red (NFV) como una aplicación de software virtualizada que se ejecuta en una máquina virtual/hipervisor. La máquina virtual/hipervisor puede ejecutarse en un hardware que es compartido con otras aplicaciones virtualizadas. El hardware puede incluir uno o más servidores y/u otros dispositivos informáticos. En algunas implementaciones, cada CU gestiona una o más de las unidades remotas (RUs) 26a, 26b, 26c, 26d, 26e, 26f, 26g, 26h, 26i ("26a-26i").

Las RUs (también denominadas puntos de radio (RPs)) pueden estar controladas por las CUs y pueden incluir hardware, tal como transceptores de radio y SoCs. Las RUs 26a-26i pueden contener transceptores de RF para transmitir señales de RF hacia y desde los UEs y para realizar funciones de interfaz de usuario de RF, entre otras funciones. Las RUs pueden tener antenas de transmisión que son integrales a las mismas o que son externas y se conectan a las RUs a través de cables de antena. En algunas implementaciones múltiples RUs servidas por una CU pueden pertenecer a la misma celda. En algunas implementaciones con base en el estándar de LTE, múltiples RUs pueden transmitir el mismo ID de Celda Física (PCI). Las RUs que pertenecen a la misma celda pueden transmitir a diferentes UEs en el mismo recurso de frecuencia de tiempo. Las RUs en la misma celda pueden transmitir las mismas señales de referencia específicas de celda y las mismas señales de control. En algunas implementaciones, una CU puede servir a múltiples celdas. En algunos ejemplos, puede haber menos funcionalidad de software ejecutándose en las RUs que en CUs 22, 24. En algunas implementaciones, las RUs están configuradas para no realizar ninguna funcionalidad de módem de banda base. En algunas implementaciones, las RUs pueden realizar alguna funcionalidad de módem de banda base. Por ejemplo, en el estándar de LTE, las RUs pueden implementar las funciones de Transformada Rápida de Fourier (FFT) e FFT Inversa (IFFT). En algunas implementaciones, las RUs pueden realizar funciones de módem de banda base de enlace descendente adicionales. Por ejemplo, las RUs pueden realizar todas, o la gran mayoría de, las funciones de capa física (descritas a continuación). A este respecto, la transmisión de datos al UE se denomina como enlace descendente (DL), y la transmisión de datos desde el UE se denomina como enlace ascendente (UL).

Los módems de banda base en las CUs y las RUs pueden estar conectados a través de una red 28. En algunas implementaciones, la red 28 puede ser una red Ethernet compuesta por uno o más conmutadores Ethernet, los cuales pueden estar, dispuestos en una configuración similar a árbol. En algunas implementaciones, todas las CUs y RUs en el sitio 10 están conectadas entre sí a través de la red 28. En algunas implementaciones, son usados uno u otros más tipos de redes de ordenador (por cable o inalámbricas) además de, o en vez de, una red Ethernet.

En este sentido, la porción de red 28 que conecta las RUs con las CUs se denomina la porción delantera, y el tiempo tomado para la transmisión de datos sobre la porción delantera se denomina retraso de porción delantera o latencia (de porción delantera). En este ejemplo, las CUs 22, 24 también están conectadas (porción trasera) a una red central del operador. La red central del operador puede incluir una puerta de acceso de seguridad (SeGW) y nodos definidos en el estándar de LTE, tales como entidades de gestión de movilidad (MME) 14a, 16a y puertas de acceso de servicio (SGW) 14b, 16b. La conexión de porción trasera a la red central del operador puede ser implementada, en parte, a través de puertas de acceso de eNodeB domésticas (HeNB GW) 30, 32.

Las CUs 22, 24 también pueden conectarse a la red central del operador a través del Internet u otra red 33 de transporte de paquetes basada en IP. Como se usa en este documento, "el Internet" puede incluir otras redes. Cuando están presentes múltiples CUs como en el ejemplo de la figura 1, una CU puede actuar como un punto de agregación y presentar una única interfaz de red de eNodoB hacia uno o más nodos en la red central; por ejemplo, una SeGW, una MME, una puerta de acceso de HeNodeB (GW), y/o una SGW. En algunas implementaciones, las CUs también pueden incluir funcionalidad de MME (no se muestra) y funcionalidad de SGW (no se muestra). Por lo tanto el tráfico puede fluir directamente entre un UE y un nodo 31 de destino en el Internet o en una red interna (por ejemplo, una red de IP) en el sitio 10 sin atravesar la red central del operador.

Cada CU puede estar asociada con un operador móvil de tal manera que las RUs gestionadas de esa manera puedan operar en un espectro que pertenece a ese operador móvil. Una CU también puede ser compartida entre múltiples operadores móviles. Entre otras cosas, las CUs pueden programar el tráfico hacia/desde los UEs asignando recursos para la transmisión sobre el aire. Cada CU 22, 24 también está conectada a un gestor 40, 42 de servicio en el ejemplo de la figura 1, el cual típicamente está ubicado en la red central del operador. El gestor de servicio es responsable de la configuración, activación y monitorización de la red de radio. También puede haber un gestor de servicio de instalación local, el cual puede permitir que el personal de tecnología de información (IT) local instale y mantenga la red de radio.

En algunas implementaciones, cada CU 22, 24 realiza, para cada celda a la que sirve, las funciones de una estación base, excepto para ciertas funciones de módem de banda base y RF que pueden ser realizadas por las RUs. En general, una estación base, tal como una celda pequeña, incluye una unidad de módem de banda base digital y una unidad de procesamiento de red. En el sistema de ejemplo de la figura 1, la funcionalidad de banda base de procesamiento (o "funcionalidad de banda base") para una celda se divide entre la CU y las RUs, realizando cada una al menos algo de la funcionalidad de banda base.

La funcionalidad de procesamiento de banda base de LTE puede ser implementada en nodos de red en hardware y/o software. Las funciones de procesamiento de banda base que forman la funcionalidad de procesamiento de banda base de LTE se describen a menudo en términos de capas de protocolo, que incluyen lo siguiente. La capa física porta información de una capa de control de acceso al medio (MAC) sobre una interfaz de RF. Las funciones de capa física típicamente incluyen codificación/decodificación, modulación/demodulación, precodificación y ecualización. Las funciones de la capa de MAC incluyen mapeo entre canales lógicos y canales de transporte, y multiplexación de unidades de datos de servicio (SDUs) de MAC desde uno o diferentes canales lógicos en bloques de transporte (TB) para ser suministrados a la capa física, corrección rápida de errores a través de HARQ, asignar recursos de LTE a los UEs a través de programación en tiempo real (que se describe a continuación), y manejo de prioridades entre canales lógicos de uno o más UEs. Las funciones de la capa de control de enlace de radio (RLC) (por encima de la capa de MAC) incluyen típicamente la transferencia de PDUs de capa superior, tal como concatenación, segmentación y reensamblaje, y corrección de errores a través de ARQ. En este sentido, HARQ y solicitud de repetición automática (ARQ) son protocolos de retransmisión que soportan una comunicación fiable entre dispositivos. Las funciones de la capa de control de convergencia de datos por paquetes (PDCP) (por encima de la capa de RLC) incluyen el manejo (entre otras cosas) de la compresión y descompresión de encabezado de datos de IP (Protocolo de Internet), protección de integridad de datos de plano de control, y cifrado y descifrado de datos de plano de usuario y datos de plano de control. Los protocolos de LTE de capa superior incluyen la subcapa de control de control de recursos de radio (RRC).

En algunas implementaciones, la programación en tiempo real incluye asignar datos de usuario a recursos de LTE de tiempo y/o frecuencia. La programación en tiempo real está basada en CSI (información de estado de canal) y otra información. En la programación de DL, la CSI es suministrada por el UE. En el estándar de LTE, la DL CSI puede incluir un indicador de calidad de canal (CQI), indicador de matriz de precodificación (PMI), e indicador de rango (RI), enviados por el UE. En la programación de UL, el estado de canal es determinado por una CU con base en transmisiones recibidas de los UEs, incluyendo DL CSI. En el estándar de LTE, el estado de canal también puede ser determinado con base en las señales transmitidas por el UE, por ejemplo, la señal de referencia de sondeo (SRS).

Cada CU puede incluir uno o más módems de banda base. Los módems de banda base pueden ser para realizar funciones de todas las capas de funcionalidades de banda base, incluyendo el procesamiento de capa de MAC/RLC/PDCP, y procesamiento de RRC de capa superior. Por ejemplo, la programación en tiempo real y terminación de HARQ, las cuales son parte de la capa de MAC, pueden ser realizadas en las CUs. Las CUs también pueden realizar el procesamiento de capa física. Además, las CUs pueden realizar otras funciones similares a una estación base tradicional, tal como la función de una unidad de procesamiento de red, por ejemplo, procesar datos de IP. En algunas implementaciones, las CUs no realizan ninguna función de RF.

En algunas implementaciones todas las funciones de capa física son implementadas en las RUs, y solo las funciones de banda base de la capa de MAC y superiores son implementadas en las CUs. En algunas implementaciones, las funciones de capa física son divididas entre las CUs y las RUs. Las funciones de receptor de canal de control de enlace ascendente, tales como el canal de control de enlace ascendente físico (PUCCH), canal de acceso aleatorio físico (PRACH), y SRS, pueden ser implementadas en su conjunto o en parte en las RUs, mientras que las funciones de receptor de PUSCH de enlace ascendente pueden ser implementadas sustancialmente en las CUs. La división funcional entre la CU y la RU puede ser diferente en el enlace descendente y en el enlace ascendente. En algunas implementaciones, sustancialmente todas las funciones de capa física de enlace descendente pueden ser implementadas en las RUs y la mayoría de las funciones de capa física de enlace ascendente son implementadas en las CUs. En otras implementaciones, todas las funciones de capa física son implementadas en la CUs.

Despliegue de red de radio

Con referencia a la figura 2, se despliega una red 120 de radio de ejemplo en un sitio 122. La red de radio de ejemplo de la figura 2 puede ser una implementación de, e incluir toda o algo de la estructura y función de la red de radio mostrada en la figura 1. En el ejemplo de la figura 2, uno o más controladores (CUs) 124 están instalados en un sala 126, por ejemplo, una sala de telecomunicaciones, localmente en el sitio 122. Las CUs también pueden ser desplegadas fuera del sitio y pueden servir a las RUs desplegadas en múltiples sitios. Las Rus 128a-1281 están distribuidas a lo largo del sitio 122. En algunas implementaciones, algunas RUs están montadas en la pared con antenas integradas, algunas RUs están ocultas en uno o más armarios, y algunas RUs están instaladas sobre la baldosa de techo y se unen a una antena de montaje en la pared a través de un cable de antena externo.

En algunas implementaciones, las RUs 128a-1281 se conectan a las CUs 124 a través de una red 130 Ethernet conmutada, la cual incluye cables de par trenzado y/o fibra óptica, y uno o más conmutadores Ethernet. Pueden ser usados otros tipos de redes en el ejemplo de la figura 2 además de, o en vez de, la red 130 Ethernet conmutada. En algunas implementaciones, la red 130 Ethernet está dedicada solo a la red de radio. En algunas implementaciones, la red 120 de radio comparte la red 130 Ethernet con otro tráfico de área local en el sitio 122. Por ejemplo, en una red empresarial tal otro tráfico puede incluir tráfico local generado por diversos ordenadores en la empresa que pueden estar conectados a los mismos conmutadores Ethernet. El tráfico de red de radio puede ser segregado de otro tráfico formando una red de área local virtual (VLAN) separada. La QoS (calidad de servicio) de alta prioridad puede ser asignada a la VLAN para controlar la latencia. En el ejemplo que se muestra en la figura 2, las CUs 124 están conectadas a un conmutador 132 Ethernet coubicado (por ejemplo, en la misma sala 126). En algunas implementaciones, la conexión 134 al conmutador 132 usa un único enlace Ethernet de 10 Gb/s que se ejecuta sobre un cable de fibra óptica o par trenzado de Categoría 6, o múltiples enlaces Ethernet de 1 Gb/s que se ejecutan sobre cables de par trenzado de Categoría 5/6.

En una red de radio, tal como las redes de radio ilustradas en las figuras 1 y 2, la comunicación entre un UE y una RU puede ser dividida en varios grupos distintos de funciones o capas relacionadas. Los datos que van a ser enviados sobre una red pasan a través de cada una de las capas, donde los datos pueden ser divididos en paquetes. Algunos ejemplos de estas capas se describen anteriormente e incluyen lo siguiente: la capa de protocolo de convergencia de datos por paquetes (PDCP), la capa de control de enlace de radio (RLC), la capa de control de acceso al medio (MAC), y la capa física (PHY). La figura 3 ilustra jerarquías de ejemplo 301,302 de capas que están incluidas en CUs, Rus, y UEs tales como las de las figuras 1 y 2.

La figura 4 ilustra la comunicación de ejemplo entre capas de protocolo. En un nodo que está transmitiendo paquetes, un paquete recibido por una capa de la capa superior se denomina unidad de datos de servicio (SDU), mientras que el paquete proporcionado a una capa inferior es la unidad de datos de protocolo (PDU). En el ejemplo de la figura 4, la PDU incluye una unidad de datos que se especifica en un protocolo de una capa dada y que incluye información de encabezado de protocolo y posiblemente datos de usuario de esa capa. Como se ilustra en la figura 4, la PDU de la capa 401 de PDCP se convierte en la SDU de la capa 402 de RLC, y la PDU de la capa de RLC se convierte en la SDU de la capa 403 de MAC. La capa 404 PHY es usada para portar MAC PDUs, también denominadas bloques de transporte (TBs). Una RLC SDU puede ser segmentada en múltiples RLC PDUs o múltiples RLC SDUs pueden ser combinadas en una única RLC PDU usando campos de indicador de longitud (LI). Un programador en tiempo real en la CU puede determinar un tamaño apropiado del bloque de transporte.

El apilamiento de protocolos se aplica tanto al DL como al UL. En este contexto, la RU y la CU se denominan colectivamente como "RU/CU", dado que una o ambas de la RU y CU pueden implementar, o ser parte de, las comunicaciones representadas. La transmisión de datos desde la RU/CU al UE es el enlace descendente (DL), y la transmisión de datos desde el UE a la RU/CU es el enlace ascendente (DL). En el DL, la RU/CU es el transmisor y el UE es el receptor. En el UL, el UE es el transmisor y la RU/CU es el receptor. HARQ permite retransmisiones rápidas entre las capas de MAC/PHY de UE 301 y RU/CU 302.

Operación de HARQ y RLC

La experiencia de usuario en LTE puede depender de varias métricas, que incluyen, por ejemplo, rendimiento de datos (cantidad de paquetes de datos que pasan a través de la red), variación rápida de retraso (variación en retraso de paquetes), y tasa de errores de paquetes (tasa de errores en paquetes de datos transmitidos). En algunos protocolos de comunicación, tal como Protocolo de Control de T ransmisión (TCP), la tasa de error de paquetes necesita ser muy baja (por ejemplo, 10-5 o menor). Sin embargo, apuntar a una tasa de error muy baja en la primera transmisión de un TB sobre el aire (OTA) puede bajar innecesariamente el rendimiento alcanzable. Por lo tanto, los protocolos de comunicación tal como LTE están diseñados para apuntar a una tasa de error moderadamente alta en una primera transmisión sobre el aire, y luego depender de retransmisiones rápidas para corregir cualquier error. Se describen en este documento ejemplos de procedimientos de retransmisión rápida para acelerar la corrección de errores. La retransmisión de datos incluye reenviar datos que son, al menos en parte, idénticos a los datos que fueron transmitidos originalmente. Por ejemplo, en el caso de retransmisión de HARQ, las cargas útiles de los datos originales y los datos retransmitidos pueden ser idénticas.

En algunos ejemplos, la corrección rápida de errores puede ser lograda usando transmisiones de HARQ en las capas de MAC/PHY que operan con una tasa de error objetivo de 10% para una primera transmisión. Para reducir la variación rápida de retraso, las retransmisiones de HARQ pueden ser relativamente rápidas. En algunas implementaciones, esto se puede lograr usando un canal de retroalimentación de único bit con una probabilidad de error objetivo de 10-4 a 10-3. Dado que la retroalimentación de HARQ no es lo suficientemente fiable para la operación de TCP, también son soportadas retransmisiones de ARQ adicionales en la capa de RLC. Las retransmisiones de RLC corrigen errores residuales de HARQ que pueden ser, por ejemplo, debidos a cuatro errores de retransmisión de HARQ consecutivos o errores en el canal de retroalimentación de HARQ. El protocolo de RLC, en su modo reconocido (AM) de operación, usa retroalimentación protegida por CRC (verificación de redundancia cíclica - protegida) para corregir errores residuales en HARQ. RLC AM también proporciona reordenamiento para corregir la recepción fuera de secuencia de RLC PDUs. Aunque los errores de HARQ pueden ser corregidos a través de retransmisión dentro de tan poco como 8 ms, las retransmisiones de RLC pueden tomar 50 ms a 100 ms.

Cada UE en una red de radio tal como los de las figuras 1 y 2, pueden tener uno o más portadores de radio, los cuales representan un tipo de tráfico diferente que puede necesitar tratamiento diferente de la red de radio. Los portadores de radio portan ya sea tráfico de señalización (Portador de Radio de Señalización, o SRB) o tráfico de datos (Portador de Radio de Datos). En algunas implementaciones, cada portador de radio tiene su propia instancia de PDCP, instancias de RLC y un ID de Canal Lógico (LCID) de Capa de MAC. En este contexto, una instancia puede ser implementada en código ejecutable por ordenador que, cuando se ejecuta, permite la comunicación a través de una capa particular. Cada instancia de PDCP puede estar asociada con una o dos instancias de RLC (enlace descendente y enlace ascendente). Cada instancia de RLC puede estar configurada para operar en AM. Una instancia de PDCP puede operar independientemente de las instancias de RLC y MAC, y puede encapsular paquetes de IP o mensajes de control de recursos de radio (RRC) en PDCP PDUs (las cuales son RLC SDUs). Una RLC SDU puede ser segmentada en múltiples RLC PDUs o múltiples RLC SDUs pueden ser combinadas en una única RLC PDU usando campos de Indicador de Longitud (LI).

En LTE, hay un acoplamiento apretado entre las capas de RLC y MAC. Un programador en tiempo real determina el tamaño de bloque de transporte (TBS) con base en el tamaño de datos de UE que esperan en un búfer y recursos de enlace aéreo disponibles. El programador en tiempo real puede ser implementado en una CU. Múltiples RLC PDUs, representadas como MAC SDUs, pueden ser multiplexadas en una única MAC PDU, la cual forma el TB. Cada MAC SDU (RLC PDU) es identificada en el encabezado de MAC PDU mediante un encabezado de MAC SDU, que incluye un ID de Canal Lógico (LCID) de 5 bits para identificar el portador de radio (o instancia de PDCP) al que pertenecen los datos, y un Indicador de Longitud (LI) para identificar la longitud de la MAC SDU. Cuando un TB no es recibido correctamente (por ejemplo, después de 4 retransmisiones de HARQ), todas las AM RLC PDUs que son portadas por el TB son retransmitidas por la capa de RLC. Los TBs usualmente portan RLC PDUs completas, pero, en una retransmisión de RLC, la RLC PDU original puede ser segmentada y dividida en múltiples TBs.

Un componente del procedimiento de RLC ARQ es un Reporte de Estado (SR), el cual es un ejemplo de un mensaje de estado, generado por el receptor de una instancia de RLC (por ejemplo, en el DL el receptor de RLC en el UE, o en el UL el receptor de RLC en la CU). Por ejemplo, un Reporte de Estado puede ser generado, por ejemplo, por un UE después de la recepción de RLC PDUs de una CU. Entre otras cosas, un Reporte de Estado identifica errores en RLC PDUs recibidas por la instancia de RLC receptora. Por ejemplo, en algunas implementaciones, el Reporte de Estado indica, a la instancia de RLC transmisora (por ejemplo, la instancia de RLC que está transmitiendo RLC PDUs), los números de secuencia (SNs) de PDUs que no fueron recibidos correctamente. En un caso de resegmentación durante la retransmisión de RLC, el Reporte de Estado también puede identificar segmentos específicos dentro de una RLC PDU que no fueron recibidos correctamente. El Reporte de Estado también puede identificar la primera RLC PDU aún no recibida, reconociendo indirectamente las PDUs hasta esa PDU como recibidas correctamente. En algunas implementaciones, el Reporte de Estado también puede incluir otra información no descrita en este documento.

En respuesta a la recepción de un Reporte de Estado, una instancia de RLC transmisora puede retransmitir todos o algunos datos transmitidos previamente, de esa manera corrigiendo de manera efectiva errores identificados en, o implícitos en, el Reporte de Estado. Los Reportes de Estado pueden ser enviados con una prioridad relativamente alta y alta fiabilidad, en algunos casos empleando verificaciones de redundancia cíclica (CRCs) para detectar cualquier error de transmisión. La transmisión de un Reporte de Estado desde un receptor de instancia de RLC puede ser activada, por ejemplo, mediante uno o más de los siguientes: expiración de un temporizador de reordenamiento t (un parámetro configurable), o sondeo explícito mediante el transmisor de instancia de RLC. En este sentido, cuando un receptor de instancia de RLC detecta una RLC PDU faltante, inicia un temporizador de reordenamiento t, y si la condición no es corregida antes de la expiración del temporizador, es enviado un Reporte de Estado. Con el fin de evitar transmisiones frecuentes de Reportes de Estado, puede ser usado un temporizador de t-Prohibición de Estado configurable. Este temporizador es iniciado cuando un Reporte de Estado es enviado, y no es enviado ningún Reporte de Estado nuevo mientras este temporizador aún está funcionando. El temporizador de reordenamiento t puede ser lo suficientemente largo para permitir que HARQ complete sus retransmisiones, de tal manera que cuando una retransmisión de HARQ retrasa la llegada de una RLC PDU, no será enviado un Reporte de Estado. En algunos ejemplos, los temporizadores de Reordenamiento t y t-Prohibición de Estado usados en el UE en el enlace descendente pueden tomar valores en el rango [0, 200] ms y [0, 500] ms, respectivamente. En algunas implementaciones, los valores predeterminados para el UE (RLC de enlace descendente) son 35 ms y 0 ms, respectivamente. En algunas implementaciones de LTE, un transmisor de instancia de RLC puede enviar hasta 512 RLC PDUs sin recibir un Reporte de Estado que indique la recepción correcta de las 512 RLC PDUs transmitidas.

Enlace descendente

Las características de ejemplo que se describen a continuación pueden ser implementada en, pero no se limitan a uso en, una red de radio, tales como las que se muestran en las figuras 1 y 2.

La figura 5 es un diagrama de bloques de operaciones de ejemplo en la transmisión de datos en un enlace descendente usando HARQ. En este ejemplo, se transmite un TB (501) desde la capa de MAC/PHY de RU/CU 500 sobre el canal compartido de enlace descendente físico (PDSCH) a la capa de MAC/PHY de UE 502 en el tiempo t = 0 ms. Cuando el UE recibe el TB de la RU/CU, envía (503) una señal de ACK/NAK (reconocida/no reconocida) 4 ms más tarde sobre el canal de control de enlace ascendente físico (PUCCH) o sobre el canal compartido de enlace ascendente físico (PUSCH), dependiendo de si al UE se le han asignado recursos de PUSCH por el programador en tiempo real en la CU. Tras recibir un NAK, la RU/CU puede retransmitir (504) el TB, en cualquier momento en o después de que hayan transcurrido 8 ms desde una primera transmisión. Las retransmisiones pueden ser enviadas en cualquier bloque de recursos usando cualquier esquema de modulación y codificación (MCS) apropiado.

Como se muestra en la figura 6, además de cada capa 614, 615 de MAC, cada capa 616, 610 de RLC también puede estar involucrada en transmisiones de HARQ de enlace descendente (DL). La capa 616 de RLC y la capa 614 de MAC pueden comunicarse entre sí a través de comunicación en capas cruzadas. En algunas implementaciones, DL HARQ soporta un máximo de ocho procesos de HARQ, por ejemplo, para un UE pueden existir hasta ocho transmisiones de TB no reconocidas en cualquier momento dado. Dado que las retransmisiones de DL pueden producirse en cualquier TTI, RU/CU 600 envía el número de proceso de HARQ al UE 602 explícitamente en un mensaje de Indicación de Control de Enlace descendente (DCI) enviado sobre el canal de control de enlace descendente Físico (PDCCH) (véase 503 de la figura 5). Cuando se usa multiplexación espacial, la RU/CU puede enviar dos TBs en el mismo TTI usando dos capas espaciales y recibir dos bits de ACK/NAK separados en respuesta a lo mismo. Cuando se recibe un NAK para una de las capas, el TB correspondiente puede ser retransmitido en la misma capa, junto con una nueva transmisión enviada a la otra capa, usando el mismo proceso de HARQ. Por lo tanto, en algunas implementaciones, la RU/CU puede identificar solo un número de proceso de HARQ incluso cuando está en uso la multiplexación espacial.

La RU/CU también indica, al UE, si una transmisión de PDSCH representa nuevos datos alternando un bit indicador de nuevos datos (NDI) en la DCI. El bit NDI puede estar configurado para permitir que el UE solucione errores de retroalimentación de HARQ. Por ejemplo, cuando el UE envía un mensaje de NAK, pero el mensaje de NAK es recibido como un mensaje de ACK por la RU/CU, la RU/CU puede enviar un nuevo TB en el mismo proceso con el NDI establecido como "alternado". Tras recibir correctamente el nuevo TB, el UE vacía su búfer de recepción suave de HARQ e intenta decodificar el nuevo TB. El antiguo TB, con las RLC PDUs contenidas en el mismo, se perderá y será retransmitido por la instancia de RLC en AM. Sin el bit NDI, el UE podría haber intentado usar la nueva transmisión para decodificar el antiguo TB. Esto puede llevar a latencia adicional. Alternativamente, cuando el UE recibe correctamente un PDSCH TB, el UE lo suministra a la instancia de capa de MAC y envía un ACK a la RU/CU. Si el ACK es recibido como un NAK o una transmisión discontinua (DTX), la RU/CU retransmitirá el mismo TB en el mismo proceso de HARQ con el NDI establecido como "no alternado". El UE reconocerá el error de retroalimentación, ignorará la retransmisión y simplemente reenviará el mensaje de ACK.

Como se muestra en la figura 6, en DL HARQ, la instancia 610 de RLC en el UE también puede contener un temporizador 611 de reordenamiento t y un temporizador 612 de t-Prohibición de estado. Cuando el temporizador de reordenamiento t expira, la instancia de RLC en el UE envía un Reporte de Estado a una instancia de RLC en la RU/CU.

Enlace ascendente

Las características de ejemplo que se describen a continuación pueden ser implementadas en, pero no se limitan a uso en, una red de radio, tales como las que se muestran en las figuras 1 y 2.

Los procesos de HARQ de enlace ascendente (UL) usan una forma sincrónica de HARQ. La figura 7 ilustra un ejemplo de un proceso de UL HARQ. En el ejemplo de la figura 7, la capa 614 de MAC/PHY de un UE 600 transmite 701 un TB en un TTI k (donde "k" es un entero que representa milisegundos mayor que cero) sobre un PUSCH a la capa 615 de MAC/PHY de RU/CU 602. En el UL, la ^{r U / C U}envía 703 un mensaje de ACK/NAK en el Canal Indicador Físico Híbrido de ARQ (PHICH) en TTI k+4, 4 ms después de recibir la transmisión de PUSCH del UE en TTI k. En este ejemplo, un NAK significa que la transmisión de PUSCH en TTI k fue recibida por error. Después de esto, se solicita una retransmisión en TTI k+8 usando los mismos bloques de recursos (RBs) y parámetros de modulación que la transmisión en TTI k. En otras palabras, un NAK no solo sirve como un reconocimiento negativo, sino también como una asignación de recursos de enlace ascendente para la retransmisión (retransmisión no adaptativa). Un ACK no significa que la transmisión de PUSCH en un TTI dado fue recibida correctamente. Tras recibir un ACK, el UE no borra inmediatamente su búfer de transmisión (Tx) de HARQ, a menos que el UE reciba un mensaje de DCI Tipo-0 acompañante que porte una asignación de recursos para TTI k+8 con un bit NDI alternado. Si el ACK no está acompañado por un mensaje de DCI Tipo-0, el significado real del ACK puede ser determinado por el UE después de que el UE reciba una asignación de enlace ascendente para el mismo proceso de HARQ. Por ejemplo, si el UE recibe una asignación de enlace ascendente en TTI k+12 para transmisión en TTI k+16 con el bit NDI alternado (indicando una nueva transmisión de datos), el UE puede concluir que el ACK recibido en TTI k+4 realmente significaba una correcta recepción. Por lo tanto, el UE puede borrar el búfer de transmisión (Tx) de HARQ para ese proceso. Si el bit NDI no está alternado (retransmisión), el UE puede concluir que el ACK recibido en TTI k+4 fue recibido por error, y retransmitir 705 el TB en TTI k+16. La asignación de RB también puede producirse más tarde, por ejemplo en TTI k+20, para la transmisión sobre el aire en TTI k+24. Por consiguiente, enviando una asignación de enlace ascendente en el mismo TTI que el ACK en TTI k+4, la CU puede lograr un tiempo de retransmisión relativamente rápido (en este ejemplo, 8 ms), (igual que en el caso de NAK) excepto de una manera adaptativa (por ejemplo, usando diferentes bloques de recursos y/o esquema de modulación y codificación).

Otro aspecto de HARQ es el uso de una versión de redundancia (RV). En versiones de ejemplo de LTE HARQ, hay cuatro posibles RVs que corresponden a diferentes conjuntos de datos codificados. Tanto en el enlace descendente como en el enlace ascendente, la RV se indica explícitamente en un mensaje de asignación de recursos mediante un índice de dos bits portado en la DCI. Cuando se usan retransmisiones no adaptativas con base en un NAK en el enlace ascendente, el UE sigue una secuencia fija específica {0, 2, 3, 1} de RVs en retransmisiones. En las retransmisiones adaptativas, DL o UL, la RV es indicada explícitamente. Un receptor de HARQ puede realizar una combinación mediante software ya sea usando combinación de canal, que involucra combinar transmisiones de la misma RV, o redundancia incremental, que proporciona combinación para diferentes RVs. En la codificación turbo, puede haber situaciones donde la combinación de canal dé mejor rendimiento que la combinación mediante software de redundancia incremental.

Como se ilustra en la figura 8, en un ejemplo, UL HARQ también soporta ocho procesos, pero estos procesos están vinculados a un TTI específico: las transmisiones en TTI k pertenecen al proceso de HARQ k (mod 8). Las capas de MAC/PHY en RU/CU se comunican con su capa de RLC respectiva a través de comunicación en capas cruzadas. El RLC en la RU/CU tiene un tiempo de Reordenamiento t y un temporizador de t-Prohibición de estado. Tras la expiración del temporizador de Reordenamiento t, la RU/CU puede enviar un Reporte de Estado a la capa de RLC en el UE. En la figura 8, el programador 620 programa las comunicaciones hacia/desde el UE, como se describe en este documento.

Relajación de restricción de latencia en HARQ de enlace descendente

En el DL, las restricciones de latencia de HARQ pueden ser relajadas retrasando la retransmisión de datos desde la CU cuando se recibe un mensaje de NAK en respuesta a una transmisión de datos inicial. Retrasar retransmisiones puede retrasar la recuperación de datos perdidos. Esto puede tener algún impacto en el rendimiento general. Sin embargo, si la latencia es relativamente pequeña (por ejemplo, del orden de 5-10 milisegundos), la disminución en el rendimiento será insignificante. Dado que la LTE de dúplex por división de frecuencia (FDD) soporta ocho procesos de HARQ, en la operación de HARQ de LTE "normal", la CU suspenderá transmisiones a un UE si la CU tiene ocho procesos de HARQ no reconocidos pendientes para ese UE. Por ejemplo, si las retransmisiones de HARQ son retrasadas por 4 ms (enviadas 12 ms después de la transmisión previa), el porcentaje de TTIs, en los cuales el UE puede ser programado consecutivamente, se reduce de 100% a 66%. Esto se debe a que, después de que el UE esté programado en ocho TTIs consecutivos, no se programa ninguna nueva transmisión para los siguientes cuatro TTIs. Para generalizar el ejemplo anterior, cuando las retransmisiones son retrasadas por "p" ms, la suspensión de HARQ reducirá el porcentaje de TTIs disponibles para programar un UE específico por p/(8 p), o 33% para p = 4 ms, 50% para p = 8 ms, y 67% para p = 16 ms. Las reducciones en TTIs disponibles para un UE no implican necesariamente una reducción en el rendimiento total de sistema. Si los TTIs restantes pueden ser llenados con datos para otros UEs, puede ser mantenido el rendimiento total de sistema. En situaciones donde la demanda de datos se concentra en un único UE, la suspensión de una transmisión del UE puede provocar una reducción en ese rendimiento del UE.

Con referencia a la figura 9, en una implementación 900 de ejemplo, a pesar del retraso en las retransmisiones de HARQ, se pueden tomar acciones para reducir el impacto del retraso en el rendimiento de UE. Por ejemplo, cuando el UE 902 tiene todos sus ocho procesos 920a-920h de HARQ pendientes; por ejemplo, aún no se ha recibido ningún mensaje de ACK para ninguno de los TBs enviados previamente en ocho procesos de HARQ diferentes, CU 901 aún puede enviar 904 un nuevo TB en cualquiera de los procesos de HARQ pendientes con el indicador de nuevos datos (NDI) establecido como "alternado”, que indica que el TB actual es un TB nuevo (aquí, "TB_1"). Al recibir TB_1 en UE 902, TB 903 transmitido previamente (por ejemplo, TB_0) en el mismo proceso de HARQ (se muestra aquí como "Proceso de HARQ = x") es/son anulados. Como resultado, el HARQ para TB_0 está efectivamente apagado. El UE 902, tras recibir 904 TB_1 en un proceso de HARQ para el cual el UE 902 envió 906 un ACK/NAK, borrará los datos antiguos (que pertenecen a TB_0) de su búfer suave de recepción de HARQ. En tanto que el UE 902 esté recibiendo datos correctamente y enviando mensajes de ACK, el UE 902 puede continuar recibiendo nuevos TBs en cada TTI y puede, en algunos casos, operar a su tasa pico. Si TB_0 es recibido 903 por el UE 902 por error, el UE 902 enviará 906 un mensaje de NAK a la CU. Sin embargo, si antes de recibir una retransmisión de TB_0, el búfer suave de recepción en el UE donde se almacena TB_0 es anulado por TB_1, entonces depende de la capa de RLC recuperar los datos perdidos de TB_0 a través de la comunicación 909a entre las capas de RLC de la RU/CU 901 y UE 902, como se describe en este documento.

Las retransmisiones de HARQ retrasadas pueden presentar una compensación para el programador 920 en la RU/CU 901. Por ejemplo, si un UE dado (por ejemplo, UE_0) debe ser programado en un TTI y un mensaje de ACK/NAK aún no está disponible para cualquiera de los ocho procesos 920a-920h de HARQ pendientes del UE debido a una alta latencia de porción delantera o cualquier otra razón (por ejemplo, errores en transmisiones de PDSCH o ACK/NAK), y no hay otros UEs con datos en búfer esperando ser programados, la RU/CU 901 puede continuar transmitiendo al UE apagando HARQ para uno o más de los TBs pendientes. Cuando los PDSCH RBs en el TTI pueden ser asignados a otros UEs con procesos de HARQ disponibles, el programador puede, en algunos ejemplos, omitir asignar cualquier RB al UE_0 sin afectar significativamente el rendimiento total de sistema. De lo contrario, el programador 920 puede asignar bloques de recursos (RBs) a UE_0 y aceptar la inhabilitación de HARQ para TBs pendientes en ese proceso. En algunos casos, el escenario descrito anteriormente, donde un UE tiene todos sus ocho procesos 920a-920h de HARQ pendientes, puede producirse más frecuentemente a medida que aumenta la latencia de porción delantera.

Cuando el programador 920 determina asignar PDSCH RBs a un UE_0 en una transmisión de HARQ pendiente, dando como resultado que la transmisión de HARQ pendiente sea anulada, el programador 920 puede implementar una o más de las siguientes operaciones para acelerar la recuperación de TBs anulados. Las operaciones de recuperación pueden ser implementadas en instancias de capa de RLC o MAC en uno o más dispositivos apropiados.

En algunas implementaciones, la RU/CU 901 puede acelerar la transmisión 909b del Reporte de Estado de RLC por un UE 902 configurando el UE con un temporizador 911 de reordenamiento t que es menor que un valor predeterminado. Después de que expira el temporizador, un Reporte de Estado es enviado automáticamente desde el UE 902 a la RU/CU 901. Como se describe en este documento, el Reporte de Estado identifica los datos que fueron recibidos correctamente por el UE 902 y los datos que aún no fueron recibidos correctamente por el UE. Por ejemplo, el Reporte de Estado puede identificar las RLC PDUs faltantes. Por ejemplo, las RLC PDUs faltantes pueden estar relacionadas con TB_0 enviado por la capa 914 de MAC en la CU que no fue recibido con éxito por la capa 915 de MAC en el UE. Alternativamente, el Reporte de Estado puede identificar qué datos fueron recibidos correctamente y el remitente (por ejemplo, la RU/CU) puede determinar, a partir de sus propios registros, qué datos no recibió correctamente el UE.

El temporizador 911 puede estar configurado enviando mensajes 909a de configuración apropiados desde la RU/CU 901 al UE 902. La RU/CU 901 puede configurar UEs con un temporizador de reordenamiento t (por ejemplo, temporizador 911) comunicándose con dispositivos de procesamiento en los UEs, y programando esos dispositivos de procesamiento con temporizadores apropiados. La configuración del temporizador de esta manera puede acelerar la recuperación de datos perdidos a través de la transmisión del mensaje 909a de configuración desde la capa 916 de RLC en la CU y 910 en el UE, activando más rápidamente una transmisión 909b de Reporte de Estado en respuesta a la expiración del temporizador 911 de reordenamiento t.

En algunas implementaciones, una instancia 914 de MAC en la RU/CU 901 recibe 906 un mensaje de NAK retrasado del UE 902 para un TB anulado, por ejemplo, TB_0. En respuesta, la instancia de MAC en la RU/CU 901 puede enviar instrucciones a todas o algunas instancias de RLC en la CU (por ejemplo, a través de la comunicación 908 en capas cruzadas) para las cuales fueron portadas PDUs en TB_0 para activar cada instancia de RLC para establecer un bit de sondeo de Reporte de Estado en la siguiente RLC PDU enviada al UE. Este bit de sondeo de Reporte de Estado activa la instancia de RLC correspondiente en el UE 902 para transmitir 909b un Reporte de Estado inmediatamente. Así este método puede acelerar la recuperación de datos perdidos a través de la capa de RLC activando una transmisión de Reporte de Estado desde el UE.

En algunas implementaciones, en vez de esperar un Reporte de Estado de una instancia de RLC en el UE 902, la RU/CU 901 puede activar por sí misma una retransmisión en las instancias de RLC. Este método emplea una interacción en capas cruzadas entre las capas de RLC y MAC/PHY. Por ejemplo, se puede mantener una asociación entre MAC PDUs (TBs) y RLC SNs o segmentos que son portados en las mismos. Cuando se pierde un TB, una instancia de MAC en la RU/CU 901, tras la recepción 906 del NAK retrasado, envía una solicitud, por ejemplo, a través de la comunicación 908 en capas cruzadas, a las instancias 916 de RLC en la RU/CU 901 instruyendo la retransmisión de las RLC PDUs perdidas o segmentos sin esperar a que llegue un Reporte de Estado del UE 902. Este método puede acelerar así la recuperación de datos perdidos a través de la capa de RLC mediante retransmisión sin requerir un Reporte de Estado de UE.

En algunas implementaciones, tras la recepción 906 de un NAK retrasado para un TB anulado, la capa 914 de MAC en la CU 901 puede retransmitir 950 el mismo TB (por ejemplo, TB_0) como nuevos datos de HARQ en cualquier proceso de HARQ disponible. Para hacer esto, el programador 920 en la CU puede priorizar el TB anulado y asignar PDSCH RBs al TB anulado. Los datos de PDSCH serán indicados usando una DCI que tiene un NDI alternado para indicar que el TB es nuevo. En otras palabras, el sistema prioriza la transmisión de la una o más transmisiones de HARQ nuevas; y asigna bloques de recursos de PDSCH a la una o más transmisiones de HARQ nuevas, con información de control de enlace descendente enviada al dispositivo móvil que incluye un conjunto de bits indicadores de nuevos datos para indicar una nueva transmisión de HARQ.

Por lo tanto, el UE 902 recibe la transmisión resultante, trata esta transmisión como nueva transmisión, e intenta decodificar la nueva transmisión. Para aumentar la probabilidad de transferencia y recepción exitosas, el programador 920 puede no permitir que este nuevo TB sea anulado de nuevo de tal manera que HARQ no esté inhabilitada una segunda vez. El programador 920 también puede asignar RBs en exceso al UE y aplicar desbloqueo al esquema de modulación y codificación (MCS) del TB con el fin de aumentar la probabilidad de transferencia y recepción exitosas.

Retransmitir el TB como nuevos datos de HARQ (por ejemplo, en respuesta a recibir un NAK retrasado para un TB anulado) puede ser ventajoso. Por ejemplo, retransmitir el TB como un nuevo dato de HARQ puede ser relativamente fácil de implementar debido a que, en algunas implementaciones, no necesita depender de ninguna comunicación 908 en capas cruzadas entre capas de RLC 916 y MAC 914. En algunos ejemplos, para aumentar la fiabilidad de este método, puede ser beneficioso aumentar el valor del temporizador de reordenamiento t de RLC (por ejemplo, a 50 ms). Hacer eso puede reducir la probabilidad de que el UE envíe un Reporte de Estado antes de recibir el TB retransmitido como nuevos datos de HARQ que produce una retransmisión prematura para las RLC PDUs que fueron portadas en el TB anulado antes de recibir la nueva transmisión de los mismos datos de TB.

En algunas implementaciones, las transmisiones de enlace descendente pueden tolerar retrasos de porción delantera más largos usando una combinación de uno o más de: retransmisiones de HARQ retrasadas, reusando ocasionalmente procesos de HARQ mientras esos procesos de HARQ aún están pendientes inhabilitando así de manera efectiva HARQ para una transmisión anterior, y usando retransmisiones rápidas en las capas de MAC/PHY o RLC para corregir posibles errores en transmisiones anteriores cuando HARQ está inhabilitada como resultado de anular un proceso de HARQ pendiente. En algunas implementaciones, las latencias de porción delantera de ida y vuelta de 8 ms (o más) pueden ser soportadas por los procesos descritos en este documento. Sin embargo, las implementaciones descritas en este documento no se limitan a soportar latencias de 8 ms; pueden ser soportadas latencias incluso más altas.

Relajación de restricción de latencia en HARQ de enlace ascendente

Con referencia a la figura 10, en una implementación 1000 de ejemplo, las restricciones de latencia en HARQ de enlace ascendente pueden ser relajadas. En el enlace ascendente, la latencia de porción delantera aumentada puede retrasar la recepción de una transmisión de UE PUSCH en la RU/CU. Para una transmisión de PUSCH recibida 1003 en un TTI k (donde k es un entero que representa milisegundos mayor que 0) en la RU/CU 1001, la RU/CU 1001 puede diferir la programación de una retransmisión de HARQ enviando por la fuerza 1004 un ACK en el PHICH sin una DCI Tipo 0 en TTI k+4, y puede programar una retransmisión 8 ms después en TTI k+12 enviando 1005 una DCI Tipo 0 para una retransmisión 1006 adaptativa en TTI k+16. Esto puede adaptarse a un aumento de 8 ms en la latencia de porción delantera de ida y vuelta. Tal enfoque puede llevar a una reducción de rendimiento. Por ejemplo, un aumento de 8 ms en la latencia de porción delantera de ida y vuelta puede llevar a una reducción del porcentaje de TTIs en los que se puede programar UE de 100% a 50%. Con tales retransmisiones retrasadas, por ejemplo, cuando se programa un UE en TTI k, ese UE no puede ser reprogramado en TTI k+8. Así, en algunos casos, cuando el UE necesita ser programado en cada TTI, su rendimiento será reducido en 50%.

Cuando el largo retraso de porción delantera hace que los datos de PUSCH lleguen 1003 más tarde a la CU 1001, se pueden tomar acciones para reducir la degradación de rendimiento de UE en el enlace ascendente. Esto se puede hacer, por ejemplo, si el programador 1020 determina que el programador no puede satisfacer la demanda de datos del UE o cuando el programador no tiene suficiente demanda de otros UEs para utilizar los recursos disponibles. En ese caso, el programador 1020 puede anular opcionalmente un proceso de HARQ pendiente programando una nueva transmisión de HARQ en el mismo proceso de HARQ. Por ejemplo, en la figura 11, el programador 1020 puede anular un proceso de HARQ pendiente asignando recursos al UE 1002 para nuevos datos. Esto se puede lograr enviando 1007, en TTI k+4, un ACK en el PHICH junto con una asignación de bloque de recursos (RB) de enlace ascendente para una nueva transmisión en DCI Tipo 0. La nueva transmisión de PUSCH se producirá en TTI k+8 1008. Esto inhabilita efectivamente HARQ para el PUSCH TB anulado, el cual el UE había transmitido 1003 en TTI k. Si ese PUSCH TB es recibido 1003 por la CU 1001 por error, una forma de recuperar el PUSCH TB es que el UE 1001 retransmita los datos correspondientes en la capa de RLC. Este proceso puede ser usado en algunos casos debido a que no hay un mecanismo en la capa de LTE MAC para que el UE retransmita un TB en la capa de HARQ/MAC después de que al UE se le asignen RBs para una nueva transmisión en el mismo proceso de HARQ.

Como se ilustra en las figuras 10 y 11, en la capa de RLC, el UE 1002 retransmitirá 1009a una RLC PDU tras recibir 1009b un Reporte de Estado de la instancia de RLC par en la CU 1001 que indica que las RLC PDUs no fueron recibidas correctamente. En este ejemplo, asumiendo que no hay errores previos, las instancias 1016 de RLC en la CU 1001 pueden transmitir 1009b un Reporte de Estado bajo una de dos condiciones: a) el RLC 1016 detecta la RLC PDU faltante después de recibir correctamente otra RLC PDU con un número de secuencia más alto, o b) el RLC 1016 recibe un sondeo de Reporte de Estado de una instancia de RLC 1010 par en el UE 1002.

Para acelerar la retransmisión de RLC de datos perdidos por un UE, después de que la instancia 1014 de PHY/MAC en la CU recibe el PUSCH TB anulado por error, la instancia de PHY/MAC en la CU puede enviar un activador a todas las instancias de RLC en la CU para transmitir de manera preventiva Reportes de Estado al UE. Dado que la instancia de PHY/MAC en la CU no conoce cuales instancias de RLC estaban representadas en el TB perdido, activará Reportes de Estado en todas las instancias de RLC del UE. Tras recibir los Reportes de Estado, las instancias de RLC en el UE retransmitirán los datos perdidos. En algunas implementaciones, la instancia de MAC en la CU, tras recibir un reporte de CRC negativo para una transmisión de PUSCH anulada, puede enviar, usando comunicaciones en capas cruzadas, un activador a las instancias de RLC en la CU y solicitar la transmisión de Reportes de Estado de la CU lo antes posible.

Las implementaciones de ejemplo de las interacciones de MAC-RLC descritas en este documento pueden ser modificadas entretejiendo el activador de Reporte de Estado en la operación normal del RLC en la CU. Por ejemplo, cuando una instancia de MAC en la CU detecta un error de HARQ irrecuperable para un TB anulado, la instancia de MAC puede enviar indicaciones en capas cruzadas a instancias de RLC en la CU para configurar temporizadores de ordenamiento t para que estén en un estado expirado. Este estado expirado hará que todas las instancias de RLC del UE en la CU envíen un Reporte de Estado tras detectar una RLC PDU faltante. Alternativamente, la indicación en capas cruzadas de la capa de MAC puede ser usada en la CU para establecer un bit de sondeo de Reporte de Estado en unas siguientes RLC PDUs recibidas del UE igual a 1 antes de que se procese un encabezado de RLC PDU.

Agrupación de submarcos de enlace ascendente

En el enlace ascendente, en un caso donde un UE es extremadamente limitado en potencia y puede no tener suficiente potencia para transmitir incluso en un número muy pequeño de RBs en cada TTI (por ejemplo, uno o dos RBs), los RBs pueden ser programados en múltiples TTIs consecutivos para satisfacer la demanda de datos. UEs tales como este pueden quedar privados de potencia por cualquier suspensión de HARQ en el programador provocada por la llegada retrasada de transmisiones de PUSCH a la RU/CU. Por lo tanto la CU puede configurar tales UEs para que operen en un modo de agrupación de submarcos, en el cual pueden ser asignados recursos al UE en múltiples TTIs consecutivos para enviar un único TB. En una implementación de ejemplo de agrupación de submarcos, pueden ser programadas cuatro versiones de redundancia de un único bloque de transporte al mismo tiempo o aproximadamente al mismo tiempo. Esto puede verse como un proceso de retransmisión preventivo, en el cual el UE transmite cuatro versiones de redundancia (RVs) sin esperar la retroalimentación de HARQ. La RV especifica cual combinación de datos está siendo enviada al UE. En algunas implementaciones de agrupación de submarcos, se le puede asignar al UE como máximo tres RBs por TTI y el orden de modulación puede estar limitado a QPSK (modulación por desplazamiento de fase en cuadratura). En el MCS más alto para QPSK (I_TBS = 10), la agrupación de submarcos puede soportar una tasa pico de 500 bits cada cuatro TTIs, o aproximadamente 125 kbps. La agrupación de submarcos permite que el UE transmita a una tasa más alta (MCS) de la que sería posible de otra manera, y puede ser útil para usuarios de VoIP (voz sobre Protocolo de Internet) en o cerca del borde de una celda. Una única retroalimentación de HARQ es usada para la agrupación, que puede reducir sobrecarga de PHICH y DCI Tipo-0. El retraso de retransmisión de HARQ puede ser reducido o evitado cuando la agrupación es recibida correctamente.

En algunas implementaciones de agrupación de submarcos, el UE puede enviar un paquete de VoLTE (voz sobre LTE) completo en cuatro TTIs, y no sufrir ningún bloqueo debido a la suspensión de HARQ. En algunas implementaciones de agrupación de submarcos, la CU envía un ACK/NAK 4 ms después de que es recibido el último submarco de la agrupación desde el UE. La CU puede ser capaz de decodificar la agrupación antes de recibir todos los cuatro submarcos, pero el UE aún puede transmitir los submarcos restantes. En algunas implementaciones de agrupación de submarcos, puede haber como máximo cuatro procesos de HARQ, cada uno ocupando cuatro submarcos, y el bucle HARQ es 16 ms (por ejemplo, la retransmisión puede producirse como mínimo 16 ms después de la primera transmisión). Esto significa que, en algunas implementaciones, la concesión para una retransmisión puede producirse 5 ms después de un ACK forzado. Por ejemplo, cuando se produce una primera transmisión de agrupación de submarcos en TTIs k hasta k+3, el ACK forzado es enviado en TTI k+7; puede ser enviada una asignación de retransmisión en TTI k+12; y la retransmisión de la agrupación puede iniciar en TTI k+16. Así, en este ejemplo, la latencia de porción delantera puede ser aumentada en 5 ms sin afectar las retransmisiones de HARQ. Por lo tanto, la agrupación de submarcos puede tolerar más latencia. Si la latencia de porción delantera es aumentada, además, por ejemplo en 8 ms, la retransmisión será retrasada hasta TTI k+32. Sin embargo, en algunas implementaciones, la agrupación de submarcos ya tiene retransmisiones incorporadas, y puede ser aceptable inhabilitar retransmisiones adicionales, con la condición de que, por ejemplo, el MCS se elija de manera más conservadora para una fiabilidad más alta. Esto se produce automáticamente cuando al UE se le asignan RBs para una nueva transmisión en TTI k+16.

Así, bajo ciertas circunstancias, los procesos descritos en este documento pueden aumentar la latencia de porción delantera (por ejemplo, en hasta 5 ms a 10 ms) y pueden operar HARQ con retransmisiones retrasadas. En algunas implementaciones, para UEs con limitada potencia, la agrupación de submarcos puede ser utilizable para mejorar la cobertura, y HARQ puede ser operada sin ningún retraso adicional en las retransmisiones. En algunas implementaciones, para evitar que las retransmisiones retrasadas disminuyan el porcentaje de TTIs disponibles para la transmisión de UL, el programador en la CU puede anular una transmisión de TB pendiente e iniciar una nueva transmisión de TB en el mismo proceso de HARQ. Tras la falla de CRC para el TB previo, el programador puede activar un Reporte de Estado de RLC para acelerar la retransmisión de RLC por el UE. En algunas implementaciones, los procesos pueden tolerar un aumento en la latencia de porción delantera (por ejemplo, 8 ms o más), como se describe en este documento.

Extensión a TD-LTE

Los procesos de ejemplo descritos en este documento pueden ser implementados tanto en sistemas de LTE por división de tiempo (TD-LTE) como en sistemas de LTE por división de frecuencia (FD-LTE). En TD-LTE, la temporización de HARQ puede ser diferente de la de FD-LTE, y puede depender de la configuración de marco en uso. La Tabla 1 a continuación muestra la temporización de HARQ normal para diferentes configuraciones de marcos de TD-LTE. También se muestra en la Tabla 1 el número de procesos de HARQ x y y para el DL y UL, indicados como [DL: x, UL: y]. En la Tabla 1, "D" significa "Enlace descendente", "U" significa "Enlace ascendente", y "S" significa "Submarco Especial".

Tabla 1

De acuerdo con las configuraciones de TD-LTE 2-5 de la Tabla 1, una CU/RU tiene solo 4 ms para una retransmisión de DL, que es lo mismo que en la duplexación por división de frecuencia (FDD) en los sistemas de FD-LTE. El programador en una CU puede retrasar la retransmisión hasta algún otro submarco de DL. En HARQ normal, esto dará como resultado una suspensión, cuando todos los procesos de DL HARQ estén pendientes. En general, el impacto de tal suspensión es menor en TD-LTE que en FD-LTE, debido a que el número de procesos de DL HARQ disponibles en TD-LTE es mayor que en FD-LTE. Como en FD-LTE, en TD-LTE puede ser anulada una transmisión de PDSCH pendiente, e inhabilitada HARQ de manera efectiva. La recuperación de datos puede ser activada usando los métodos de retransmisión de capa de RLC o MAC descritos en este documento.

En las configuraciones de TD-LTE 2-5 de la Tabla 1, la CU/RU tiene 6 ms para enviar ACK/NAK e DCI Tipo-0 en respuesta a una transmisión de PUSCH. Esto es 2 ms más largo que en FD-LTE. Si los retrasos son aumentados, además, en la operación de HARQ normal, se producirá la suspensión. Dado que, en estas configuraciones comunes, solo hay 1-3 procesos de HARQ disponibles y el UE puede tener una restricción de ancho de banda, la suspensión de transmisiones de UL puede ser problemática. Por ejemplo, en el ejemplo extremo de la configuración 5, cuando un UE está programado en el submarco 2, el UE debería recibir una asignación de recursos en el submarco 8 para una retransmisión en el submarco 12. Si la CU/RU no puede procesar la transmisión de PUSCH a tiempo para enviar la asignación en el submarco 8, en HARQ normal, el UE no puede ser programado de nuevo para nuevos datos en el submarco 12. Esto reducirá de manera efectiva el número de submarcos disponibles para la transmisión de UL en 50% desde un valor ya bajo, pero aumentará el tiempo disponible en la CU en 10 ms, de 6 ms a 16 ms.

En un ejemplo, en el submarco 8 pueden ser asignados recursos al UE para una nueva transmisión, dando como resultado que la HARQ sea inhabilitada para el TB pendiente. Luego la CU puede iniciar una recuperación de datos activando un Reporte de Estado en el DL como se describe en este documento.

Respuesta de acceso aleatorio (RA)

Además de HARQ, una latencia de porción delantera aumentada también puede afectar la transmisión oportuna del mensaje de respuesta de acceso aleatorio (RA) por la CU en respuesta a la recepción de un preámbulo de acceso aleatorio. En LTE, una vez que se recibe un preámbulo de acceso aleatorio desde el UE, el eNB necesita transmitir una respuesta de RA no más de submarcos 3+ra-Tamaño de Ventana de Respuesta más tarde, donde ra-Tamaño de Ventana de Respuesta es un parámetro específico de celda que puede, como máximo, igualar 10 ms en algunas implementaciones. En otras palabras, en algunas implementaciones, la respuesta de RA necesita ser transmitida sobre el aire no más de 13 submarcos después de recibir el preámbulo de RA. Asumiendo que la respuesta de RA está programada nominalmente (latencia cero) en el controlador al menos 2 ms antes de OTA (sobre el aire) y la detección de PRACH está disponible al menos 1 ms antes, el mensaje de respuesta de RA puede ser transmitido dentro de la ventana permitida, en tanto que la latencia de porción delantera de ida y vuelta sea menor que 13 - 2 - 1 = 10 ms. En otras palabras, en este ejemplo, la generación de respuesta de RA en la CU puede tolerar hasta 10 ms de latencia de porción delantera de ida y vuelta. Implementaciones

Aunque se hacen diversas suposiciones con el propósito de explicación, las implementaciones de ejemplo de los sistemas y métodos descritos en esta divulgación no están limitadas por estas suposiciones. En vez, la explicación con base en estas suposiciones s puede ser generalizada fácilmente a otras situaciones. Por ejemplo, los números de RUs en cada celda, el número de antenas para cada RU, y los números de celdas en una red pueden variar, por ejemplo, con base en las demandas de red.

Todas o parte de las características descritas en este documento pueden, según sea apropiado, ser implementadas usando un producto de programa de ordenador compuesto por instrucciones que están almacenadas en uno o más medios de almacenamiento legibles por máquina no transitorios, y que son ejecutables en uno o más dispositivos de procesamiento. Todo o parte de lo anterior puede ser implementado como un aparato, método, o sistema que puede incluir uno o más dispositivos de procesamiento y memoria para almacenar instrucciones ejecutables para implementar la funcionalidad.

Todos o parte de los procesos descritos en este documento y sus diversas modificaciones (de aquí en adelante denominados como "los procesos") pueden ser implementados, al menos en parte, a través de un producto de programa de ordenador, por ejemplo, un programa de ordenador incorporado de manera tangible en uno o más portadores de información, por ejemplo, en uno o más medios de almacenamiento legibles por máquina tangibles, no transitorios, para ejecución por, o para controlar la operación de, un aparato de procesamiento de datos, por ejemplo, un procesador programable, un ordenador, o múltiples ordenadores

Un programa de ordenador puede ser escrito en cualquier forma de lenguaje de programación, incluyendo lenguajes compilados o interpretados, y puede ser desplegado en cualquier forma, incluyendo como un programa independiente o como un módulo, componente, subrutina, u otra unidad adecuada para uso en un entorno informático. Un programa de ordenador puede ser desplegado para ser ejecutado en un ordenador o en múltiples ordenadores en un sitio o distribuido a través de múltiples sitios e interconectado por una red.

Las acciones asociadas con la implementación de los procesos pueden ser realizadas por uno o más procesadores programables que ejecutan uno o más programas de ordenador para realizar las funciones del proceso de calibración. Todos o parte de los procesos pueden ser implementados como, circuitería lógica de propósito especial, por ejemplo, un FPGA (arreglo de puerta programable en campo) y/o un ASIC (circuito integrado de aplicación específica).

Los procesadores adecuados para la ejecución de un programa de ordenador incluyen, a modo de ejemplo, tanto microprocesadores de propósito general como especial, y uno cualquiera o más procesadores de cualquier tipo de ordenador digital. En general, un procesador recibirá instrucciones y datos de un área de almacenamiento de solo lectura o un área de almacenamiento de acceso aleatorio o ambas. Elementos de un ordenador (incluyendo un servidor) incluyen uno o más procesadores para ejecutar instrucciones y uno o más dispositivos de área de almacenamiento para almacenar instrucciones y datos. En general, un ordenador también incluirá, o será acoplado de manera operativa para recibir datos de, o transferir datos a, o ambos, uno o más medios de almacenamiento legibles por máquina, tales como dispositivos de almacenamiento masivo para almacenar datos, por ejemplo, discos magnéticos, magnetoópticos, o discos ópticos. Los medios de almacenamiento legibles por máquina adecuados para incorporar instrucciones y datos de programa de ordenador incluyen todas las formas de área de almacenamiento no volátil, incluyendo a modo de ejemplo, dispositivos de área de almacenamiento de semiconductores, por ejemplo, EPROM, EEPROM, y dispositivos de área de almacenamiento flash; discos magnéticos, por ejemplo, discos duros internos o discos extraíbles; discos magnetoópticos; y discos de CD-ROM y DVD-ROM.

Elementos de diferentes implementaciones descritas en este documento pueden ser combinados para formar otras implementaciones no descritas específicamente anteriormente. Elementos pueden quedar fuera de los procesos, programas de ordenador, etc. descritos en este documento sin afectar negativamente su operación. Adicionalmente, diversos elementos separados pueden ser combinados en uno o más elementos individuales para realizar las funciones descritas en este documento.

Claims

REIVINDICACIONES

1. Un sistema de comunicación que comprende:

unidades (26a-26i, 128a-128l) remotas, cada una de las unidades (26a-26i, 128a-1281) remotas comprende una o más unidades de radiofrecuencia, RF, para intercambiar señales de RF con dispositivos móviles, comprendiendo al menos algunas de las señales información destinada para, o procedente de, un dispositivo móvil; y

un controlador (22, 24, 124) separado de las unidades (26a-26i, 128a-1281) remotas por una o más redes (28), estando el controlador (22, 24, 124) conectado a una red externa, el controlador (22, 24, 124) para implementar un programador, el programador para asignar recursos para la transmisión de datos que representan la información, y estando el programador configurado para anular una transmisión de solicitud de repetición automática híbrida pendiente, HARQ, enviada por el dispositivo móvil en un proceso de HARQ programando una nueva transmisión de HARQ en el proceso de HARQ; y

en el que el controlador (22, 24, 124) está configurado para acelerar la retransmisión de datos en la transmisión de HARQ anulada enviada por el dispositivo móvil realizando operaciones que comprenden:

detectar, en una instancia de control de acceso al medio del controlador (22, 24, 124), un error irrecuperable para la transmisión de HARQ anulada enviada por el dispositivo móvil;

enviar indicaciones en capas cruzadas a una instancia de control de enlace de radio en el controlador (22, 24, 124) para colocar un temporizador en un estado expirado, dando como resultado la transmisión de un mensaje de estado al dispositivo móvil, indicando el mensaje de estado un error en los datos; y

recibir, desde el dispositivo móvil, una retransmisión de los datos en respuesta al mensaje de estado.

2. El sistema de comunicación de la reivindicación 1, en el que el dispositivo móvil está configurado para operar en un modo de agrupación de submarcos.