ES2932073T3 - Conmutación de conjunto de información de control de enlace descendente al usar agregación de portadora - Google Patents

Abstract

Un método realizado por un dispositivo de acceso (110, 140) que comprende enviar desde el dispositivo de acceso (110, 140) a un equipo de usuario, UE (130), en un canal de control de enlace descendente físico, PDCCH, una primera información de control de enlace descendente, DCI , configurado con formatos DCI (402, 404, 406; 502, 504, 506, 508) que contiene un campo indicador de portador, CIF (405, 507). El método comprende enviar desde el dispositivo de acceso al UE un mensaje de control de recursos de radio, RRC, para ordenar al UE que cambie de usar el primer conjunto DCI a usar un segundo conjunto DCI. El mensaje RRC que es para reconfigurar el UE, cuando los portadores se agregan para que los use el UE, hace que el UE cambie (700) de monitorear el primer conjunto de información de control de enlace descendente, DCI, a monitorear el segundo conjunto DCI. El primer conjunto DCI comprende un conjunto de formatos DCI que tienen un tamaño CIF de 3 bits, (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Conmutación de conjunto de información de control de enlace descendente al usar agregación de portadora

Antecedentes

Como se usa aquí, los términos "equipo de usuario" ("UE"), "estación móvil" ("MS"), y "agente de usuario" ("UA") pueden referirse en algunos casos a dispositivos móviles tales como teléfonos móviles, asistentes digitales personal, ordenadores de mano o portátiles, y dispositivos similares que tienen capacidades de telecomunicaciones. Los términos "MS", "UE", "UA", "dispositivo de usuario", y "nodo de usuario" se pueden usar como sinónimos aquí. Un UE podría incluir componentes que permitan que el UE se comunique con otros dispositivos, y también podría incluir uno o más módulos de memoria extraíbles asociados, tal como pero no limitado a una Tarjeta de Circuito Integrado Universal (UICC) que incluye una aplicación de Módulo de Identidad de Suscriptor (SIM), una aplicación de Módulo de Identidad de Suscriptor Universal (USIM), o una aplicación de Módulo de Identidad de Usuario Extraíble (R-UIM). Alternativamente, un UE tal podría consistir del dispositivo mismo sin un módulo tal. En otros casos, el término "UE" podría referirse a dispositivos que tienen capacidades similares pero que no son transportables, tal como ordenadores de escritorio, decodificadores, o aparatos de red. El término "UE" también puede referirse a cualquier componente de hardware o software que pueda terminar una sesión de comunicación para un usuario.

A medida que la tecnología de telecomunicaciones ha evolucionado, se ha introducido equipo de acceso a red más avanzado que puede proporcionar servicios que no eran posibles previamente. Este equipo de acceso a red puede incluir sistemas y dispositivos que son mejoras del equipo equivalente en un sistema inalámbrico de telecomunicaciones tradicional. Tales equipos de generación avanzada o de próxima generación pueden incluirse en estándares de comunicaciones inalámbricas en evolución, tal como Evolución a Largo Plazo (LTE) y LTE-Avanzada (LTE-A). Por ejemplo, un sistema de LTE o LTE-A puede ser una Red de Acceso de Radio Terrestre Universal Evolucionada (E-UTRAN) e incluir un nodo B de E-UTRAN (o eNB), un punto de acceso inalámbrico, un nodo de retransmisión, o un componente similar en vez de una estación base tradicional. Como se usa aquí, el término "nodo de acceso" se refiere a cualquier componente de la red inalámbrica, tal como una estación base tradicional, un punto de acceso inalámbrico, nodo de retransmisión, o un nodo B o eNB de LTE o LTE-A, que crea un área geográfica de cobertura de recepción y transmisión que permite a un UE o un nodo de retransmisión acceder a otros componentes en un sistema de telecomunicaciones. En este documento, el término "nodo de acceso" y "dispositivo de acceso" se pueden usar de manera intercambiable, pero se entiende que un nodo de acceso puede comprender una pluralidad de hardware y software.

El documento "issues for DL control signalling design" 3GPP DRAFT; R1-093823, 12-16 de octubre de 2009 analiza problemas para el Diseño de señalización de control de enlace descendente.

El documento "Further refinement to DL control signalling for carrier aggregation", 3GPP DRAFT; R1-093226-PDCCH, 19 de agosto de 2009, divulga un perfeccionamiento de la estructura de señalización de control de enlace descendente de múltiples portadoras.

Resumen

Se proporciona un método y un dispositivo de acceso de acuerdo con las reivindicaciones

Breve descripción de los dibujos

Para un entendimiento más completo de esta divulgación, ahora se hace referencia a la siguiente breve descripción, tomada en relación con los dibujos acompañantes y descripción detallada, en donde números de referencia similares representan partes similares.

La figura 1 es un diagrama de un sistema de comunicación, de acuerdo con una realización de la divulgación.

La figura 2 es un diagrama que ilustra agregación de portadoras, de acuerdo con una realización de la divulgación.

La figura 3 es un diagrama que ilustra implementaciones alternativas de agregación de portadoras, de acuerdo con una realización de la divulgación.

La figura 4 es un diagrama que ilustra la adición de un campo de CIF a una DCI de Versión 8 mientras que se retiene cualquier bit de relleno existente, de acuerdo con una realización de la divulgación.

La figura 5 es un diagrama que ilustra la adición de un campo de CIF a una DCI de Versión 8 mientras que se extrae cualquier bit de relleno existente, de acuerdo con una realización de la divulgación.

La figura 6 es un diagrama que ilustra un procedimiento de negociación de dos vías para realizar conmutación de conjunto de DCI, de acuerdo con una realización de la divulgación.

La figura 7 es un diagrama de flujo que ilustra un método para realizar conmutación de conjunto de DCI, de acuerdo con una realización de la divulgación.

La figura 8 ilustra un procesador y componentes relacionados adecuados para implementar las diversas realizaciones de la presente divulgación.

Descripción detallada

Debe entenderse desde el principio que aunque a continuación se proporcionan implementaciones ilustrativas de una o más realizaciones de la presente divulgación, los sistemas y/o métodos divulgados pueden implementarse utilizando cualquier número de técnicas, ya sean conocidas actualmente o existentes. La divulgación no debe limitarse en modo alguno a las implementaciones, dibujos y técnicas ilustrativos que se ilustran a continuación, incluidos los diseños e implementaciones de ejemplo ilustrados y descritos en el presente documento, pero pueden modificarse dentro del alcance de las reivindicaciones adjuntas.

Como se usa a lo largo de la especificación, reivindicaciones, y figuras, los siguientes acrónimos tienen las siguientes definiciones. A menos que se exprese lo contrario, todos los términos se definen por y siguen las normas descritas por las especificaciones técnicas de Programa de Asociación de Tercera Generación (3GPP).

"ACK" se define como "Reconocimiento".

"AM" se define como "Modo Reconocido".

"ARQ" se define como "Solicitud de Repetición Automática".

"CA" se define como "Agregación de Portadora".

"CCE" se define como "Elemento de Canal de Control".

"CI" se define como "Indicador de Portadora".

"CIF" se define como "Campo Indicador de Portadora".

"DCI" se define como "Información de Control de Enlace descendente".

"eNB" se define como "Nodo B de E-UTRAN".

"FDD" se define como “Duplexación de División de Frecuencia".

"HARQ" se define como "Solicitud de Repetición Automática Híbrida".

"LTE" se define como "Evolución a Largo Plazo".

"LTE-A" se define como "LTE-Avanzada".

"MAC" se define como "Control de Acceso a Medios".

"NACK" se define como "Reconocimiento Negativo".

"PDU" se define como "Unidad de Datos de Protocolo".

"RAN" se define como "Red de Acceso de Radio".

"Versión" seguido por un número se refiere a un número de versión de las especificaciones de 3GPP.

"RLC" se define como "Control de Enlace de Radio".

"RNTI" se define como "Identificador Temporal de Red de Radio".

"RRC" se define como “Control de Recursos de Radio ".

"PDCCH" se define como "Canal de Control de Enlace Descendente Físico".

"PDCP" se define como "Protocolo de Convergencia de Datos por Paquetes".

"PDSCH" se define como "Canal Compartido de Enlace Descendente Físico".

"PUSCH" se define como "Canal Compartido de Enlace Ascendente Físico".

"SDU" se define como "Unidad de Datos de Servicio".

"SFN" se define como "Número de Marco de sistema".

"SRB" se define como "Portador de Radio de Señalización".

"TDD" se define como "Duplexación de División de Tiempo".

"Tx" se define como "Transmisión".

"UE" se define como "Equipo de Usuario".

Las realizaciones descritas aquí se relacionan con procedimientos de conmutación de conjunto de DCI. Un conjunto de DCI es una o más instancias discretas de información de enlace de control de descarga transmitida desde el eNB al UE. Un conjunto de DCI puede referirse al conjunto de DCIs de no CIF o a un conjunto de DCIs de CIF, donde una DCI de no CIF no incluye un Campo de Indicador de Portadora (CIF) mientras que una DCI de CIF incluye un CIF. La conmutación de conjunto de DCI se refiere a los procedimientos para conmutar de usar DCIs de no CIF a DCIs de CIF, o de usar DCIs de CIF a DCIs de no CIF, o de usar DCIs de CIF con un CIF de cierta longitud a DCIs de CIF con un campo de CIF de longitud diferente.

Actualmente, existen problemas con respecto a la conmutación de conjunto de DCI al usar la agregación de portadora. En la agregación de portadora, las portadoras de componentes múltiples pueden agregarse y pueden asignarse en un submarco a un UE. Un ejemplo de un problema que puede surgir con respecto a la conmutación de conjunto de DCI al usar la agregación de portadora es asegurar que el eNB y UE no pierdan contacto entre sí durante el procedimiento de conmutación de conjunto de DCI. El contacto podría perderse como un resultado de errores, tal como un error de NACK a ACK. El eNB y el UE también pueden perder contacto entre sí debido a que los formatos de DCI correspondientes en cada uno de los múltiples conjuntos de DCI pueden tener diferentes longitudes. Por esta razón, el eNB podría estar transmitiendo un formato de DCI con una longitud, mientras que el UE está intentando descodificar a ciegas ese formato de DCI con respecto a una longitud diferente. Estos problemas se describen con más detalle a continuación.

Las realizaciones descritas aquí proporcionan al menos siete técnicas diferentes para abordar estos y otros problemas. En una realización, se puede especificar un tiempo de activación de tal manera que el UE pueda recibir una orden de RRC y transmitir un reconocimiento de RRC de tal manera que el eNB pueda reducir o eliminar la posibilidad de que ocurra un error de NACK a ACK en la transmisión de enlace ascendente desde el UE. Los errores de NACK a ACK se describen en detalle a continuación. El tiempo en el que el eNB puede no ser consciente de un error de NACK a ACK del UE puede referirse como una ventana de incertidumbre.

En una segunda realización, el eNB podría no asignar recursos al UE a través del PDCCH durante una ventana de incertidumbre. Este procedimiento reduce la probabilidad de que el UE reciba comunicaciones de PDCCH que el UE no puede descodificar a ciegas.

En una tercera realización, el eNB puede transmitir DCIs desde ambos conjuntos de DCI durante la ventana de incertidumbre. Al usar esta técnica, el conjunto de DCI que estaba usando actualmente el UE es menos relevante, debido a que DCIs de ambos conjuntos estarían presentes en el PDCCH.

En una cuarta realización, se podría proporcionar un nuevo formato de DCI. El nuevo formato de DCI podría definirse de tal manera que el UE siempre pueda buscar el nuevo formato de DCI en el PDCCH, independientemente de la configuración actual de múltiportadoras del UE.

En una quinta realización, la descodificación a ciegas de conjunto de DCI doble se puede realizar en el UE en una técnica que podría referirse como una negociación de dos vías. En esta realización, el UE señala al eNB que el UE está monitorizando ambos conjuntos de DCI de tal manera que el eNB pueda conmutar a usar el nuevo conjunto de DCI. A su vez, el eNB señala al UE que el eNB ya no está transmitiendo la antigua DCI de tal manera que el UE puede dejar de monitorizar el antiguo conjunto de DCI.

En una sexta realización, se hace una especificación o determinación con respecto a cual conjunto de DCI se debe usar cuando estén presentes longitudes de DCI ambiguas. En una séptima realización, se puede hacer una conmutación al modo de transmisión no ambiguo antes de conmutar los conjuntos de DCI. Ambas de estas realizaciones se describen en detalle a continuación. Adicionalmente, estas siete realizaciones son solo de ejemplo, ya que se proporcionan realizaciones adicionales aquí.

La figura 1 ilustra una realización de una RAN 100, que puede ser una red de LTE o LTE-A como se describe en las especificaciones de 3GPP. La figura 1 es de ejemplo y puede tener otros componentes o disposiciones en otras realizaciones. En una realización, RAN 100 puede ser una red de LTE-A y puede incluir uno o más nodos 110 y 140 de acceso, uno o más nodos de retransmisión (RNs) 120, y uno o más UEs 130. La figura 1 muestra un segundo nodo 140 de acceso que está presente. Ya sea el nodo 110 o 140 de acceso puede ser un eNB, una estación base, u otro componente que promueva el acceso a red para los UE 130. Los UE 130 pueden comunicarse entre sí a través de RAN 100, pueden comunicarse con los diversos componentes de la RAN 100 mostrada, y también puede comunicarse con otros componentes no mostrados. RAN 100 puede habilitar un sistema inalámbrico de telecomunicaciones.

La figura 2 es un diagrama que ilustra la agregación de portadoras, de acuerdo con una realización de la divulgación. En LTE-A, la agregación de portadora podría usarse con el fin de soportar anchos de banda de transmisión más amplios y por tanto aumentar la tasa de datos pico potenciales, por ejemplo, para cumplir requisitos de LTE-A. En la agregación de portadora, las portadoras de componentes múltiples se agregan y pueden asignarse en un submarco a un UE, como se muestra en la figura 2. En este ejemplo, cada portadora 210a, 210b, 210c, 210d, y 210e de componentes tiene un ancho de alrededor de 20 MHz. El ancho de banda total de sistema es alrededor de 100 MHz. Se nota que las portadoras de componentes pueden tener otros anchos de banda tal como 10MHz. El UE puede recibir o transmitir en un múltiple, tal como hasta cinco, de portadoras de componentes, por ejemplo, dependiendo de las capacidades del UE. Además, dependiendo del escenario de despliegue, la agregación de portadora puede ocurrir con portadoras ubicadas en la misma banda de frecuencia y/o portadoras ubicadas en bandas diferentes. Por ejemplo, una portadora puede ubicarse a 2 GHz y una segunda portadora agregada puede ubicarse a 800 MHz.

En LTE-A, una opción para transmitir un PDCCH en la agregación de portadora es transmitir el PDCCH en una portadora diferente a la portadora en la que se transmite el PDSCH correspondiente al usar un CIF explícito. Las realizaciones descritas aquí proporcionan soluciones y procedimientos de UE para resolver diversos problemas, incluyendo pero no limitados a, los relacionados con la introducción del CIF explícito.

Uno de los problemas asociados con la agregación de portadora es el diseño del PDCCH. Actualmente, existen dos opciones actualmente para el diseño de PDCCH. La opción 1 es que el PDCCH se transmite en la misma portadora como la portadora en la que se transmite el PDSCH correspondiente, y la opción 2 muestra que el PDCCH se puede transmitir en una portadora diferente de la portadora en la que al menos uno de los PDSCH correspondientes es transmitido.

En la primera opción, el PDCCH en una portadora de componente asigna recursos de PDSCH en la misma portadora de componente y los recursos de PUSCH en una única portadora de componente de enlace ascendente enlazada. En este caso, no está presente el campo indicador de portadora. Es decir, la estructura de PDCCH de Versión 8 puede continuar usándose con la misma codificación, misma planificación de recursos basada en CCE, y formatos de DCI.

Con respecto a la segunda opción, el PDCCH en una portadora de componente puede asignar recursos de PDSCH o PUSCH en una de portadoras de componentes múltiples usando el campo indicador de portadora. En este caso, los formatos de DCI de Versión 8 se extienden con un campo indicador de portadora de 1 - 3 bits. El resto de la estructura de PDCCH de Versión 8 puede reusarse con la misma codificación y misma planificación de recursos basada en CCE.

La figura 3 es un diagrama que ilustra implementaciones alternativas de agregación de portadora, de acuerdo con una realización de la divulgación. La figura 3 muestra las dos alternativas anteriores. La primera alternativa, que se muestra en la flecha 300, muestra que el PDCCH se transmite en la misma portadora como la portadora en el que se transmite el PDSCH. La segunda alternativa, que se muestra en la flecha 302, muestra que el PDCCH puede transmitirse en una portadora diferente de la portadora en la que se transmite el PDSCH. Para esta segunda alternativa, se puede usar un CIF para indicar la portadora en la que se asigna el PDSCH o PUSCH. El CIF requiere bits de señalización adicionales que se añaden a una DCI, ya sea para una concesión de recursos de enlace descendente o concesión de recursos de enlace ascendente, para permitir que la señalización de PDCCH en una portadora de monitorización de PDCCH se refiera a recursos en una portadora diferente.

Tabla 1 hasta

La tabla 4, a continuación, contiene las longitudes de bits de todas las DCI para diferentes anchos de banda, y también para los casos de FDD frente a TDD, y dos antenas de transmisión en el eNB frente a 4 antenas de transmisión. Las DCI 0, 1A, y 3/3A pueden tener siempre la misma longitud. Las longitudes de DCIs 1B, 1D, 2, y 2A varían, en parte, basadas en el número de antenas de transmisión en uso en el eNB.

Tabla 1: Tamaños de formato de DCI en Versión 8 de LTE. Esta tabla se relaciona con FDD con dos antenas de transmisión en el eNB.

Tabla 2: Tamaños de formato de DCI en Versión 8 de LTE. Esta tabla se relaciona con FDD con cuatro antenas de transmisión en el eNB.

Tabla 3: Tamaños de formato de DCI en Versión 8 de LTE. Esta tabla se relaciona con TDD con dos antenas de transmisión en el eNB.

Tabla 4: Tamaños de formato de DCI en Versión 8 de LTE. Esta tabla se relaciona con TDD, cuatro antenas de transmisión en el eNB.

Conmutación de conjunto de DCI

Un problema que no se aborda completamente en las especificaciones técnicas existentes es la conmutación de conjunto de d C i cuando está en uso la agregación de portadora. Las realizaciones descritas aquí se relacionan con la conmutación de conjunto de DCI cuando está en uso la agregación de portadora. Los siguientes párrafos resumen brevemente algunas de estas realizaciones, así como los problemas que se relacionan con la conmutación de conjunto de DCI.

Un conjunto de DCI se refiere ya sea al conjunto de DCIs de no CIF, tal como DCIs de Versión 8, o a un conjunto de DCIs de CIF. Pueden existir múltiples conjuntos de DCI de CIF con campos de CIF de diferente longitud. Un campo de CIF puede tener una longitud de 1 a 3 bits, posiblemente más.

La conmutación de conjunto de DCI se refiere a un procedimiento para conmutar de usar DCIs de no CIF a DCIs de CIF, o de usar DCIs de CIF a DCIs de no CIF, o de DCIs de CIF con un campo de DCI de cierta longitud a DCIs de CIF con un campo de DCI de longitud diferente. Las realizaciones descritas aquí describen principalmente la conmutación de DCIs de no CIF a DCIs de CIF, pero todos los problemas identificados y soluciones propuestas pueden ser igualmente aplicables para conmutar en la dirección opuesta. De este modo, las realizaciones no se limitan a conmutar de DCIs de no CIF a DCIs de CIF, sino que incluyen cualquier tipo de conmutación de conjunto de DCI.

En una realización, el CIF puede incluir bits de señalización adicionales que se añaden a un formato de DCI para permitir que la señalización de PDCCH en una portadora de monitorización de PDCCH se refiera a recursos de PDSCH o PUSCH en una portadora diferente. El CIF se puede usar ya sea para una asignación de recursos de enlace descendente o una concesión de recursos de enlace ascendente.

DCIs de no CIF pueden referirse a DCIs que no incluyen un CIF, tal como las DCI de Versión 8. Esta realización también puede incluir la situación donde la longitud del CIF era cero.

DCIs de CIF pueden incluir un CIF adicional de 1-3 bits de longitud con todas las DCI relevantes para indicar la portadora en la que está asignado el PDSCH o PUSCH. Un conjunto de DCI puede referirse ya sea al conjunto de DCIs de no CIF o a un conjunto de DCIs de CIF. Pueden existir múltiples conjuntos de DCI de CIF, con cada conjunto de DCI de CIF teniendo campos de CIF de diferente longitud.

DCI X puede referirse a un formato o longitud de DCI específico en un conjunto de DCI particular, tal como (pero no limitado a) el conjunto de DCIs de no CIF. DCI X+ puede referirse al formato o longitud de DCI correspondiente en un conjunto de DCI diferente, tal como (pero no limitado a) el conjunto de DCIs de CIF. DCI X+ puede tener una mayor longitud que DCI X, debido a la presencia del campo de CIF adicional.

Un caso donde DCI X y DCI X+ pueden tener la misma longitud es si DCI X se ha rellenado para evitar una longitud de DCI ambigua. Las longitudes ambiguas incluyen 12, 14, 16, 20, 24, 26, 32, 40, 44, y 56, y posiblemente otras. En un ejemplo, si DCI X incluye un bit de relleno y DCI X+ incluye un CIF de un bit, entonces DCI X y DCI X+ pueden tener la misma longitud. Un ejemplo adicional de esta situación sería DCI 1A para un ancho de banda de 10 MHz. Esta DCI tiene una longitud de 27 bits, de los cuales 1 bit es un bit de relleno con el fin de evitar la longitud ambigua de 26 bits. Sin embargo, la DCI 1A correspondiente con un CIF de 1 bit también tendría una longitud de 27 bits, debido a que el bit de relleno extra no sería requerido en este caso.

El entendimiento de la conmutación de conjunto de DCI puede mejorarse mediante un entendimiento de señalización de RRC. En la señalización de RRC, una orden de RRC se refiere a un mensaje de RRC enviado desde el eNB al UE para ordenar que se realice un procedimiento de RRC específico. Ejemplos de un procedimiento tal incluyen la activación, reconfiguración, o desactivación de múltiportadoras. El reconocimiento de r Rc se refiere a un mensaje de RRC enviado desde el UE al eNB para reconocer que un procedimiento de RRC ordenado se ha completado con éxito, o posiblemente sin éxito.

Como se menciona anteriormente, existen algunos problemas relacionados con el procedimiento de conmutar de usar un conjunto de DCI, referido como el antiguo conjunto de DCI, a usar otro conjunto de DCI, referido como el nuevo conjunto de DCI. Por ejemplo, la conmutación puede ocurrir desde un conjunto de DCI de no CIF a un conjunto de DCI de CIF, tal como en la activación de múltiportadoras o la configuración de un subconjunto de portadoras activas como portadoras de monitorización de PDCCH. En otro ejemplo, la conmutación puede ocurrir desde un conjunto de DCI de CIF a un conjunto de DCI de no CIF, tal como en la desactivación de múltiportadoras o la configuración de todas las portadoras activas como portadoras de monitorización de PDCCH. En aún otro ejemplo, la conmutación puede ocurrir desde un conjunto de DCI de CIF con una longitud de CIF de M a un conjunto de DCI de CIF diferente con una longitud de CIF de N (M^N), tal como en la reconfiguración de múltiportadoras, donde se cambia la longitud del campo de CIF.

Una realización para conmutar los conjuntos de DCI se puede describir usando las siguientes etapas. Estas etapas también ilustran la entrada de red para un UE capaz de soportar múltiples portadoras. Primera, un UE capaz de soportar múltiples portadoras puede realizar la entrada de red como un UE de Versión 8, incluso si el UE es un UE de Versión 10. El eNB puede usar DCIs de no CIF para enviar información de PDCCH al UE. Segunda, el UE de múltiportadoras puede señalar sus capacidades de múltiportadoras al eNB a través del procedimiento de intercambio de capacidad de UE. Tercera, el eNB puede reconfigurar el UE para la operación de múltiportadoras, que incluye el uso de DCIs de CIF en el PDCCH como señalización de control dedicada a ese UE. La señalización de PDCCH de emisión, tal como información de sistema (SI-RNTI) y paginación (P-RNTI) puede continuar usando DCIs de no CIF.

En uno o más puntos durante el procedimiento anterior, tanto el eNB como UE podrían necesitar conmutar de usar un conjunto de ^d Cⁱ a usar un conjunto de DCI diferente. Los puntos de tiempo exactos para la conmutación de conjunto de DCI pueden no ser necesariamente los mismos para el eNB y UE. Un problema relacionado con la conmutación de conjunto de DCI en este procedimiento es asegurar que el eNB y UE no pierdan contacto entre sí durante el procedimiento de conmutación de conjunto de DCI. La pérdida de contacto entre el eNB y UE es potencialmente posible debido a que los formatos de DCI correspondientes en cada uno de los dos conjuntos de DCI pueden tener diferentes longitudes. Por tanto, el eNB podría estar transmitiendo un formato de DCI con una longitud, tal como DCI X del conjunto de DCI de no CIF, mientras que el UE está intentando descodificar a ciegas ese formato de DCI pero con una longitud diferente, tal como DCI X+ del conjunto de DCI de CIF. Diversos aspectos de este problema se discuten a continuación.

Cuando se indica a un UE que realice un procedimiento de RRC, incluyendo la conmutación de conjuntos de DCI, no se puede asociar tiempo de activación fijo con el procedimiento de RRC particular en LTE. Ciertos procedimientos de RRC tienen requisitos de retraso de procesamiento, ya que se puede esperar que el UE complete un procedimiento particular dentro de un cierto período de tiempo como se mide desde el momento en que el UE recibe con éxito la orden de RRC que inicia ese procedimiento. Sin embargo, el momento exacto en que el UE aplica una configuración de recursos de radio puede ser desconocida en el eNB. Por tanto, existe una ventana de incertidumbre durante la cual el eNB podría no estar seguro en cuanto a la configuración actual del UE.

Por estas razones, un eNB podría no estar completamente seguro de que un UE haya realizado un procedimiento de RRC indicado hasta que el eNB reciba de vuelta un mensaje de RRC del UE que reconoce una compleción con éxito del procedimiento. El eNB puede suponer que el UE ha recibido con éxito la orden de RRC que inicia el procedimiento cuando se recibe un HARQ ACK para el bloque de transporte de capa física que contiene la orden de RRC del UE. Sin embargo, hay una probabilidad pequeña pero no cero de que el Ue pueda señalar un HARQ NACK, pero el eNB descodifica esta señal como un ACK. Este tipo de error se puede referir como un error de NACK a ACK.

En una situación tal, el eNB puede comportarse como si el UE hubiera recibido la orden de RRC cuando de hecho el UE no lo ha hecho. Debido a que el eNB ha recibido incorrectamente un HARQ ACK para el bloque de transporte que contiene la orden de RRC, el eNB no puede, y en algunos casos nunca, realizar alguna retransmisión de HARq adicional de ese bloque de transporte. En algún momento después, cuando el eNB espera recibir el mensaje de reconocimiento de RRC desde el UE pero no lo hace, el eNB puede darse cuenta de que el UE de hecho nunca recibió la orden de RRC original. Este período de tiempo durante el cual el eNB es inconsciente del error puede ser igual a al menos la suma del retraso de procesamiento del procedimiento de RRC, como se describe anteriormente, y el tiempo usado para realizar una transmisión de enlace ascendente. Este último período de tiempo puede prolongarse además si las retransmisiones de HARQ de enlace ascendente, o incluso retransmisiones de RLC ARQ en el peor de los casos, son necesarias o deseables.

Se espera que los errores de NACK a ACK sean relativamente raros. Sin embargo, en un despliegue de red completo con muchos eNB y un número aún mayor de UEs, incluso una pequeña probabilidad individual de que ocurra este error puede dar como resultado en que ocurra un gran número total de errores de NACK a ACK. Un método alternativo para obtener un reconocimiento fiable para la transmisión de datos es a través del uso de un AM RLC ACK de la RLC SDU (PDCP PDU) que contiene la orden de RRC. Sin embargo, este ACK también puede retrasarse dado que la entidad de AM RLC receptora no puede expedir un informe de ESTADO inmediato, que proporciona información de ARQ ACK/NACK. Adicionalmente, la MAC PDU que contiene un informe de ESTADO tal también puede estar sujeta a retransmisiones de HARQ de enlace ascendente, y de esa manera provocar retraso adicional.

Como se describe en el párrafo precedente, cuando un eNB indica a un UE que conmute conjuntos de DCI, el eNB puede no estar completamente seguro de que el UE haya recibido y/o llevado a cabo realmente la orden de RRC para realizar la conmutación hasta que el eNB reciba el mensaje de reconocimiento de RRC correspondiente de vuelta del UE. El UE transmite este reconocimiento de RRC en el enlace ascendente, lo que puede necesitar recibir una concesión de enlace ascendente, es decir DCI 0, en el PDCCH desde el eNB. Sin embargo, si el UE debe conmutar conjuntos de DCI, tal como de usar DCI 0 a DCI 0+, y el eNB no puede estar seguro de que se haya realizado esta acción hasta que el eNB reciba el mensaje de reconocimiento de RRC, entonces surge una pregunta en cuanto a si el eNB debe usar una DCI 0 o DCI 0+ en el PDCCH para enviar una concesión de enlace ascendente al UE de tal manera que el UE pueda transmitir este mensaje de reconocimiento de RRC.

Al conmutar de un conjunto de DCI a otro conjunto de DCI, también hay un problema potencial de ambigüedad de longitud de DCI en ciertos casos. Por ejemplo, el UE puede estar en un modo de transmisión donde el UE está buscando DCIs "X" y "Y" de asignación de recursos de enlace descendente en el PDCCH. DCI X podría ser DCI 1A y DCI Y podría ser la DCI específica asociada con el modo de transmisión actualmente configurado. Si el UE se conmuta del conjunto de DCI de no CIF al conjunto de DCI de CIF, entonces posiblemente DCI X y DCI Y+, o DCI Y y DCI X+, pueden tener las mismas longitudes. Debido a que el UE puede ser inconsciente de exactamente cuándo el eNB conmuta de transmitir el conjunto de DCI de no CIF a transmitir el conjunto de DCI de CIF en el PDCCH, si el UE descodifica a ciegas con éxito un candidato de PDCCH, el UE no podrá determinar de manera inequívoca si ese candidato de PDCCH corresponde a DCI X o DCI Y+, o alternativamente, a DCI Y o DCI X+. Se pueden derivar ejemplos específicos de tales escenarios al hacer referencia a las longitudes de formato de DCI enumeradas en la Tabla 1 a Tabla 4, que se muestran anteriormente.

En un ejemplo ilustrativo, suponer que un UE está configurado en modo de transmisión 5, que usa DCI 1D, o modo de transmisión 6, que usa ^d C ⁱ 1B. DCIs 1B y 1D tienen la misma longitud para un ancho de banda dado y número de antenas de Tx en el eNB, por lo que este ejemplo se aplica igualmente bien a ambos formatos de DCI. Con dos antenas de Tx en el eNB, DCIs 1B y 1D tienen una longitud de 28, 29, o 30 bits, respectivamente, para anchos de banda de 10 MHz, 15 MHz, y 20 ^m H^z . El formato de DCI 1A, que también debe buscarse, tiene una longitud de 25, 27, o 28 bits, para los mismos tres anchos de banda. Suponer que un campo de CIF de 1 bit (10 MHz) o 2 bits (15 y 20 MHz) entonces se añadió a estos formatos de DCI. Entonces, DCI 1A+ tendría una longitud de 28, 29, o 30 bits, para los tres anchos de banda dados. En este caso, estas longitudes son idénticas a las longitudes de DCI 1B/1D, por lo que el UE no podría distinguir entre DCI 1A+ y DCI 1B/1D simplemente mediante descodificación a ciegas.

De manera similar, cuando están presentes cuatro antenas de Tx en el eNB y se usa una portadora de 10 MHz, las DCI 1B/1D tienen una longitud de 30 bits, mientras que DCI 1A tiene una longitud de 27 bits. Si se usa un campo de CIF de 3 bits, entonces DCI 1A+ tendría la misma longitud (27+3=30) como las DCI 1B/1D.

Este problema de ambigüedad de longitud de DCI también puede existir para las situaciones donde las portadoras de diferentes anchos de banda comparten el mismo PDCCH y/o donde las portadoras diferentes pueden configurarse en diferentes modos de transmisión. Este problema puede ser exacerbado por portadoras que están en frecuencias ampliamente separadas dado que tales portadoras pueden exhibir diferentes características de propagación inalámbrica y por lo tanto puede ser más probable que estén configuradas en diferentes modos de transmisión que las portadoras que están estrechamente separadas en frecuencia.

El problema de conmutar conjuntos de DCI mientras que se asegura que las comunicaciones de PDCCH entre el eNB y Ue no se pierdan tiene algunas similitudes con el procedimiento existente de reconfigurar un UE para usar un modo de transmisión diferente. En general, un UE puede configurarse para operar en uno de varios posibles modos de transmisión. Para cada modo de transmisión, se puede esperar que el UE busque DCI 0/1A, que tienen la misma longitud, y uno de DCIs 1, 1B, 1D, 2, y 2A, dependiendo del modo de transmisión actual. Cuando se "indica" un cambio de modo de transmisión, como un procedimiento de RRC, hay una ventana de incertidumbre entre el eNB que transmite la orden de RRC y el eNB que recibe el reconocimiento de RRC. Esta incertidumbre se describe más arriba. Durante esta ventana de incertidumbre, el eNB puede no estar seguro de cuál de los dos, ya sea el antiguo o el nuevo, modos de transmisión el UE está operando actualmente.

Una solución a este problema puede ser intentar asegurar que el UE siempre pueda buscar DCI 1A en cada modo de transmisión. Entonces un eNB puede usar DCI 1A para enviar asignaciones de recursos de enlace descendente al UE hasta que el mensaje de reconocimiento de RRC se reciba de vuelta desde el UE. El eNB puede entonces conmutar, si se desea, a usar la DCI particular asociada con el modo de transmisión actual, es decir DCI 1, 1B, 1D, 2, o 2A. De manera similar, el UE siempre puede buscar una DCI 0 en el PDCCH independientemente del modo de transmisión configurado actualmente. De esta manera, el eNB puede ser capaz de enviar, y en algunas realizaciones siempre es capaz de enviar, las concesiones de enlace ascendente al UE.

Sin embargo, una conmutación del conjunto de DCI de no CIF a un conjunto de DCI de CIF, o viceversa, o entre conjuntos de DCI de CIF con campos de CIF de diferente longitud, puede dar como resultado en que se usen DCIs de diferentes longitudes, tales como 1A y 1A+, en el PDCCH. No hay DCI similar a DCI 1A que pueda recibirse en todos los modos posibles de agregación de portadora, por ejemplo con longitudes de campo de CIF de 0, 1,2, o 3 bits.

Una conmutación del conjunto de DCI de no CIF a un conjunto de DCI de CIF, o viceversa, o entre conjuntos de DCI de CIF con campos de CIF de diferente longitud, puede probablemente dar como resultado en un cambio en longitud de DCI 0 ya que un campo de CIF es ya sea añadido o eliminado. Por esta razón, existe un riesgo definido de que el eNB no pueda proporcionar concesiones de enlace ascendente decodificables al UE. Conmutar modos de transmisión como se describe anteriormente puede no dar como resultado en un cambio de longitud de DCI 0, y en algunos casos nunca dará como resultado en un cambio de longitud tal. Por tanto, el eNB siempre podrá continuar proporcionando concesiones de enlace ascendente al UE incluso si el eNB no está seguro en cuanto a cual modo de transmisión está actualmente el UE, y en algunos casos siempre podrá continuar proporcionando tales concesiones de enlace ascendente.

Como se menciona anteriormente, un conjunto de DCI se refiere ya sea al conjunto de DCIs de no CIF, tal como DCIs de Versión 8, o a un conjunto de DCIs de CIF. Pueden existir múltiples conjuntos de DCI de CIF con campos de CIF de diferente longitud. Un campo de CIF puede tener una longitud de 1 a 3 bits, posiblemente más.

Al construir una DCI de CIF a partir de la DCI de no CIF correspondiente, tal como DCI 1A+ de DCI 1A, podría ser necesario incluir un campo de CIF en algún lugar dentro de la carga útil de bit de información de la DCI. Este campo de CIF se puede añadir al comienzo de los bits de información, siguiendo todos los bits de información existentes, o posiblemente incluso en algún lugar en el medio de los campos existentes.

Cuando la carga útil de bit de información de un formato de DCI de Versión 8 tiene una longitud de bit ambigua, entonces se puede anexar un bit de relleno adicional con un valor de 0, y en algunos casos siempre se anexa, a la carga útil de bit de información. Los tamaños de longitud de bit ambiguo incluyen 12, 14, 16, 20, 24, 26, 32, 40, 44, y 56. Además, si el valor de carga útil más cualquier bit de relleno de una DCI 1 de Versión 8 es igual al de DCI 1A para el mismo ancho de banda, entonces se puede añadir un bit de relleno cero adicional, y en algunos casos siempre se añade, a DCI 1 de tal manera que DCI 1 y 1A no tengan la misma longitud.

Las realizaciones descritas aquí cada una aborda uno o más de los problemas descritos anteriormente. Las siguientes realizaciones pueden considerarse al definir los formatos exactos de los nuevos DCI de CIF, especialmente cuando se incluyen bits de relleno que resultan de aplicación de las reglas descritas anteriormente.

La figura 4 es un diagrama que ilustra la adición de un campo de CIF a una DCI de Versión 8 mientras que se retiene cualquier bit de relleno existente. Todos los formatos 400 de DCI se refieren al mismo formato de DCI que se modifica con el tiempo. El formato 402 de DCI muestra el formato de DCI original con uno o más bits 403 de relleno. Estos bits 403 de relleno no necesitan estar presentes. El formato 404 de DCI muestra el mismo formato de DCI como formato 402 de DCI, con la adición de un CIF 405.

Los bits de relleno existentes se pueden retener, y se añaden al campo de CIF. El campo de CIF no necesariamente necesita añadirse al final de la carga útil. El formato 406 de DCI muestra el mismo formato de DCI como formato 404 de DCI, con la adición de uno o más bits 407 de relleno adicionales. Estos bits 407 de relleno adicionales se pueden añadir con el fin de evitar longitudes de carga útil total ambiguas. Para ciertos anchos de banda, longitudes de campo de CIF, formatos de DCI, y los bits 407 de relleno adicionales podrían no ser necesarios o deseables.

En una realización, añadir un campo de CIF a una DCI de Versión 8 puede aumentar la longitud de la DCI resultante. La carga útil de DCI de Versión 8 existente de longitud M se retiene originalmente, más cualquier bit de relleno que se añade. Se puede incluir un campo de CIF de longitud N en la carga útil. Si la longitud resultante (M+N) corresponde a uno de los tamaños de carga útil ambiguos enumerados anteriormente, entonces se puede incluir un bit de relleno adicional. Además, si la longitud resultante de DCI 1+ es igual a la de DCI 1A+, entonces se pueden incluir bits de relleno adicionales en DCI 1+ hasta que la longitud total no sea igual a la de DCI 1A+ y su longitud no pertenezca al conjunto de tamaños ambiguos, tal como los enumerados anteriormente. Un ejemplo de este procedimiento que usa DCI 1A se ilustra en la figura 4.

La figura 5 es un diagrama que ilustra la adición de un campo de CIF a una DCI de Versión 8 mientras que se extrae cualquier bit de relleno existente, de acuerdo con una realización de la divulgación. Todos los formatos 500 de DCI se refieren al mismo formato de DCI que se modifica con el tiempo. El formato 502 de DCI muestra el formato de DCI original con uno o más bits 503 de relleno. No es necesario que estos bits 503 de relleno estén presentes. El formato 504 de DCI muestra el mismo formato de DCI como formato 502 de DCI, después de extraer los bits 503 de relleno. El formato 506 de DCI muestra el mismo formato de DCI como formato 504 de DCI, pero con la adición de un CIF 507. El formato 508 de DCI muestra el mismo formato de DCI como formato 506 de DCI, pero con la adición de uno o más bits 509 de relleno adicionales.

Notar que el formato 1A de DCI de Versión 8 puede incluir o no uno o más bits 503 de relleno. Sin embargo, si están presentes, entonces los bits 503 de relleno pueden extraerse, como en formato 504 de DCI. Entonces se añade un campo de CIF (507), pero podría no estar necesariamente al final de la carga útil como se muestra. Para el formato 508 de DCI, se pueden añadir bit o bits (509) de relleno extras con el fin evitar longitudes de carga útil totales ambiguas. Para ciertos anchos de banda, longitudes de campo de CIF, y formatos de DCI, esta etapa podría no ser necesaria o deseable.

De este modo, en esta realización, se extrae cualquier bit de relleno que se añadió a la carga útil de DCI de Versión 8 existente de longitud M. Puede haber "P" de tales bits de relleno, donde P podría ser cero. Se puede incluir un campo de CIF de longitud N en la carga útil. Si la longitud resultante (M-P+N) corresponde a uno de los tamaños de carga útil ambigua, tal como los enumerados anteriormente, entonces se puede incluir un bit de relleno adicional. Además, si la longitud resultante de DCI 1+ es igual a la de DCI 1A+, entonces se pueden incluir bits de relleno adicionales en DCI 1+ hasta que su longitud no sea igual a la de DCI 1A+ y su longitud no pertenezca al conjunto de tamaños ambiguos enumerados anteriormente. Un ejemplo de este procedimiento que usa DCI 1A se ilustra en la figura 5.

Conmutación de conjunto de DCI

Como se presentó anteriormente, el concepto de usar diferentes conjuntos de DCI para diferentes configuraciones de múltiportadoras puede ser necesario o deseable si se debe añadir un campo de CIF a los formatos de DCI existentes. Por esta razón, definir un procedimiento para conmutar entre diferentes conjuntos de DCI puede ser deseable o necesario.

De nuevo, la conmutación de conjunto de DCI se refiere al procedimiento de conmutar de usar un conjunto de DCI, referido como el antiguo conjunto de DCI, a usar otro conjunto de DCI, referido como el nuevo conjunto de DCI. Este procedimiento puede incluir una conmutación que involucre cualquiera de los siguientes.

La conmutación de conjunto de DCI puede incluir conmutar de DCIs de no CIF a DCIs de CIF. Un ejemplo de este tipo de conmutación puede ocurrir durante la activación de múltiportadoras o la configuración de un subconjunto de portadoras activas como portadoras de monitorización de PDCCH.

La conmutación de conjunto de DCI puede incluir conmutar de DCIs de CIF a DCIs de no CIF. Un ejemplo de este tipo de conmutación puede ocurrir durante la desactivación de múltiportadoras o la configuración de todas las portadoras activas como portadoras de monitorización de PDCCH.

La conmutación de conjunto de DCI puede incluir conmutar de DCIs de CIF con un campo de DCI de cierta longitud a DCIs de CIF con un campo de DCI de diferente longitud. Un ejemplo de este tipo de conmutación puede ocurrir durante la reconfiguración de múltiportadoras, donde se cambia la longitud del campo de CIF.

Una realización específica del formato general esperado de este procedimiento para conmutar conjuntos de DCI se puede describir a través de las siguientes etapas. Estas etapas también ilustran la entrada de red para un UE capaz de soportar múltiples portadoras.

Primera, un UE capaz de soportar múltiples portadoras (por ejemplo Versión 10) realiza entrada de red como un UE de Versión 8. El eNB usa DCIs de no CIF para enviar información de PDCCH al UE. Segunda, un UE de múltiportadoras puede señalar sus capacidades de múltiportadoras al eNB a través del procedimiento de intercambio de capacidad de UE. Tercera, el eNB puede reconfigurar el UE para la operación de múltiportadoras. La reconfiguración puede incluir el uso de DCIs de CIF en el PDCCH como señalización de control dedicada a ese UE. La señalización de PDCCH de emisión tal como información de sistema, SI-RNTI, y paginación, P-RNTI, puede continuar usando DCIs de no CIF.

Especificar un tiempo de activación

En otra realización para realizar conmutación de conjunto de DCI, la orden de RRC que ordena una conmutación en conjuntos de DCI también podría incluir un tiempo de activación. El tiempo de activación podría ser en la forma de un SFN y desplazamiento de submarco dentro de ese marco de radio. El tiempo de activación especificado puede ser suficientemente lejano en el futuro que habría tiempo suficiente para que el UE reciba la orden de RRC y entonces transmita un reconocimiento de RRC de vuelta al eNB. El eNB tendría de este modo un claro reconocimiento de que el UE también conmutaría conjuntos de DCI antes de que esté programada para ocurrir la conmutación. El eNB y UE entonces realizarían una conmutación coordinada en conjuntos de DCI al mismo tiempo. Esta acción eliminaría la ventana de incertidumbre donde el UE y eNB pueden no estar seguros de cual conjunto de DCI está usando la otra entidad.

Si el eNB no recibió un reconocimiento de RRC de vuelta del UE o no recibió un ARQ ACK de la entidad de AM RLC asociada con el SRB1 de plano de control que transporta el tráfico de RRC, el eNB se daría cuenta de que el UE no había recibido la orden de RRC original. El UE podría no haber recibido la orden de RRC original debido a, quizás, a un error de NACK a ACK. En una situación tal, el eNB no conmutaría conjuntos de DCI, sino que en vez reenviaría la orden de RRC con un nuevo tiempo de activación.

Un problema potencial de esta metodología es que podría no permitir que el UE realice la conmutación de conjunto de DCI en la configuración de múltiportadoras lo antes posible. Puede haber diversos retrasos en transmitir la orden de RRC y/o reconocimiento de RRC. Estos retrasos pueden resultar, por ejemplo, debido a retransmisiones de HARQ de enlace descendente y/o HARQ de enlace ascendente. Por tanto, el tiempo de activación puede establecerse suficientemente lejos en el futuro para tener en cuenta el retraso adicional potencialmente introducido por posibles retransmisiones de HARQ de enlace descendente y/o de enlace ascendente. Establecer el tiempo de esta manera reduce la flexibilidad y capacidad de respuesta dinámica del sistema.

eNB no asigna recursos al UE durante ventana de incertidumbre

En otra realización para realizar conmutación de conjunto de DCI, el eNB podría no asignar recursos al UE, a través del PDCCH, durante la ventana de incertidumbre descrita anteriormente. Debido a que hay una ventana de incertidumbre durante la cual el eNB puede no estar seguro de cual conjunto de DCI está usando actualmente el UE, el eNB podría simplemente evitar enviar cualquier transmisión de enlace descendente o concesiones de enlace ascendente al UE durante este período de incertidumbre. La única excepción podría ser para retransmisiones de HARQ de enlace descendente del bloque de transporte que contiene la orden de RRC, si tales retransmisiones son necesarias. Al "suspender" temporalmente contacto, no habría peligro en el eNB que envía comunicaciones de PDCCH que el UE no podría descodificar a ciegas.

Esta metodología, sin embargo, tiene unos pocos problemas. La longitud de la ventana de incertidumbre podría extenderse si se requieren o desean retransmisiones de HARQ de enlace descendente y/o de enlace ascendente. Durante este tiempo, todo el tráfico de enlace descendente y enlace ascendente podría bloquearse, lo que tendría un impacto temporal en el rendimiento hacia/desde el UE. Adicionalmente, si hay mensajes importantes para ser suministrados al UE inmediatamente, tal como señalización relacionada con movilidad, esta solución puede incurrir en retraso adicional no deseado. Otro problema clave es que el eNB todavía podría tener un problema en enviar una concesión de enlace ascendente al UE de tal manera que el UE pueda transmitir el reconocimiento de RRC. Si, de hecho, el UE no realizó la conmutación de conjunto de DCI, tal como en el caso de un error de NACK a ACK, entonces el eNB podría enviar al UE una DCI 0+, mientras que el UE estaría buscando una DCI 0 (con una longitud diferente) en el PDCCH. Esta situación supone una conmutación del conjunto de DCI de no CIF a un conjunto de DCI de CIF. Sin embargo, este problema podría abordarse a través de la solución que se describe inmediatamente a continuación.

eNB transmite DCIs desde ambos conjuntos de DCI durante ventana de incertidumbre

En otra realización para realizar conmutación de conjunto de DCI, durante la ventana de incertidumbre, el eNB podría transmitir DCIs desde ambos conjuntos de DCI al ^u E. Estos pares de DCI pueden referirse a los mismos recursos de enlace descendente o concesión de enlace ascendente. Por ejemplo, si el eNB estaba realizando una transmisión de enlace descendente, podría incluir tanto una DCI 1A como DCI 1A+ en el PDCCH para un submarco dado. Ambos formatos de DCI pueden apuntar ambos a los mismos recursos de enlace descendente en el PDSCH. De manera similar, para una concesión de enlace ascendente, el eNB puede incluir tanto una DCI 0 como DCI 0+, con ambos formatos de DCI que se refieren a los mismos recursos de enlace ascendente en el PUSCH. En este caso, no importa cual conjunto de DCI esté usando actualmente el UE, debido a que las DCI de ambos conjuntos estarían presentes en el PDCCH.

Un beneficio de usar esta metodología es que el número de descodificaciones a ciegas que el UE debe realizar en el PDCCH no aumenta. Adicionalmente, el tráfico hacia y/o desde el UE no se bloquea durante la ventana de incertidumbre, como podría ser el caso de la solución descrita anteriormente.

Sin embargo, la transmisión desde ambos conjuntos de DCI podría aumentar la probabilidad de bloqueo en el PDCCH, debido a que el eNB podría ahora tener que encontrar espacio adicional en el PDCCH para ambas DCI. Esta probabilidad de bloqueo aumentada podría dar como resultado en uso ineficiente de los recursos de PDSCH y/o PUSCH dentro de la celda debido al bloqueo de PDCCH. Adicionalmente, existe una posibilidad de confusión entre longitudes de DCI ambiguas como se describe anteriormente. Las soluciones potenciales a este último problema se describen a continuación con respecto a las realizaciones de especificar cual DCI se debe usar cuando están presentes longitudes de DCI ambiguas, y conmutar al modo de transmisión no ambiguo antes de conmutar conjuntos de DCI.

Si se usara la técnica de evitar asignación de recursos al UE durante la ventana de incertidumbre de conmutación de conjunto de DCI, como se describe anteriormente, el eNB entonces podría usar la técnica de enviar ambos conjuntos de DCI para enviar tanto una DCI 0 como DCI 0+ al UE cuando el eNB desea proporcionar una concesión de enlace ascendente para que el UE transmita el reconocimiento de RRC. Esta técnica puede asegurar que el UE pudo recibir la concesión de enlace ascendente, independientemente del conjunto de DCI que el UE estaba usando actualmente. Al transmitir solo DCIs emparejados desde ambos conjuntos de DCI de esta manera limitada, es decir solo para proporcionar la concesión de enlace ascendente para el reconocimiento de RRC, se puede minimizar el impacto potencial en el bloqueo de PDCCH.

En vista de este hecho, se puede usar una solución híbrida al combinar las técnicas para evitar asignación de recursos durante la ventana de incertidumbre y enviar pares de conjuntos de DCI. Es decir, durante el tiempo transitorio, el eNB puede intentar bloquear temporalmente tantas transmisiones de enlace ascendente y enlace descendente como sea posible. En el caso de que se deba hacer cualquier transmisión, el eNB puede transmitir DCIs de ambos conjuntos de DCI al UE.

En otra realización, la técnica de especificar un tiempo de activación se puede combinar con esta técnica de transmitir ambos conjuntos de DCI durante la ventana de incertidumbre. En este caso, el eNB solo puede enviar ambos conjuntos de DCI al UE después del tiempo de activación si el eNB no recibe el mensaje de reconocimiento de RRC, o retroalimentación de AM RLC, del UE antes del tiempo de activación. De esta forma, el tiempo de activación se puede establecer para una duración más corta. Si el UE no ha recibido y procesado la orden de RRC antes del tiempo de activación, el UE aún podría aún ser capaz de descodificar el antiguo conjunto de DCI.

Nuevo formato de DCI

En otra realización para realizar conmutación de conjunto de DCI, se podría definir un nuevo formato de DCI que el UE buscaría en el PDCCH, independientemente de la configuración de múltiportadoras actual del UE. Esta técnica podría usarse con el fin de reducir la probabilidad de que el eNB y UE pierdan contacto entre sí, independientemente de cual conjunto de DCI está usando cada entidad. Esta técnica sería una idea similar a una DCI 1A que el UE busca en todos los modos de transmisión, como se describe anteriormente con respecto a conjuntos de DCI y conmutación de conjunto de DCI.

Sin embargo, esta realización podría aumentar el número de descodificaciones a ciegas que tendría que realizar un UE capaz de múltiportadoras. Aumentar el número de descodificaciones a ciegas puede aumentar indeseablemente el procesamiento y consumo de potencia en el UE. El diseño de DCI 1A se optimizó ya que DCI 1A tiene la misma longitud como DCI 0 y DCI 3/3A, que el UE también debe buscar, y por tanto el UE puede buscar todos estos formatos de DCI a través de una única descodificación a ciegas en un candidato de PDCCH particular. Sin embargo, buscar todos los formatos de DCI a través de única descodificación a ciegas podría no ser posible si se introduce aún otro formato de DCI.

En una realización, el nuevo formato de DCI podría tener una longitud fija independientemente del número de portadoras activadas. De este modo, el nuevo formato de DCI podría no incluir un campo de CIF o podría incluir un campo de CIF con una longitud fija igual al tamaño de CIF máximo posible (por ejemplo 3 bits). Adicionalmente, las longitudes de los formatos de DCI existentes puede variar basadas en la longitud de cualquier campo de CIF que se incluyó.

Además de un nuevo formato de DCI, se podría definir una nueva DCI de una manera tal que la longitud de DCI fuera diferente de todos los otros formatos de DCI posibles, incluyendo las DCI tanto con y sin un campo de CIF. Esta nueva DCI permitiría al UE identificar de manera inequívoca esa DCI a través de la descodificación a ciegas. Sin embargo, puede ser difícil encontrar una nueva longitud que no "colisione" con ninguna de las posibles longitudes de DCI existentes.

En una realización relacionada, se podría requerir que el UE busque siempre DCI 1A, sin campo de CIF, y DCI 0, que tendría la misma longitud, independientemente de si se habilitó o no la agregación de portadora. Si se encuentra, se supondría que la DCI 1A o DCI 0 se refiere a la portadora de anclaje o a la portadora que contiene el PDCCH. Por tanto, un campo de CIF podría no ser requerido. Sin embargo, esta realización podría dar como resultado en que el UE tenga que realizar un mayor número de descodificaciones a ciegas, debido a que esta técnica podría añadir una longitud de DCI adicional más que tendría que buscar el UE.

Descodificación a ciegas de conjunto de DCI doble en el UE / negociación de dos vías

La figura 6 es un diagrama que ilustra un procedimiento de negociación de dos vías para conmutar DCI, de acuerdo con una realización de la divulgación. En esta realización, como se muestra en la figura 6, el antiguo conjunto de DCI se refiere al conjunto de DCI que está siendo usado antes de una conmutación de conjunto de DCI, mientras que el nuevo conjunto de DCI se refiere al conjunto de DCI que se debe usar después de la conmutación de conjunto de DCI. Los conjuntos 600 de DCI en relación tanto con el eNB como el UE se presentan en la figura 6.

Después de que un eNB envía una orden de RRC que ordena una conmutación de conjunto de DCI al UE, el eNB puede continuar usando el antiguo conjunto de DCI. Cuando un UE recibe una orden de RRC que ordena una conmutación de conjunto de DCI, el UE puede comenzar temporalmente a monitorizar ambos conjuntos de DCI en el PDCCH. Cuando el eNB desea que el UE transmita el mensaje de reconocimiento de RRC, el eNB puede enviar una concesión de enlace ascendente, DCI 0, al UE. Después de que el eNB ha recibido con éxito el reconocimiento de RRC, el eNB sabe que el UE está monitorizando ambos conjuntos de DCI, y entonces puede conmutar al nuevo conjunto de DCI. El UE puede dejar de monitorizar el antiguo conjunto de DCI cuando se cumple una de las siguientes condiciones.

Una condición puede ser que el eNB envíe una orden de RRC adicional que indique al UE para que deje de monitorizar el antiguo conjunto de ^d Cⁱ . Otra condición puede ser que el UE haya recibido un número específico de DCIs que pertenecen de manera inequívoca al nuevo conjunto de DCI. Este número podría especificarse ya sea como una cantidad fija en el estándar o ser configurable. El número puede ser configurable a través de señalización de RRC. El número incluso podría incluirse como un parámetro en la orden de RRC que originalmente ordenó la conmutación de conjunto de DCI. Puede ser deseable usar un valor mayor que 1 con el fin de proteger contra las falsas detecciones positivas de DCIs en el PDCCH que accidentalmente desencadenan esta condición prematuramente.

La metodología descrita con respecto a la figura 6 puede considerarse un procedimiento de negociación de dos vías, con la segunda negociación siendo ya sea explícita (la primera de las dos condiciones anteriores) o implícita (la segunda de las dos condiciones anteriores). La primera negociación puede ocurrir mediante la señalización de UE que ahora está monitorizando ambos conjuntos de DCI de tal manera que el eNB ahora puede conmutar a usar el nuevo conjunto de DCI. La segunda negociación puede ocurrir cuando el eNB señala, ya sea de manera explícita o implícitamente, que ya no está transmitiendo el antiguo conjunto de DCI de tal manera que el UE puede dejar de monitorizar ese conjunto de DCI.

Esta realización tiene un número de beneficios. Es probable que el procedimiento de negociación de dos vías no bloquee el tráfico de enlace descendente/enlace ascendente hacia/desde el UE, como podría la realización descrita con respecto al eNB que evita asignar recursos durante la ventana de incertidumbre. El procedimiento de negociación de dos vías tampoco aumenta la probabilidad de bloqueo en el PDCCH, como podría la realización descrita con respecto al eNB que transmite DCIs desde ambos conjuntos de DCI durante la ventana de incertidumbre. El procedimiento de negociación de dos vías también puede ayudar a asegurar que el eNB y UE no pierdan contacto accidentalmente entre ellos debido a un error de NAC^k a ACK en el bloque de transporte de capa física que contiene la orden de RRC que ordena la conmutación de conjunto de DCI.

Sin embargo, algunas descodificaciones a ciegas adicionales, y por tanto procesamiento adicional, podrían ser usadas por el UE durante el proceso de negociación involucrado con conmutar conjuntos de DCI. Sin embargo, este procesamiento adicional sería solo de una forma temporal. Por tanto, el procesamiento adicional puede no dar como resultado en consumo incremental de potencia significativo, especialmente si las reconfiguraciones de modo de múltiportadoras no ocurren de manera frecuente.

Cuando el UE está monitorizando dos conjuntos de DCI, hay una posibilidad de que ciertos formatos de DCI en ambos de los conjuntos de DCI puedan tener la misma longitud. En este caso, el UE podría no saber cual DCI fue prevista en el caso de una descodificación a ciegas exitosa en el PDCCH. Por ejemplo, DCI X y DCI Y+ pueden tener la misma longitud, por lo que el UE no podría diferenciar de manera inequívoca entre estos dos formatos de DCI durante el período de tiempo donde el UE está monitorizando ambos conjuntos de DCI. Esta situación puede beneficiarse del uso de una de las soluciones descritas con respecto a las realizaciones de especificar cual DCI se debe usar cuando estén presentes longitudes de DCI ambiguas o conmutar a modo de transmisión no ambiguo antes de conmutar conjuntos de DCI, como se describe a continuación.

Especificar cual DCI se debe usar cuando estén presentes longitudes de DCI ambiguas

En otra realización útil para realizar la conmutación de conjunto de DCI, se puede hacer una determinación o selección con respecto a cual DCI se debe usar cuando estén presentes longitudes de DCI ambiguas. Cuando existe una posibilidad de longitudes de DCI ambiguas durante una conmutación de conjunto de DCI, tal como cuando DCI X y DCI Y+ tienen las mismas longitudes como las descritas anteriormente, se puede hacer una determinación o selección con respecto a cual formato de DCI se debe evitar o suponer que no está presente. El siguiente párrafo proporciona un ejemplo ilustrativo de esta realización.

Suponer que hay dos antenas de Tx en el eNB, todas las portadoras múltiples tienen un ancho de banda de 20 MHz, y el UE está configurado actualmente para el modo de transmisión 5. Si el UE está usando actualmente el conjunto de DCI de no CIF, entonces el UE podría estar buscando DCI 1A (28 bits) y DCI 1D (30 bits) en el PDCCH. Si el UE se reconfigura para operación de múltiportadoras con un campo de CIF de 2 bits, entonces DCI 1A+ tendrá una longitud de 30 bits y DCI 1 D+ tendrá una longitud de 33 bits. Se puede añadir un bit de relleno adicional a DCI 1D+ debido a que 32 bits pueden no ser una longitud permitida. De este modo habría una ambigüedad potencial de descodificación a ciegas entre DCI 1D y DCI 1A+, debido a que ambos tendrían una longitud de 30 bits.

En una situación tal, podría ser requerido que el eNB no use DCI 1A+ hasta que el eNB haya recibido el mensaje de reconocimiento de RRC de vuelta del UE. Después de que el eNB ha recibido este reconocimiento de RRC, el eNB sabe que el UE ahora está monitorizando solo el conjunto de DCI de CIF. Por consiguiente, el eNB ahora puede usar DCI 1A+ debido a que el eNB sabe que el UE ya no está buscando DCI 1D en el PDCCH. En la dirección opuesta, tal como al conmutar del conjunto de DCI de CIF al conjunto de DCI de no CIF, el eNB puede evitar usar DCI 1D hasta que el eNB reciba el mensaje de reconocimiento de RRC del UE, dado que existe la posibilidad de confusión con DCI 1A+.

De este modo, se puede hacer una especificación de que el formato de DCI no usado es el uno que pertenece al conjunto de DCI al que se supone que debe conmutar el UE (es decir el nuevo conjunto de DCI), debido a que puede haber la posibilidad de que el UE no sepa que se supone que conmute conjuntos de DCI por alguna razón, tal como la ocurrencia de un error de NACK a ACK. Esta realización puede asegurar que el eNB no envíe una DCI 1A+ que el UE pueda interpretar incorrectamente como una DCI 1D cuando el UE todavía está usando el conjunto de DCI de no CIF, por ejemplo.

Una realización alternativa relacionada podría ser que el eNB evite usar todas las DCI que pueden tener longitudes ambiguas hasta que se reciba el reconocimiento de RRC del UE. Sin embargo, esta técnica puede no ser posible. Por ejemplo, puede ser difícil para el eNB evitar usar DCIs de la misma longitud como DCI 1A o 1A+, debido a que DCI 0 y 0+ y DCIs 3/3A y 3+/3A+ también pueden tener las mismas longitudes respectivas.

Aún otra alternativa podría ser especificar bits de relleno adicionales en los casos donde puedan existir longitudes de formato de DCI ambiguas. Esta técnica puede eliminar todas o la mayoría de las ocurrencias posibles de longitudes de formato de DCI ambiguas. Esta técnica puede ser complicada, sin embargo, debido al número de longitudes de DCI que ya existen y las posibles longitudes diferentes del campo de CIF, tal como 1, 2, o 3 bits.

Conmutación a modo de transmisión no ambiguo antes de conmutar conjuntos de DCI

En otra realización útil para realizar conmutación de conjunto de DCI, se puede realizar una conmutación a un modo de transmisión no ambiguo antes de conmutar conjuntos de DCI. La posibilidad de tener longitudes de DCI ambiguas durante una conmutación de conjunto de DCI, tal como DCI X y DCI Y+ que tienen la misma longitud, puede ocurrir solo para ciertos modos de transmisión. Los ejemplos proporcionados anteriormente con respecto a los conjuntos de DCI y conmutación de conjunto de DCI podrían aplicarse solo a los modos de transmisión 5 y 6, por ejemplo. Si el UE está en un modo de transmisión potencialmente ambiguo tal, el eNB podría primero reconfigurar el UE a un modo de transmisión inequívoco "seguro" intermedio. A partir de ahí, el eNB podría indicar al UE que conmute conjuntos de DCI, y entonces finalmente reconfigure el UE de vuelta al modo de transmisión deseado. Un modo de transmisión seguro no ambiguo tal podría ser el modo de transmisión 1 (única antena de transmisión en el eNB) o modo de transmisión 2 (diversidad de transmisión desde el eNB), dependiendo del número de antenas de transmisión en el eNB.

Por ejemplo, suponer que el UE estaba en modo de portadora única y en modo de transmisión 5. Con el fin de conmutar el UE al modo de múltiportadoras, se podrían realizar las siguientes etapas.

Primera, el eNB puede enviar una orden de RRC al UE que indica al UE que conmute al modo de transmisión 2. Segunda, el UE puede enviar un reconocimiento de RRC al eNB indicando que el UE ha conmutado modos de transmisión. Tercera, el eNB puede enviar una orden de RRC al UE que indica al UE que conmute al modo de múltiportadoras, con todas las portadoras operando en el modo de transmisión 2.

Cuarta, el UE entonces puede enviar un reconocimiento de RRC al eNB indicando que el UE ha activado múltiples portadoras. Quinta, el eNB puede enviar una orden de RRC al UE que indica al UE que conmute de vuelta al modo de transmisión 5 ya sea en todas o en un subconjunto de las múltiples portadoras. Finalmente, el UE puede enviar un reconocimiento de RRC al eNB indicando que el UE ha conmutado modos de transmisión.

Esta realización podría involucrar señalar y realizar tres procedimientos de RRC consecutivos separados, en vez de solo una conmutación de conjunto de DCI. Podría resultar retraso adicional con respecto a realizar la reconfiguración general de múltiportadoras. Adicionalmente, se podría incurrir en sobrecarga de señalización adicional con respecto a enviar ordenes de RRC y reconocimientos de RRC para cada uno de los tres procedimientos de RRC.

La figura 7 es un diagrama de flujo que ilustra un método para realizar conmutación de conjunto de DCI, de acuerdo con una realización de la divulgación. El método que se muestra en la figura 7 puede implementarse ya sea en un UE o en un nodo de acceso, tal como los que se muestran en las figuras 1 hasta 3, mientras está siendo usada la agregación de portadora. El método que se muestra en la figura 7 se puede implementar usando un procesador y/u otros componentes, tales como los que se muestran en la figura 8. El método que se muestra en la figura 7 puede implementarse usando procedimientos tales como los descritos con respecto a las figuras 4 hasta 6.

El proceso comienza a medida que el procesador produce ya sea que un UE o un nodo de acceso produzca una conmutación entre un primer conjunto de información de control de enlace descendente (DCI) y un segundo conjunto de DCI mientras está siendo usada la agregación de portadora (bloque 700). El proceso termina a partir de ahí.

El UE y otros componentes descritos anteriormente pueden incluir procesamiento y otros componentes capaces de ejecutar instrucciones relacionadas con las acciones descritas anteriormente. La figura 8 ilustra un ejemplo de un sistema 800 que incluye un componente de procesamiento, tal como procesador 810, adecuado para implementar una o más realizaciones divulgadas aquí. Además del procesador 810 (que puede referirse como una unidad central de procesador central o CPU), el sistema 800 podría incluir dispositivos 820 de conectividad de red, memoria de acceso aleatorio (RAM) 830, memoria de solo lectura (ROM) 840, almacenamiento 850 secundario, y dispositivos 860 de entrada/salida (I/O). Estos componentes pueden comunicarse entre sí a través de un bus 870. En algunos casos, algunos de estos componentes pueden no estar presentes o pueden combinarse en diversas combinaciones entre sí o con otros componentes que no se muestran. Estos componentes pueden estar ubicados en una única entidad física o en más de una entidad física. Cualquier acción descrita aquí como que es llevada por el procesador 810 puede ser llevada por el procesador 810 solo o por el procesador 810 en conjunto con uno o más componentes que se muestran o no se muestran en el dibujo, tal como un procesador de señal digital (DSP) 880. Aunque el DSP 880 se muestra como un componente separado, el DSP 880 podría incorporarse en el procesador 810.

El procesador 810 ejecuta instrucciones, códigos, programas informáticos, o secuencias de comandos a los que puede acceder desde los dispositivos 820 de conectividad de red, RAM 830, ROM 840, o almacenamiento 850 secundario (que pueden incluir diversos sistemas basados en disco tales como disco duro, disco flexible, o disco óptico). Aunque solo se muestra una CPU 810, pueden estar presentes múltiples procesadores. De este modo, mientras que las instrucciones pueden ser discutidas como ejecutadas por un procesador, las instrucciones pueden ejecutarse simultáneamente, en serie, o de otra manera por uno o múltiples procesadores. El procesador 810 puede implementarse como uno o más chips de CPU.

Los dispositivos 820 de conectividad de red pueden tomar la forma de módems, bancos de módems, dispositivos Ethernet, dispositivos de interfaz de bus de serie universal (USB), interfaces seriales, dispositivos de contraseña en anillo, dispositivos de interfaz de datos de fibra distribuida (FDDI), dispositivos de red de área local inalámbrica (WLAN), dispositivos de transceptor de radio tales como dispositivos de acceso múltiple por división de código (CDMA), dispositivos de transceptor de radio de sistema global para comunicaciones móviles (GSM), dispositivos de interoperabilidad mundial para acceso por microondas (Wím Ax ), y/u otros dispositivos bien conocidos para conectarse a redes. Estos dispositivos 820 de conectividad de red pueden permitir que el procesador 810 se comunique con Internet o con una o más redes de telecomunicaciones u otras redes desde las cuales el procesador 810 podría recibir información o hacia las cuales el procesador 810 podría generar información. Los dispositivos 820 de conectividad de red también pueden incluir uno o más componentes 825 de transceptor capaces de transmitir y/o recibir datos de manera inalámbrica.

La RAM 830 se podría usar para almacenar datos volátiles y quizás para almacenar instrucciones que son ejecutadas por el procesador 810. La ROM 840 es un dispositivo de memoria no volátil que típicamente tiene una capacidad de memoria más pequeña que la capacidad de memoria del almacenamiento 850 secundario. La ROM 840 se podría usar para almacenar instrucciones y quizás datos que se leen durante la ejecución de las instrucciones. El acceso tanto a RAM 830 como a ROM 840 típicamente es más rápido que el almacenamiento 850 secundario. El almacenamiento 850 secundario típicamente está compuesto por una o más unidades de disco o unidades de cinta y se podría usar para el almacenamiento no volátil de datos o como un dispositivo de almacenamiento de datos de sobre flujo si la RAM 830 no es suficientemente grande como para contener todos los datos de trabajo. El almacenamiento 850 secundario puede usarse para almacenar programas que se cargan en RAM 830 cuando se seleccionan tales programas para ejecución.

Los dispositivos 860 de I/O pueden incluir pantallas de cristal líquido (LCDs), pantallas táctiles, teclados, teclados numéricos, conmutadores, diales, ratones, bolas de rastreo, reconocedores de voz, lectores de tarjetas, lectores de cinta de papel, impresoras, monitores de video, u otros dispositivos de entrada/salida bien conocidos. También, los componentes 825 de transceptor podrían considerarse como un componente de los dispositivos 860 de I/O en vez de o además de ser un componente de los dispositivos 820 de conectividad de red.

Los siguientes documentos se consideran como técnica anterior relevante:

R1-093699, "Way Forward on PDCCH for Bandwidth Extension in LTE-A", Alcatel-Lucent et al.

R1-093465, "Component carrier indication scheme for carrier aggregation", Panasonic.

3GPP, TS 36.212 v8.7.0 (2008-05) "E-UTRA; Multiplexing and channel coding."

3GPP, TS 36.814.

Las realizaciones proporcionan un método y dispositivos para conmutar entre un primer conjunto de información de control de enlace descendente (DCI) y un segundo conjunto de DCI mientras se utiliza la agregación de portadoras. Si bien se han proporcionado varias realizaciones en la presente divulgación, debe entenderse que los sistemas y métodos divulgados se pueden realizar en muchas otras formas específicas sin apartarse del espíritu o alcance de la presente divulgación. Los presentes ejemplos deben considerarse ilustrativos y no restrictivos, y la intención no se limita a los detalles que se dan en el presente documento. Por ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otro sistema o pueden omitirse o no implementarse determinadas características.

Además, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas realizaciones como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas o métodos sin apartarse del alcance de la presente divulgación. Otros ítems mostrados o discutidos como acoplados o acoplados directamente o que se comunican entre sí pueden estar acoplados indirectamente o comunicarse a través de alguna interfaz, dispositivo o componente intermedio, ya sea de manera eléctrica, mecánicamente o de otro modo.

Claims (13)

REIVINDICACIONES

1. Un método realizado por un dispositivo de un dispositivo (110, 140), de acceso, comprendiendo el método enviar desde el dispositivo (110, 140) de acceso a un equipo de usuario, UE (130), en un canal de control de enlace descendente físico, PDCCH, un primer conjunto de información de control de enlace descendente, DCI, con formatos (402, 404, 406; 502, 504, 506, 508) de DCI que contienen un campo indicador de portadora, CIF (405, 507);

enviar desde el dispositivo de acceso al UE un mensaje de control de recursos de radio, RRC, para ordenar al UE que conmute de usar el primer conjunto de DCI a usar un segundo conjunto de DCI, caracterizado porque el mensaje de RRC, para reconfigurar el UE, cuando se agregan las portadoras para uso por el UE, hace que el U^e conmute (700) de monitorizar el primer conjunto de información de control de enlace descendente, DCI, a monitorizar el segundo conjunto de DCI; y

en donde el primer conjunto de DCI comprende un conjunto de formatos de DCI que tienen un tamaño de CIF de 3 bits, y en donde el segundo conjunto no comprende ningún CIF.

2. El método como se reivindica en la reivindicación 1, en donde el mensaje de RRC para reconfigurar el UE hace que el UE conmute de monitorizar el primer conjunto de DCI que comprende el CIF que tiene un tamaño de CIF de 3 bits a monitorizar el segundo conjunto de DCI que no comprende ningún CIF.

3. El método de la reivindicación 1, en donde al menos un tamaño de formato de DCI común se incluye tanto en el primer conjunto de DCI como en el segundo conjunto de DCI.

4. El método de la reivindicación 1, en donde el CIF comprende bits de señalización añadidos a al menos uno de los formatos de DCI.

5. El método de la reivindicación 1, en donde el CIF permite la señalización en el PDCCH de una portadora que se agrega para referirse a los recursos de radio de otra portadora que se agrega.

6. El método de la reivindicación 5, en donde los recursos de radio referidos por la señalización en el PDCCH comprenden al menos uno de los recursos de canal compartido de enlace descendente físico, PDSCH, y recursos de canal compartido de enlace ascendente físico, PUSCH, de la otra portadora.

7. El método como se reivindica en la reivindicación 1, en donde después de que el dispositivo de acceso envíe el mensaje de RRC que ordena una conmutación de conjunto de DCI al UE, el dispositivo de acceso continúa usando el primer conjunto de DCI.

8. El método como se reivindica en la reivindicación 1, en donde el mensaje de RRC, para reconfigurar el UE, hace que el UE monitorice temporalmente tanto el primer conjunto de DCI como el segundo conjunto de DCI antes de que el UE conmute de monitorizar el primer conjunto de información de control de enlace descendente, DCI, para monitorizar el segundo conjunto de DCI; y en donde, mientras el UE está monitorizando tanto el primer conjunto de DCI como el segundo conjunto de DCI, el dispositivo de acceso recibe del UE un reconocimiento de RRC en respuesta al mensaje de RRC para indicar al dispositivo de acceso que el UE está monitorizando tanto el primer conjunto de DCI como el segundo conjunto de DCI.

9. El método como se reivindica en la reivindicación 8, en donde al recibir el reconocimiento de RRC del UE que indica al dispositivo de acceso que el UE está monitorizando tanto el primer conjunto de DCI como el segundo conjunto de DCI, el dispositivo de acceso deja de usar el primer conjunto de DCI.

10. El método de la reivindicación 8 o 9, que comprende además:

enviar mediante el dispositivo de acceso al UE un mensaje de control de recursos de radio, RRC, para hacer que el UE deje de monitorizar el formato de DCI en el primer conjunto de DCI en respuesta a la recepción del reconocimiento de RRC recibido en respuesta al mensaje de RRC para reconfigurar el UE.

11. El método como se reivindica en la reivindicación 10, en donde el dispositivo de acceso recibe del UE un reconocimiento de RRC para indicar al dispositivo de acceso que el UE está monitorizando solamente el segundo conjunto de DCI, en respuesta al envío del mensaje de RRC para hacer que el UE detenga la monitorización del formato de DCI en el primer conjunto de DCI.

12. El método de la reivindicación 1, que comprende además:

cuando un tamaño de un formato de DCI en el primer conjunto de DCI es igual a un tamaño de un formato de DCI diferente en el segundo conjunto de DCI, incluyendo bits de relleno adicionales para el formato de DCI en el segundo conjunto de DCI.

13. Un dispositivo (110, 140) de acceso que comprende:

un procesador (810) configurado para realizar el método de una cualquiera de las reivindicaciones 1 a 12.