ES2881866T3

ES2881866T3 - Señalización en redes de comunicación móvil de doble conectividad

Info

Publication number: ES2881866T3
Application number: ES15829237T
Authority: ES
Inventors: Der Velde Himke Van; Lieshout Gert Jan Van; Soenghun Kim
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2014-08-04
Filing date: 2015-07-31
Publication date: 2021-11-30
Anticipated expiration: 2035-07-31
Also published as: CN107113904B; CN107113904A; EP3178290B1; US20210281552A1; EP3886527A1; US11038859B2; EP3178290A1; KR102288057B1; US11743244B2; WO2016021890A1; GB201413798D0; GB2528913B; CN113271589A; CN113271589B; KR20170042314A; EP3178290A4; US20170222876A1; GB2528913A; EP3886527B1

Abstract

Un procedimiento realizado por una estación base maestra para proporcionar conectividad dual a un terminal (600), en un sistema de comunicación inalámbrica, el procedimiento comprendiendo: transmitir, a una estación base secundaria, un mensaje de solicitud de adición que incluye una configuración vigente de grupo celular secundario, SCG, configurada para el terminal; recibir, desde la estación base secundaria, un mensaje de acuse de recibo para un cambio de SCG del terminal, el mensaje de acuse de recibo incluyendo una nueva configuración de SCG configurada para el terminal por la estación base secundaria e información que indica si el terminal debe liberar la configuración de SCG vigente antes de aplicar la nueva configuración de SCG; y transmitir, al terminal, un mensaje de control de recursos de radio, RRC, para el cambio de SCG, el mensaje RRC incluyendo la nueva configuración SCG configurada al terminal por la estación base secundaria.

Description

DESCRIPCIÓN

Señalización en redes de comunicación móvil de doble conectividad

Campo técnico

La presente solicitud se refiere a invenciones en la señalización en redes de comunicación móvil de doble conectividad.

Técnica anterior

Las redes de comunicaciones inalámbricas o móviles (celulares) en las que un terminal móvil (UE, tal como un teléfono móvil) se comunica a través de un enlace de radio con una red de estaciones base (por ejemplo, eNB) u otros puntos de acceso inalámbricos conectados a una red de telecomunicaciones, han experimentado un rápido desarrollo a través de varias generaciones. El despliegue inicial de los sistemas que utilizaban señalización analógica ha sido sustituido por los sistemas digitales de segunda generación (2G), tal como Sistema Global de Comunicaciones Móviles (GSM), que suelen utilizar una tecnología de acceso radioeléctrico conocida tal como Velocidades de Datos Mejoradas GSM para la Evolución de Red de Acceso de Radio GSM (GERAN), combinada con una red central mejorada.

Los sistemas de segunda generación han sido sustituidos en gran medida por sistemas digitales de tercera generación (3G), tal como el Sistema Universal de Telecomunicaciones Móviles (UMTS), que utiliza una tecnología de acceso radioeléctrico de la Red Universal de Acceso Terrestre (UTRAN) y una red central similar a la de GSM. El UMTS se especifica en las normas elaboradas por el 3GPP. Las normas de tercera generación permiten un mayor flujo de datos que los sistemas de segunda generación. Esta tendencia continúa con el pasaje a los sistemas de Cuarta Generación (4G).

3GPP diseña, especifica y estandariza las tecnologías de las redes de comunicaciones móviles inalámbricas. Específicamente, 3GPP elabora una serie de informes técnicos (TR) y especificaciones técnicas (TS) que definen las tecnologías de 3GPP. En la actualidad, 3GPP se centra en la especificación de normas más allá de 3G y, en particular, en un Sistema de Paquetes Evolucionado (EPS) que ofrece mejoras sobre las redes 3G, incluida una mayor velocidad de datos. El conjunto de especificaciones para EPS comprende dos elementos de trabajo: La evolución de la arquitectura de los sistemas (SAE, respecto a la red central) y LTE, respecto a la interfaz aérea. El primer conjunto de especificaciones EPS se publicó como la versión 8 de 3GPP en diciembre de 2008. LTE utiliza una tecnología de acceso radioeléctrico mejorada conocida como UTRA evolucionada (E-UTRA), que ofrece una capacidad potencialmente mayor y características adicionales en comparación con los estándares anteriores. SAE proporciona una tecnología de red central mejorada, denominada Núcleo de Paquete Evolucionado (EPC). A pesar de que LTE se refiere estrictamente sólo a la interfaz aérea, se utiliza comúnmente para referirse a todo el EPS, incluso por el propio 3GPP. LTE se utiliza en este sentido en el resto de esta especificación, incluso cuando se refiere a las mejoras de LTE, como LTE Advanced. LTE es una evolución de UMTS y comparte ciertos componentes y protocolos de alto nivel con UMTS. LTE Advanced ofrece velocidades de datos aún más altas en comparación con lTe y está definida por las versiones de las normas 3GPP desde la versión 10 hasta la 12, inclusive. La Unión Internacional de Telecomunicaciones (UIT) considera que LTE Advanced es un sistema de comunicación móvil 4G.

La presente invención puede implementarse dentro de una red móvil LTE. Por lo tanto, en la Figura 1 se muestra una descripción general de una red LTE. El sistema LTE comprende tres componentes de alto nivel: al menos un UE 102, E-Ut Ra N 104 y EPC 106. EPC 106 se comunica con las redes de paquetes de datos (PDN) y los servidores 108 del mundo exterior. La Figura 1 muestra los principales componentes de EPC 106. Se apreciará que la Figura 1 es una simplificación y que una implementación típica de LTE incluye más componentes. En la Figura 1 se muestran las interfaces entre las distintas partes del sistema LTE. La flecha de doble punta indica la interfaz aérea entre UE 102 y E-UTRAN 104. En el resto de las interfaces, los datos del usuario se representan con líneas continuas y la señalización con líneas discontinuas.

E-UTRAN 104 comprende un único tipo de componente: un eNB (Nodo B de E-UTRAN) que es responsable de gestionar las comunicaciones de radio entre UE 102 y EPC 106 a través de la interfaz aérea. Un eNB controla los UE 102 en una o más celdas. LTE es un sistema celular en el que los eNB brindan cobertura a una o varias celdas. Normalmente hay una pluralidad de eNB dentro de un sistema LTE. En general, un UE en LTE normalmente sólo se comunica con un eNB a través de una celda a la vez. Sin embargo, como se explicará más adelante, se está introduciendo la conectividad dual (DC) de manera que el UE puede comunicarse con más de un eNB a la vez.

Los componentes clave de EPC 106 se muestran en la Figura 1. Se apreciará que en una red LTE puede haber más de uno de cada componente de acuerdo con el número de UE 102, el área geográfica de la red y el volumen de datos a transportar a través de la red. El tráfico de datos se transmite entre cada eNB y la correspondiente pasarela de servicio (S-GW) 110, que enruta los datos entre el eNB y una pasarela PDN (P-GW) 112. P-GW 112 es responsable de conectar un UE a uno o más servidores o PDN 108 en el mundo exterior. La entidad de gestión de movilidad (MME) 114 controla el funcionamiento de alto nivel del UE 102 mediante mensajes de señalización intercambiados con el UE 102 a través de E-UTRAN 104. Cada UE está registrado en una única MME. No existe una vía de señalización directa entre la MME 114 y el UE 102 (la comunicación con el UE 102 se realiza a través de la interfaz aérea mediante la E-UTRAN 104). Los mensajes de señalización entre la MME 114 y el UE 102 comprenden mensajes de protocolo de gestión de sesión EPS (ESM) que controlan el flujo de datos del UE hacia el mundo exterior y mensajes de protocolo de gestión de movilidad EPS (EMM) que controlan el enriam iento de los flujos de señalización y datos cuando el UE 102 se desplaza entre eNB dentro de la E-UTRAN. La MME 114 intercambia tráfico de señalización con la S-GW 110 para ayudar a enrutar el tráfico de datos. La MME 114 también se comunica con un servidor de abonados domésticos (HSS) 116 que almacena información sobre los usuarios registrados en la red.

Dentro de una red LTE, los datos se transfieren entre diferentes componentes de la red utilizando portadores. Un portador EPS sirve para transferir datos entre un UE y una P-GW. El flujo de datos es bidireccional. Los datos transportados por un portador EPS comprenden uno o más flujos de datos de servicio que transportan datos para un servicio particular, por ejemplo, medios de transmisión. Cada flujo de datos de servicio comprende uno o más flujos de paquetes.

Los grupos de trabajo de la Red de Acceso Radioeléctrico (RAN) del 3GPP están trabajando actualmente en un Elemento de Estudio (SI) denominado "Mejoras en Celdas Pequeñas". El resultado técnico de este SI está documentado en el documento 3GPP TR 36.842 "Evolved Universal Terrestrial Radio Access (E-UTRA)"; Study on Small Cell enhancements for E-UTRA and E-UTRAN - Higher layer aspects (versión 12); c0.0. 3GPP TR 36.842 se refiere a los aspectos de acceso radioeléctrico de SI y afecta tanto al UE como al eNB. Las mejoras de las celdas pequeñas son aplicables, por ejemplo, cuando hay una macrocelda y una celda pequeña (dentro del área de cobertura de la macrocelda) que operan en la misma frecuencia portadora.

Actualmente se propone que la RAN soporte la llamada funcionalidad de "conectividad dual". La conectividad dual se refiere a una operación en la que un determinado equipo de usuario consume recursos radioeléctricos proporcionados por al menos dos puntos de red diferentes (eNB maestro y secundario) conectados con backhaul no ideal mientras el equipo de usuario está activo dentro de la red (en un estado RRC_CONNECTED (Control de Recursos Radioeléctricos Conectado). Esto se ilustra en la Figura 2. En la conectividad dual, el UE está configurado con múltiples celdas, una por frecuencia de servicio, mientras que las celdas de servicio están conectadas a más de un eNB. También se denomina agregación de portadoras (CA) inter-eNB. La conectividad dual permite alcanzar una mayor velocidad de datos entre el UE y la RAN. Para lograr la conectividad dual, se propone que la RAN admita la funcionalidad de "división del portador". En la conectividad dual, la división del portador se refiere a la capacidad de dividir un portador en varios eNB. Un eNB maestro (MeNB, normalmente eNB de la macrocelda) es el eNB que termina al menos la interfaz S1-MME (la interfaz entre el eNB y la MME) y, por tanto, actúa como ancla de movilidad hacia la red central (CN). Un eNB secundario (SeNB, normalmente eNB que gestiona las celdas pequeñas) es un eNB que proporciona recursos radioeléctricos adicionales para el UE, que no es el MeNB. Un Grupo de Celdas Maestras (MCG) es el grupo de celdas servidoras que proporcionan recursos radioeléctricos asociados al MeNB, mientras que un Grupo de Celdas Secundarias (SCG) es el grupo de celdas servidoras que proporcionan recursos radioeléctricos asociados al SeNB.

Con referencia a la Figura 3A, esta muestra la opción 1 de la Figura 8.1.1-1 de TS 36.842, que ilustra una opción de división del portador ahora soportada en la dirección del enlace descendente (la división del portador no se soporta actualmente en la dirección de enlace ascendente). Se puede observar que hay un primer portador EPS (#1: flechas ^{sólidas) que se comunica directamente desde un P-GW (no mostrado) a través de la}S-Gw ^{y el MeNB al UE. Un}segundo portador EPS (#2: flechas discontinuas) pasa de la S-GW al UE a través del SeNB (y no a través del MeNB). En este caso, la Red Central (específicamente la S-GW) enruta los datos a través de uno de los dos portadores.

La Figura 3B, muestra la opción 3 de la Figura 8.1.1-1 de TS 36.842, que ilustra otra opción de división del portador ahora soportada, tomando como ejemplo la dirección de enlace descendente. Se puede observar que hay un primer portador EPS (#1: flechas sólidas) que se comunica directamente desde un P-GW (no mostrado) a través de la S-GW y el MeNB al UE. Un segundo portador EPS (#2: flechas discontinuas) pasa del MeNB al UE a través del SeNB, así como directamente entre el MeNB y el UE. El segundo portador EPS se divide en la RAN, y la propia RAN (específicamente la MeBN) divide los datos entre los portadores.

En estas arquitecturas de plano de usuario, un portador de radio de datos MCG (DRB) es el término utilizado para un DRB cuyos datos DL se transfieren a través de celdas MCG, del mismo modo un DRB SCG es un DRB cuyos datos DL se transfieren a través de celdas SCG mientras que un DRB dividido se utiliza para referirse a un DRB cuyos datos DL se transfieren tanto a través de MCG como de SCG. En el enlace ascendente no hay conectividad dual, es decir, para un DRB dividido, el MeNB configura/indica qué Grupo de celdas (CG) debe utilizar el UE para transferir datos UL.

La arquitectura del plano de control adoptada para proporcionar conectividad dual se muestra en la Figura 4. En este caso, sólo el MeNB genera los mensajes finales de control de recursos radioeléctricos (RRC) que se enviarán al UE tras la coordinación de las funciones de gestión de recursos radioeléctricos (RRM) entre el MeNB y el SeNB. El MeNB puede enviar información de configuración controlada por el SeNB. La entidad RRC del UE observa todos los mensajes ^{procedentes de una sola entidad (en el MeNB) y el}Ue ^{sólo responde a esa entidad. Es decir, para la señalización}RRC no hay doble conectividad (DC), es decir, el MeNB gestiona toda la señalización hacia el UE. En general, el SeNB decide los parámetros de configuración relacionados con la SCG y éstos se transfieren a través del MeNB al UE mediante las celdas MCG.

Para conseguir un portador dividido es necesario modificar la arquitectura del plano de usuario existente mostrada en la Figura 6-1 de 3GPP TS 36.300 "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)"; Overall description; Stage 2 (Versión 11); v11.7.0 (no reproducido en la presente especificación). En un eNB, para comunicarse con el UE a través de la interfaz aérea, el eNB comprende una pila de protocolos que tiene una capa PDCP, una capa de control de enlace de radio (RLC) y una capa de control de acceso al medio (MAC). En conjunto, estas capas de protocolo forman la capa de enlace de datos: la capa dos del modelo estándar de Interconexión de Sistemas Abiertos (OSI). La capa MAC realiza el control de bajo nivel de la capa física (capa 1 del modelo OSI, y fuera del ámbito de la presente especificación), incluyendo la programación de las transmisiones de datos entre el móvil y la estación base. La capa RLC mantiene el enlace de datos entre el UE y el eNB, y gestiona el acuse de recibo de los paquetes de datos, cuando es necesario. La capa PDCP realiza funciones de transporte de alto nivel, como la compresión de cabeceras y la seguridad. En cada capa de la pila de protocolos, el protocolo recibe un paquete de datos del protocolo superior en forma de unidad de datos de servicio (SDU), procesa los paquetes y añade una cabecera para formar una unidad de datos de protocolo (PDU). La PDU se convierte en la SDU entrante de la siguiente capa de la pila.

En una arquitectura portadora como la mostrada en la Figura 3A, la pila de protocolos de capa 2 en el eNB se divide entre el MeNB y el SeNB, como se muestra en la Figura 5A. Específicamente, un portador radioeléctrico dividido utiliza dos entidades RLC como se muestra en la Figura 5B, que reproduce la Figura 8.1.1.8-1 de 3GPP TR 36.842. La Figura 5B muestra una primera pila de protocolos portadores no divididos en el MeNB (recuadros sólidos). La Figura 5B muestra los datos que se reciben de la S-GW a través de la interfaz S1. La Figura 5B muestra además un segundo portador de radio dividido (recuadros y flechas discontinuos). Para el portador dividido hay una única entidad PDCP en el MeNB y entidades de pila de protocolos RLC/MAC duplicadas para el portador dividido tanto en el MeNB como en el SeNB. Los datos se envían entre la entidad PDCP única en el MeNB y las entidades RCL/MAC en el SeNB a través de la interfaz Xn (denominada alternativamente interfaz X2). Aunque no se muestra en la Figura 3, en el lado del UE hay entidades MAC/RLC/PDCP correspondientes, y específicamente una única entidad UE PDCP y entidades ^{UE MAC/RLC duplicadas. Aunque no se muestra en la Figura}5a, ^{en el lado del UE habría entidades MAC/RLC/PDCP}correspondientes para los portadores.

En una arquitectura de división de portador como la que se muestra en la Figura 3B, la pila de protocolos de capa 2 en el eNB se divide entre el MeNB y el SeNB, como se muestra en la Figura 5B. Específicamente, un portador radioeléctrico dividido utiliza dos entidades RLC como se muestra en la Figura 5B, que reproduce la Figura 8.1.1.8-1 de 3GPP TR 36.842. La Figura 5B muestra una primera pila de protocolos portadores no divididos en el MeNB (recuadros sólidos). La Figura 5B muestra los datos que se reciben de la S-GW a través de la interfaz S1. La Figura 5B muestra además un segundo portador de radio dividido (recuadros y flechas discontinuos). Para el portador dividido hay una única entidad PDCP en el MeNB y entidades de pila de protocolos RLC/MAC duplicadas para el portador dividido tanto en el MeNB como en el SeNB. Los datos se envían entre la entidad PDCP única en el MeNB y las entidades RCL/MAC en el SeNB a través de la interfaz Xn (denominada alternativamente interfaz X2). Aunque no se muestra en la Figura 5B, en el lado del UE hay entidades MAC/RLC/PDCP correspondientes, y específicamente una única entidad UE PDCP y entidades UE MAC/RLC duplicadas.

El documento WO 2014/113082 desvela una tecnología para comunicar información de clave de seguridad desde un macro eNB. Se puede determinar la información de clave de seguridad asociada al macro nodo B evolucionado (eNB). La información de clave de seguridad puede utilizarse para cifrar la información comunicada en el primer eNB. Un pequeño eNB puede ser identificado en el macro eNB para generar la información de clave de seguridad asociada al macro eNB para cifrar la información comunicada en el segundo eNB. La información de clave de seguridad puede ser comunicada, desde el macro eNB, al pequeño eNB para la agregación de portadoras del nodo B evolucionado (eNB) de Acceso Universal Terrestre (EUTRA).

El documento WO 2014/113190 desvela procedimientos, aparatos y sistemas para gestionar portadores en un sistema de comunicación inalámbrica. En algunas realizaciones, un aparato, a ser empleado por un equipo de usuario (UE), puede comprender un módulo de comunicación para: comunicarse con una red central en un primer portador a través de un Nodo B evolucionado maestro (MeNB); recibir, desde el MeNB, un primer mensaje de reconfiguración de una conexión de control de recursos de radio (RRC) para establecer un segundo portador entre el UE y la red central y a través de un eNB secundario (SeNB); sincronizar, en respuesta al mensaje, con el SeNB para establecer el segundo portador; y comunicarse con la red central en el segundo portador a través del SeNB, y continuar comunicándose con la red central en el primer portador a través del MeNB.

El documento CN 103959829 desvela un procedimiento y un dispositivo de procesamiento de claves en un módulo de doble conexión, que garantizan la seguridad de las comunicaciones del UE en un modo de doble conexión. El procedimiento de las realizaciones de la invención comprende una etapa en la que, de acuerdo con una primera estación base y una segunda estación en la que existe una conexión de comunicación con un terminal, la segunda estación recibe un primer mensaje de solicitud que se utiliza para pedir a la segunda estación base que genere una clave utilizada en la comunicación con el terminal y enviada por la primera estación base; y una etapa en la que la segunda estación base, en base a una clave de seguridad transportada en el primer mensaje de solicitud, genera una clave utilizada en la comunicación con el terminal.

El documento WO 2013/097672 desvela un procedimiento de comunicación de seguridad de agregación de portadoras entre estaciones base. El procedimiento comprende: un equipo de usuario que recibe un primer mensaje sobre la adición de una celda controlada por una estación base auxiliar como celda de servicio enviada por una estación base principal del equipo de usuario; y que genera una clave de acuerdo con el contexto de seguridad de la estación base principal y el primer mensaje, utilizándose la clave para comunicarse con la celda controlada por la estación base auxiliar. También se desvelan los equipos de usuario correspondientes y una estación base.

El documento SCG Mobility Procedures, NSN and Nokia Corporation, 3GPP TSG-RAN WG3 #83bis, R3-140612, desvela procedimientos relacionados con el cambio de Grupo de Celdas Secundarias (SCG), incluyendo los procedimientos de adición/modificación/liberación de SCG.

El documento SeNB Change and Data Forwarding, Huawei, 3GPP TSG-RAN WG3 Meeting #83bis, R3-140568desvela un flujo de señalización para el procedimiento de cambio de eNodoB secundario (SeNB) para las alternativas 1A y 3C de Plano de Usuario.

El documento PDCP Status Report for Split Bearer, KT Corp, 3GPP TSG-RAN WG2 Meeting #86, R2-142160, desvela un enfoque para el informe de estado PDCP, en el que en caso de cambio de grupo de celdas secundarias (SCG) y liberación de SCG para portador dividido, el UE puede enviar un informe de estado PDCP.

El documento L2 Handling for SeNB Related Procedures, Fujitsu, 3GPP TSG-RAN WG2 Meeting #86, R2-142334, desvela enfoques para la gestión de la capa 2 cuando se añade, libera, cambia o modifica un eNodoB secundario (SeNB).

Divulgación de la invención

Problema técnico

La RAN y el UE deben estar configurados para comunicarse a través de la señalización y para cooperar con el fin de configurar de manera eficiente y eficaz el UE, la RAN y la CN para la CC, y para evitar el tiempo de inactividad del UE, la alta latencia y el aumento del volumen de señalización. Esta señalización y configuración debe tener en cuenta los numerosos tipos de procedimientos de reconfiguración del DRB y los cambios de tipo de DRB que pueden producirse ^{durante la}cC. ^{Es decir, los procedimientos de reconfiguración del DRB pueden incluir: un cambio de reconfiguración}normal; un cambio de SCG; una liberación de SCG; y un procedimiento de establecimiento de SCG. Los procedimientos de cambio de SCG y liberación de SCG pueden ocurrir como parte de un procedimiento de traspaso (HO). Además, puede producirse un fallo de enlace de radio (RLF) del DRB en DC, incluido un DRB SCG. El tipo de DRB puede cambiarse entre un DRB MCG, un DRB SCG y un DRB dividido

Solución al problema

Se proporciona un procedimiento de acuerdo con la reivindicación 1, un procedimiento de acuerdo con la reivindicación 4, una estación base maestra de acuerdo con la reivindicación 7, y una estación base secundaria de acuerdo con la reivindicación 10 de acuerdo con las reivindicaciones adjuntas.

Efectos ventajosos de la invención

La presente invención proporciona procedimientos de señalización y operación en la RAN para implementar eficazmente la CC teniendo en cuenta las reconfiguraciones del DRB y los cambios de tipo que se producen en el curso de la utilización de la CC.

Breve descripción de los dibujos

Las realizaciones de la invención se describen más adelante con referencia a los dibujos adjuntos, en los que:

La Figura 1 ilustra de forma esquemática una red de comunicaciones móviles LTE;

La Figura 2 ilustra la asignación de recursos radioeléctricos entre nodos en la conectividad dual;

La Figura 3A ilustra una disposición soportada de un portador para dividir los datos de enlace descendente del plano de usuario en el CN;

La Figura 3B ilustra otra disposición soportada de un portador dividido para dividir los datos de enlace descendente del plano de usuario en la RAN;

La Figura 4 ilustra una arquitectura de plano de control para la conectividad dual;

La Figura 5A ilustra una pila de protocolos RAN en un MeNB y un SeNB para el portador dividido de la Figura 3A;

La Figura 5B ilustra una pila de protocolos RAN en un MeNB y un SeNB para el portador dividido de la Figura La Figura 6 muestra un diagrama de bloques que ilustra los componentes seleccionados de un equipo de usuario para uso en una red de comunicación inalámbrica, como se muestra en las Figuras 1 y 2;

La Figura 7 es un diagrama de flujo que ilustra un procedimiento de un UE para tomar medidas sobre la reconfiguración de DRB y/o el cambio de tipo de DRB en DC;

La Figura 8 es un gráfico de secuencia de mensajes que muestra un procedimiento de cambio de SeNB que implementa señalización delta;

La Figura 9 es un diagrama de flujo que ilustra un procedimiento de un UE para soportar la señalización delta en el cambio de SCG y el cambio de tipo de DRB;

La Figura 10 es un diagrama de flujo que ilustra un procedimiento de un eNB;

Modo de la invención

Las realizaciones de la invención se describirán ahora en el contexto de una red de comunicaciones móviles inalámbricas compatible con LTE que opera de acuerdo con los estándares 3GPP LTE hasta la versión 12 y posteriores. Sin embargo, se entenderá que esto es sólo a modo de ejemplo y que otras realizaciones pueden implicar otras redes inalámbricas, que funcionen al menos parcialmente de acuerdo con otras versiones y otras normas.

La Figura 6 muestra un diagrama de bloques que ilustra algunos componentes de ejemplo comprendidos en un ejemplo de UE 600 que puede ser utilizado en la red inalámbrica habilitada para LTE como se muestra en la Figura 1. Sin embargo, este ejemplo de UE no está cubierto por las reivindicaciones. El UE 600 puede ser un dispositivo inalámbrico y su Tarjeta de Circuito Integrado Universal (U1CC) asociada que incluye una aplicación de módulo de identidad de abonado (SIM), una aplicación de módulo de identidad de abonado universal (USIM) o una aplicación de módulo de identidad de usuario extraíble (R-UIM), o el UE 600 puede ser el propio dispositivo sin dicha tarjeta.

El UE 600 incluye múltiples componentes unidos por un bus de comunicaciones 601. Un procesador 602 controla el funcionamiento general del UE 600. Las funciones de comunicación, incluidas las comunicaciones de datos y de voz, se realizan a través de un subsistema de comunicación 604. El subsistema de comunicación 604 puede adoptar la forma de módems, bancos de módems, dispositivos Ethernet, dispositivos de interfaz de bus serie universal (USB), interfaces serie, dispositivos token ring, dispositivos de interfaz de datos distribuidos por fibra (FDDI), dispositivos de red de área local inalámbrica (WLAN), dispositivos transceptores de radio como dispositivos de acceso múltiple por división de código (CDMA), dispositivos transceptores de radio del sistema global de comunicaciones móviles (GSM), dispositivos de interoperabilidad mundial para el acceso por microondas (WiMAX), y/u otros dispositivos conocidos para conexión a redes. El subsistema de comunicación 604 puede permitir que el procesador 602 se comunique con Internet o con una o más redes de telecomunicaciones u otras redes de las que el procesador 602 puede recibir información o a las que el procesador 602 puede emitir información.

En el contexto de la Figura 1, el subsistema de comunicación 604 recibe mensajes desde y envía mensajes a la red inalámbrica 606 que puede ser la E-UTRAN 104 mostrada en la Figura 1 para comunicaciones de voz o comunicaciones de datos o ambas.

Una fuente de alimentación 608, tal como una o más baterías recargables o un puerto a una fuente de alimentación externa, alimenta el UE 600.

El procesador 602 interactúa con otros componentes del dispositivo electrónico, incluyendo Memoria de Acceso Aleatorio (RAM) 610, almacenamiento masivo 612 (incluyendo, pero sin limitación, discos magnéticos y ópticos, cinta magnética, unidades de estado sólido o matrices RAID), Memoria de Sólo Lectura (ROM) 614 y pantalla de visualización 616, que puede ser, por ejemplo, una pantalla de cristal líquido (LCD). Un controlador de entrada/salida 618 envía y recibe señales relativas a uno o más dispositivos de control del usuario, como una superposición sensible al tacto en la pantalla 616 para permitir la interacción del usuario con el UE 600.

El procesador 602 ejecuta instrucciones, código, software o programas informáticos a los que puede acceder desde el subsistema de comunicaciones 604, la RAM 610, el almacenamiento masivo 612 o la ROM 614. El procesador 602 puede comprender una o más unidades de procesamiento de datos o chips de CPU. El procesador 602 puede ejecutar las instrucciones únicamente por sí mismo, o en concierto con otros componentes de procesamiento de datos proporcionados local o remotamente u otros componentes no mostrados en la Figura 6. En particular, el procesador 602 es capaz de llevar a cabo instrucciones de tal manera que el UE 600 es operable para realizar comunicaciones inalámbricas en una red LTE de acuerdo con la divulgación expuesta a continuación.

Por ejemplo, el procesador 602 puede llevar a cabo instrucciones para instanciar y mantener un gestor de comunicaciones en la RAM 610 que en uso opera el subsistema de comunicaciones 604 para realizar la señalización para interactuar con E-UTRAN 104.

El gestor de comunicaciones puede instanciar, por ejemplo en la RAM 610 del UE 600, una pila de protocolos LTE para proporcionar, como se ha descrito anteriormente en relación con las Figuras 5A y 5B, en las capas del estrato de acceso de LTE, una o más de una capa de señalización de control de recursos de radio (RRC) que suele ser responsable del control de las funciones relacionadas con la radio, una capa de señalización de Control de Convergencia de Datos de Paquetes (PDCP) que suele ser responsable de la compresión y la seguridad de las cabeceras, una capa de señalización de Control de Enlace de Radio (RLC) que suele ser responsable de la retransmisión de datos perdidos, una capa de señalización de Control de Acceso al Medio (MAC) que suele ser responsable de controlar el acceso a la Capa Física (PHY). Por supuesto, las capas de la pila de protocolos pueden implementarse en otro lugar, por ejemplo, la señalización MAC y PHY puede proporcionarse en el UE mediante firmware o hardware y no mantenerse en la RAM 610. De hecho, la implementación de la pila de protocolos en la RAM 610 UE descrita anteriormente es sólo un ejemplo de las muchas posibilidades dentro del ámbito de la presente divulgación, y se proporciona sólo con fines explicativos.

Como se ha mencionado anteriormente, el sistema LTE incluye protocolos como el de control de recursos de radio (RRC), que se encarga de la asignación, configuración y liberación de conexiones y recursos de radio entre el UE 102 y eNB de E-UTRAN 104 u otros equipos de acceso o LTE. Estos protocolos tienen que definir la señalización y las operaciones en el UE, el MeNB del MCG y el SeNB del SCG para gobernar cómo funcionan e interactúan estos componentes de la red de comunicaciones inalámbricas para soportar la conectividad dual.

Para reducir la repetición innecesaria de las acciones del UE en la reconfiguración del DRB y/o en el cambio de tipo de DRB, la presente solicitud proporciona un procedimiento en el que un UE determina las acciones de capa 2 que deben tomarse basándose en el tipo y la configuración del DRB objetivo, en lugar de en los campos individuales de la reconfiguración señalada. Esto se describe con más detalle con referencia a la Figura 7.

De acuerdo con el estándar LTE, el UE modifica la configuración de radio (incluyendo la configuración del plano de usuario de capa 2 que comprende una configuración MAC principal y una configuración de canales lógicos, RLC y PDCP por portador de radio):

a. Tras recibir (del MeNB) un mensaje de reconfiguración que incluya parámetros de configuración

b. Tras recibir un mensaje que desencadena una acción específica, por ej., en el momento del traspaso, el equipo de usuario reinicia primero la MAC, restablece PDCP y RLC para cada DRB que se haya establecido

c. Tras producirse un evento específico, por ejemplo, cuando el UE inicia el restablecimiento de la conexión, libera las celdas secundarias (SCells)

Los parámetros de configuración que son señalados al UE por el MeNB, pueden referirse a

- Señalización Delta: Cambios en comparación con la configuración/ la configuración en el momento en que se procesan los parámetros señalados (es decir, antes de que el UE procese los parámetros de configuración recibidos, el UE puede desencadenar acciones que den lugar a un cambio de la configuración, por ejemplo, en el momento del traspaso). Como se entenderá a partir de la descripción más adelante, actualmente la señalización delta se admite en LTE en la reconfiguración normal y en el traspaso.

- Señalización completa: toda la configuración que el UE aplicará, independientemente de la configuración vigente

Para la Conectividad Dual, se ha acordado a través de las discusiones del grupo de trabajo 3GPP que:

- Debe especificarse un procedimiento de cambio de SCG, es decir, un mensaje de reconfiguración que incluya la liberación del SCG vigente, así como la adición de un SCG. El nuevo SCG puede incluir celdas que estaban presentes en el anterior SCG, en cuyo caso el nuevo SCG es manejado por el mismo SeNB

- Tras el traspaso, el SCG se libera o, si el MeNB quiere continuar con la CC, puede realizar un cambio de SCG como parte del traspaso

- No se acordó ninguna restricción en relación con el procedimiento de cambio de SCG, por ejemplo, que este o algunos casos específicos sólo puedan realizarse en combinación con el traspaso

- En caso de un cambio de tipo de DRB de un DRB dividido a un DRB MCG, la MCG-RLC no se restablece, es decir, el UE simplemente libera la SCG-RLC

Una propuesta presentada al grupo de trabajo de 3GPP sobre mejoras de celdas pequeñas como el documento R2-141940 cubre en gran medida la operación PDCP en DC que debe realizarse en casos que implican: cambio de tipo de DRB, adición/cambio/liberación de SCG, reconfiguración de la trayectoria UL de DRB dividido. En resumen, el documento indica que:

a. Tras el cambio de un MCG DRB a un DRB dividido, no es necesario realizar ninguna acción PDCP específica, salvo configurar la ruta de datos UL (es decir, qué CG debe aplicar el UE para los datos UL) b. Tras el traslado de la entidad PDCP entre el MeNB y el SeNB, el UE realiza un restablecimiento PDCP igual al HO sin CC

c. Tras el cambio de SCG, el equipo de usuario realiza un restablecimiento de PDCP los DRB de SCG de la misma manera que en HO sin CC

d. Tras el cambio de un DRB dividido a un DRB MCG, el UE realiza un restablecimiento parcial de PDCP (simplemente de la parte SCG)

e. Tras el cambio de SCG, el UE realiza un restablecimiento parcial de PDCP para DRB divididos

La lista anterior muestra que hay múltiples desencadenantes para un restablecimiento (parcial) de PDCP. Además, un solo mensaje de reconfiguración recibido por el UE puede dar lugar a múltiples desencadenantes, por ejemplo:

- Si un mensaje de reconfiguración que incluye el cambio de SCG se utiliza también para cambiar el tipo de DRB de un DRB SCG a un DRB MCG, por ejemplo, porque el SeNB de destino está algo cargado, el UE detecta ambos desencadenantes (b) y (c) para el DRB SCG en cuestión

- Si un mensaje de reconfiguración que incluye el cambio de SCG se utiliza también para cambiar el tipo de DRB de un DRB dividido a un DRB MCG (por razones similares), el UE detecta ambos desencadenantes (d) y (e) para el DRB dividido en cuestión

- Un mensaje de traspaso que incluye la liberación de SCR puede incluir también el cambio de tipo de DRB de un DRB SCG a un DRB MCG (o puede ser realizado de forma autónoma por el UE, como en B.7), el UE puede volver a detectar múltiples desencadenantes para el restablecimiento de PDCP

Como se indica en lo anterior, se supone que el cambio de SCG se señala mediante la liberación del SCG vigente y la adición de un SCG posiblemente diferente. En estos casos, sobre la base de la especificación vigente, el UE en primer lugar normalmente tomaría una acción basada en un campo que indica la liberación del SCG y posteriormente tomaría una acción basada en otro campo que indica la adición de un nuevo SCG.

No es deseable que un único mensaje de reconfiguración haga que el UE desencadene, por ejemplo, el restablecimiento de PDCP más de una vez, ya que podría incluso hacer que el UE transmitiera múltiples informes de estado PDCP. Incluso puede ocurrir que un mensaje de reconfiguración incluya una primera reconfiguración que, por sí sola, desencadene una determinada acción, pero que en combinación con otra reconfiguración no dé lugar a ninguna o a una acción diferente.

Para evitar la repetición innecesaria de ciertas acciones por parte del UE, lo que llevaría a un aumento de la señalización y a una disminución del rendimiento, de acuerdo con la presente divulgación el UE debe estar configurado para no tomar medidas inmediatamente después de detectar un disparador individual, sino que debería tener en cuenta la configuración inicial completa y la configuración final completa, así como cualquier tipo de procedimiento de reconfiguración relevante del DRB.

De este modo, con referencia a la Figura 7, que muestra un diagrama de flujo que ilustra un procedimiento de un UE (este procedimiento no está sin embargo cubierto por las reivindicaciones) para tomar medidas sobre la reconfiguración de DRB y/o el cambio de tipo de DRB en DC, el UE está configurado en la etapa 701 para detectar un procedimiento de reconfiguración señalado de un DRB que tiene o cambia a un DRB SCG o a un tipo de DRB dividido. Es decir, el cambio de tipo de DRB o la reconfiguración de DRB es para cambiar de o a un DRB en el que los datos de enlace descendente, DL, se reciben sólo de las celdas servidoras de un Grupo de celdas Secundarias, SCG, conectado a un eNB Secundario, SeNB, a través de un DRB SCG, o en el que los datos DL se reciben de un SCG y también de las celdas servidoras de un Grupo de Celdas Maestras, MCG, conectado a un eNB Maestro, MeNB, a través de un DRB dividido. En la etapa 702, el UE determina si se detecta un tipo de procedimiento de reconfiguración DRB que incluya uno o más de: un traspaso; un cambio de SCG; y un cambio de tipo DRB. Si la respuesta en el punto de decisión en la etapa 702 es afirmativa, entonces en la etapa 703 el UE decide una o más acciones requeridas relacionadas con el DRB de capa 2 que resultan de la reconfiguración del DRB en base a: la configuración inicial del DRB; la configuración final del DRB; y los tipos de procedimiento de reconfiguración del DRB relevantes. En la etapa 704, el UE realiza entonces dichas acciones decididas relacionadas con el DRB de capa 2.

Si la respuesta en el punto de decisión en la etapa 702 es no, entonces en la etapa 705 el UE continúa de acuerdo con la especificación vigente. Es decir, la reconfiguración puede incluir otros cambios de configuración que el UE aún debe realizar de acuerdo con la especificación vigente. La Figura 7 se centra en las acciones adicionales de la capa 2 relacionadas con el DRB tras la reconfiguración del tipo de DRB, así como el traspaso y/o el establecimiento/cambio/liberación del SCG.

Se observa que, de forma más general, la presente aplicación establece que las acciones resultantes relacionadas con el DRB de capa 2 realizadas por el UE dependen del tipo de procedimiento (de reconfiguración) y de la reconfiguración del tipo de DRB. En este caso, el tipo de procedimiento (de reconfiguración) se define como un término generalizado para la combinación de los procedimientos {reconfiguración normal, traspaso} y {establecimiento de SCG, cambio de SCG, liberación de SCG}.

De acuerdo con el procedimiento descrito anteriormente, si al decidir una o más acciones necesarias relacionadas con el DRB de capa 2 resultantes de la reconfiguración del DRB, se generan múltiples disparadores para una acción, el procedimiento puede permitir al UE decidir realizar la acción sólo una vez. Por ejemplo, cuando las acciones requeridas relacionadas con el DRB de capa 2 incluyen una acción de restablecimiento del Protocolo de Convergencia de Datos de Paquetes, PDCP, y si al decidir una o más acciones requeridas resultantes de la reconfiguración del DRB, se generan múltiples disparadores para la misma acción de restablecimiento del PDCP, el UE puede decidir realizar la acción de restablecimiento del PDCP sólo una vez.

Las operaciones de descarga L2 actualmente en LTE se realizan en el momento del traspaso, en cuyo caso se utiliza la señalización delta. Sin embargo, como se mostrará más adelante, la presente solicitud establece que el uso de la señalización delta debe ser apoyado no sólo en HO, sino también en el cambio de SCG y en el cambio de tipo de DRB, es decir, los otros casos en los que se realizan tales operaciones de descarga L2.

El siguiente análisis incluye una consideración en profundidad de los detalles de cómo especificar el comportamiento de un UE configurado con DC al recibir un mensaje de reconfiguración que incluye el traspaso, el cambio de SCG y/o el cambio de tipo de DRB. El análisis no se limita a PDCP, sino que también incluye MAC y RLC.

Como se ha indicado anteriormente, al cambiar el SCG, el mensaje de reconfiguración enviado desde la RAN incluye una liberación y adición del SCG, lo que significa que se señalan todos los parámetros de configuración del SCG. Como se ha indicado anteriormente, la operación PDCP es la misma que se realiza en el traspaso. Sin embargo, en caso de traspaso, E-UTRAN normalmente sólo señala los cambios en comparación con la configuración vigente (es decir, la señalización delta). Sin embargo, el protocolo también incluye una opción para proporcionar la configuración completa en el momento del traspaso, destinada a abordar el caso de que el eNB de destino no comprenda la configuración vigente, ya que soporta una versión inferior del protocolo. La Tabla 1 resume la acción actualmente especificada en el traspaso (sin/con fullConfig), enumerada en orden secuencial.

Tabla 1

[Tabla 1]

Tabla 1. Acciones actualmente especificadas en el traspaso para señalización delta y completa

Algunas observaciones adicionales sobre la especificación anterior para HO son las siguientes:

- En el caso de fullConfig, el UE sigue realizando el restablecimiento de L2 antes de liberar las entidades, lo que parece redundante

- El restablecimiento de MAC que se realiza en el traspaso se considera funcionalmente equivalente a la liberación adición de la entidad MAC, tal y como se realizaría en la liberación y adición de SCG

- Se considera que el reinicio de RLC que se realiza en el traspaso no es totalmente equivalente funcionalmente a la liberación adición de la entidad RLC. Es decir, para la liberación de una entidad RLC, la especificación no establece/exige explícitamente el reensamblaje de las SDU RLC y su reenvío a las capas superiores (como se hace al restablecer RLC). Sin embargo, al parecer el UE debe realizar esta operación también en el momento de la liberación de RLC (aunque actualmente no es obligatorio)

A partir de lo anterior, se pasa a considerar un procedimiento de cambio de SCG cuando se utiliza la liberación y la adición al cambio de SCG (es decir, sin señalización delta):

- la operación de UE a ser realizarse en las capas RLC y MAC no parece requerir ninguna especificación, ya que se deduce automáticamente de la liberación y adición de la entidad en cuestión

- Sin embargo, la operación que debe realizar el UE en PDCP es diferente a una simple liberación y adición de la entidad en cuestión, es decir, la entidad PDCP realmente necesita continuar y realizar algunas acciones para evitar la pérdida de datos. Sin embargo, es posible modelar esta operación, pero significa que el UE no puede procesar los campos recibidos drbToReleaseList y drbToAddModList de forma independiente, sino que tiene que reconocer que DRB continúa realmente

- En lo anterior, se indicó que UE no sólo necesita considerar el cambio de SCG sino también el cambio de tipo de DRB y, por lo tanto, necesita analizar ambos campos para decidir la acción requerida

Sin embargo, si la señalización delta fuera compatible con el cambio de SCG, el análisis realizado ha demostrado que:

- La operación del UE que debe realizarse en las capas RLC y MAC requiere declaraciones similares a las del traspaso

- La operación del UE en PDCP puede especificarse de forma similar al traspaso. Si la operación es necesaria para los casos que no implican un traspaso (es decir, cuando el cambio de SCG no se realiza como parte del traspaso), es necesario introducir un campo separado para activar esta operación

El análisis ha demostrado que lo mismo se aplica si se admite la señalización delta al cambiar el tipo de DRB, incluso cuando implica un movimiento de PDCP de la configuración MCG a la SCG (es decir, un cambio del tipo de DRB de MCG o división a SCG DRB) o viceversa. Se ha comprobado que en este caso la señalización delta tiene la ventaja de que se puede alinear el funcionamiento de PDCP, RLC y MAC con el comportamiento que se realiza en el traspaso.

Se reconoce que el apoyo de la señalización delta en el cambio de tipo de DRB implica que la referencia para la señalización de la configuración delta difiere según el caso, es decir:

- En el caso de que la reconfiguración no implique un traslado de PDCP: la configuración PDCP de referencia forma parte de la configuración del grupo de celdas (CG) que incluye PDCP (es decir, intra-CG)

- En caso de que la reconfiguración implique un traslado de PDCP: la referencia es la configuración de PDCP forma parte de la configuración del grupo de celdas (CG) que actualmente incluye PDCP (es decir, inter-CG)

- Sin embargo, hay una configuración PDCP por DRB y aunque se mueve entre grupos de celdas se puede considerar que en ambos casos la configuración PDCP vigente es la de referencia

Como se indica en lo anterior, al cambiar el SCG (así como al cambiar el tipo de DRB) el PDCP no puede ser liberado y añadido/creado nuevamente porque esto implica una pérdida de datos inaceptable. Esto requiere que se mantenga el estado/contexto interno del PDCP. Aun así, el UE necesita tener en cuenta la configuración PDCP que es señalada por E-UTRAN. Como continúa la entidad existente de PDCP, si se utiliza la señalización completa en lugar de la señalización delta, una forma de hacerlo sería que el propio UE derivara el delta a la configuración vigente aunque E-UTRAN señalice la configuración completa. El UE puede hacer esto por la comparación de la configuración completa recibida con la configuración vigente.

Un ejemplo de este manejo de la configuración PDCP propuesto por el UE en la señalización completa y la señalización delta en un procedimiento de cambio de SCG es el siguiente. Suponiendo que: la configuración de PDCP incluye 5 campos opcionales (parámetros de configuración), es decir, de campo1 a campo5; y que el UE está actualmente configurado con campo1, campo3 y campo4.

Señalización completa: Si la E-UTRAN quiere configurar el UE con el campo1, el campo2 y el campo4, y quiere modificar el valor del campol y aplica la configuración completa, y por lo tanto señala (además del campo que indica que el UE debe liberar la configuración vigente, es decir, fullConfigSCG), la nueva configuración completa en SCG-Config. Es decir, que incluye el campo1, el campo2 y el campo4.

Sin embargo, el UE no libera la configuración PDCP vigente, sino que compara la configuración completa recibida con la configuración vigente y determina las diferencias (es decir, el delta) y los cambios correspondientes, que en este caso son: modificación del campo1 (ya que el valor recibido difiere), adición del campo2 (ya que éste no está configurado actualmente) y liberación del campo3.

Señalización Delta: Si la E-UTRAN quiere configurar el UE con el campo1, el campo2 y el campo4, y quiere modificar el valor del campo1 y aplica la señalización delta, señala (además del campo que indica el procedimiento de cambio de SCG, es decir, que el UE debe realizar una descarga de L2), los cambios en comparación con la configuración vigente de SCG, es decir, que incluye el campo1 (para indicar el nuevo valor), el campo2 (actualmente no configurado) y una indicación de que el UE debe liberar el campo3. El UE aplica estos cambios a la configuración del SCG y continúa con la entidad PDCP.

Ambos enfoques (el uso de la señalización delta y la señalización completa de los parámetros de configuración del DRB en el cambio de SCG y el cambio de tipo de DRB) parecen ser posibles, y simplemente dan lugar a diferentes ^{condiciones para desencadenar el mismo/similar comportamiento del}Ue.

La introducción de soporte para la señalización delta en el cambio de SCG y el cambio de tipo de DRB no parece introducir mucha complejidad adicional, por lo que se considera que permitir la señalización delta en el cambio de SCG. Sin embargo, el UE y los eNB que operan como MeNB y SeNBs necesitan ser configurados para soportar la señalización delta.

La Figura 8 es un gráfico de secuencia de mensajes que muestra un procedimiento de cambio de SeNB que soporta la señalización delta de acuerdo con una realización. En la etapa 1, el MeNB envía un mensaje de solicitud de adición de SeNB al SeNG de destino (T-SeNB) como mensaje AP a través de la interfaz X2. La solicitud de adición de SeNB se modifica para incluir el conjunto de SCG-Configuration de acuerdo con la configuración actualmente asignada al UE. Puede incluirse en el mensaje RRC Inter-node SCGConfigInfo incluido en el mensaje X2 AP.

En la etapa 2 el T-SeNB envía un mensaje de reconocimiento de solicitud de adición de SeNB al MeNB como mensaje AP a través de la interfaz X2. El mensaje X2 AP Acuse de Recibo de Solicitud de Adición SeNB se modifica para incluir un campo que indique que el UE debe realizar las operaciones definidas para SCG-Change, es decir, restablecer/liberar MAC, restablecer/liberar RLC y restablecer PDCP. Puede incluirse en el mensaje RRC Inter-node SCGConfig(uration) incluido en el mensaje X2 AP. El T-SeNB establece el campo fullConfigSCG indicando si el UE debe liberar la configuración SCG completa antes de aplicar la configuración SCG señalizada, es decir, indicando que no se aplique la señalización delta. Se incluye en el mensaje RRC Inter-node SCGConfig(uration) incluido en el ^mensajex2 ^{AP Acuse de Recibo de Solicitud de Adición SeNB}

En la etapa 3, el MeNB envía un mensaje de solicitud de liberación de SeNB al SeNB de origen (S-SeNB) y en la etapa 4 el MeNB envía un mensaje de reconfiguración de conexión RRC al UE a través de la interfaz aérea Uu. El mensaje RRC RRCConnectionReconfiguraton se modifica para incluir un campo que indique que el UE debe realizar las operaciones definidas para SCG-Change, es decir, restablecer/liberar MAC, restablecer/liberar RLC y restablecer PDCP. Esto puede incluirse en el RRC IE SCG-Configuration que puede incluirse en este mensaje RRC. En este caso, la configuración de SGC incluye una configuración delta que el UE aplica a la configuración PDCP vigente para la entidad PDCP que continúa. Si no se indica la señalización delta y, en cambio, RRCConnectionReconfiguraton indica una liberación y adición de SCG, el UE, en lugar de liberar la configuración SCG por sí mismo, determina el delta a partir de los parámetros de configuración totalmente señalizados, y el UE aplica este delta derivado a la configuración PDCP vigente para la entidad PDCP que continúa.

En la etapa 5 el UE envía un mensaje RRC Connection Reconfiguration Complete al MeNB a través de la interfaz aérea Uu. A continuación, el MeNB envía un mensaje de reconfiguración SeNB completa al T-SeNB a través de la interfaz X2 y, en la etapa 7, el UE lleva a cabo un procedimiento de acceso aleatorio con el T-SeNB para sincronizarse con el SeNB y obtener acceso a este.

Por lo tanto, para permitir que un UE soporte la señalización delta en el cambio de SCG y el cambio de tipo de DRB, la presente solicitud proporciona un procedimiento de un UE como se muestra en el diagrama de flujo de la Figura 9. Sin embargo, este procedimiento no está cubierto por las reivindicaciones. En este caso, en la etapa 901, el UE detecta una reconfiguración DRB señalizada que incluye un procedimiento de cambio de SCG o un cambio de tipo DRB que no incluye el traspaso. Esto puede ser por un cambio de SCG o un cambio de tipo de DRB se indica en el mensaje de reconfiguración de la conexión RRC. Por ejemplo, el campo mobilityControlInfoSCG del mensaje RRC Connection Reconfiguration puede indicar un procedimiento de cambio de SCG. En la etapa 902, se determina si se utiliza la señalización delta o si se utiliza señalización completa. Si se utiliza señalización delta, en la etapa 903 el UE aplica los cambios señalados recibidos en comparación con los parámetros de configuración SCG actuales para actualizar los parámetros SCG almacenados. El procedimiento comprende además: descarga de la capa 2 de Unidades de Datos de Servicio, SDU; liberación y adición de la entidad SCG-MACel restablecimiento de la entidad SCG-RLC; y continuación y restablecimiento de la entidad PDCP para el SCG DRB que se establece.

Alternativamente, si en la etapa 902 se determina que la señalización de configuración SCG completa se recibe tras un procedimiento de cambio de SCG o cambio de tipo de DRB que no incluya traspaso (por ejemplo, mediante la recepción de una instrucción de liberación y adición de SCG en virtud de un campo fullConfigSCG del mensaje de reconfiguración de DRB), en la etapa 904 el UE continúa y restablece la entidad PDCP para el DRB SCG que se ha establecido. En la etapa 905 el UE determina, a partir de la configuración SCG completa señalada, el delta (es decir, los cambios) de la configuración PDCP vigente necesarios para reconfigurar el PDCP. En la etapa 906 el UE aplica los cambios determinados.

Del mismo modo, para permitir que un eNB que actúa como MeNB soporte la señalización delta en el cambio de SCG y el cambio de tipo de DRB, la presente solicitud proporciona un procedimiento de un eNB. En este caso, el eNB transmite la señalización de un procedimiento de reconfiguración de un DRB al cambiar el SCG o el tipo de DRB. Si el eNB y el SeNB de destino admiten la señalización delta en caso de cambio de SCG o de tipo de DRB sin incluir el traspaso, la señalización del eNB indica un procedimiento de cambio de SCG o de tipo de DRB sin incluir el traspaso y el eNB señala el delta (es decir, los cambios) en comparación con los parámetros de configuración del SCG vigente. El propio eNB deriva el delta. La indicación para que el UE realice las operaciones definidas para el cambio de SCG (es decir, restablecer/liberar MAC, restablecer/liberar RLC y restablecer PDCP) puede comprender el uso del campo mobilityControlInfoSCG del mensaje de reconfiguración de la conexión RRC.

Si el eNB y el SeNB de destino no soportan la señalización delta en el cambio de SCG o el cambio de tipo de DRB que no incluya el traspaso, el eNB puede señalar una configuración SCG completa y una indicación de que una configuración SCG existente debe ser liberada antes de aplicar la configuración SCG señalada. Por ejemplo, el campo fullConfigSCG puede utilizarse para indicar al UE que libere toda la configuración SCG antes de aplicar una configuración SCG señalizada. La indicación para que el UE libere toda la configuración SCG antes de aplicar una configuración SCG señalizada puede ser recibida desde y/o generada por un SeNB.

El MeNB puede transmitir además a un SeNB de destino la configuración SCG tras el cambio de SCG inter-SeNB (es decir, dentro del mensaje de solicitud de adición de SeNB que envía al SeNB de destino).

Tras un cambio de MeNB, el MeNB puede transmitir además a un MeNB de destino la configuración SCG en el traspaso inter-MeNB (es decir, dentro del mensaje X2 AP Solicitud de Traspaso que envía al MeNB de destino. Esto se incluye en el mensaje RRC inter-nodo HandoverPreparationInformation que está contenido en este mensaje X2 AP).

Cabe destacar que el parámetro fullConfig fue introducido para soportar la movilidad hacia un nodo que soporta el ASN.1 de una versión de protocolo inferior. Este nodo recibe una configuración que incluye una extensión no comprendida. Como el nodo no puede generar la señalización normal utilizada para liberar la funcionalidad asociada a dichas extensiones, se ha introducido un campo que simplemente indica que el UE debe liberar toda la configuración (fullConfig). En el caso de traspaso hacia un SeNB que soporta una versión tardía del protocolo a un SeNB que soporta una versión temprana (es decir, REL-12) se puede utilizar una solución similar, es decir, que el SeNB de destino puede decidir que el UE debe liberar toda la configuración SCG. Por lo tanto, cuando se admite la señalización delta tras el cambio de SCG, se supone que el SeNB es el nodo adecuado para decidir el parámetro fullConfigSCG, como se ha descrito anteriormente.

Actualmente se definen tres procedimientos diferentes de reconfiguración de SCG a) reconfiguración normal de SCG, b) reconfiguración sincrónica de SCG, es decir, se incluye un campo que indica que el UE debe realizar un acceso aleatorio (RA) hacia la PSCell, c) cambio de SCG, es decir, un procedimiento que implica la liberación y adición del SCG, es decir, que incluye la descarga de la capa 2 (y también implica RA hacia la PSCell). En cuanto a MCG no hay opción de realizar RA sin realizar la descarga de la capa 2, se puede debatir la necesidad de soportar la opción b). En caso de que se elimine esta opción, el campo que actualmente se supone que indica que el UE debe realizar RA, es decir, mobilityControlInfoSCG, de hecho puede utilizarse para indicar que el UE debe realizar un cambio de SCG, como se ha descrito anteriormente.

Se ha llevado a cabo un análisis que determina el comportamiento completo del UE tras el traspaso, el cambio de SCG y/o el cambio de tipo de DRB, y que se expone en la Tabla 2 a continuación. Cabe destacar que la tabla sólo describe las acciones del equipo de usuario y se basa en la suposición de que, al liberar una entidad RLC, el equipo de usuario se desprende de las capas superiores. Es importante señalar que la Tabla 2 también cubre el caso en el que se utiliza la señalización completa al cambiar el SCG, así como al cambiar el tipo de DRB. A continuación se exponen algunas observaciones sobre las declaraciones adicionales a introducir si se utilizara la señalización delta.

En caso de que haya una operación de UE aplicable en cada celda de una fila/columna, este comportamiento se incluye en la celda del borde, es decir, en la celda más a la izquierda/superior respectivamente.

Tabla 2

[Tabla 2]

Tabla 2. Establecimiento de comportamiento completo de UE

No parece haber una necesidad real de mover el tráfico hacia SCG inmediatamente después del traspaso, mientras que mover el tráfico en la otra dirección parece algo importante de soportar (ya que el SeNB de destino puede no ser capaz de admitir los mismos DRB). Esto último también puede debatirse, dado que en RAN2 se acordó anteriormente que el cambio de SCG inter-SeNB en el traspaso no es realmente esencial para REL-12.

En consecuencia, todos los casos de la tabla deben ser compatibles con la CC, con las siguientes excepciones. Las celdas sombreadas corresponden a casos inexistentes. Los casos en los que se realiza un establecimiento de SCG en el que el tipo de DRB cambia de MCG a SCG o se divide pueden requerir soporte, por ejemplo, si se quiere evitar un SCG sin DRB. Los casos en los que se realiza un cambio de SCG (como parte de un traspaso o de otro modo) en los que el tipo de DRB cambia de MCG a SCG o se divide no parecen esenciales de soportar, pero podrían ser soportados si no introducen una complejidad adicional. Los casos en los que se realiza un cambio de SCG (como parte de un traspaso o de otro modo) en los que el tipo de DRB cambia entre SCG y división no requieren ser soportados en Rel-12.

Con referencia a la Tabla 2, se puede observar que la acción "específica de celda" (es decir, la acción que no se aplica comúnmente a todas las celdas de la fila/columna en cuestión) sólo incluye los siguientes elementos:

- Restablecimiento de PDCP, restablecimiento parcial de PDCP

- Restablecimiento de MCG-RLC (aunque no es necesario, esta operación puede realizarse siempre en el momento del traspaso, es decir, cuando se libera la entidad MCG-RLC, sin un efecto perjudicial significativo)

- La liberación/adición de la entidad SCG-RLC tras el cambio de SCG (con/sin traspaso) se aplica obviamente sólo en caso de que la configuración vigente incluya una entidad SCG-RLC (es decir, no para MCG DRB). Esto puede reflejarse en la fila superior.

Teniendo esto en cuenta, la tabla del comportamiento completo de UE puede simplificarse, como se muestra en la Tabla 3.

Tabla 3

[Tabla 3]

Varias acciones realizadas en el traspaso ya están cubiertas por la especificación de procedimiento vigente, es decir, PDCP: restablecer, MCG-MAC: reajustar, MCG-RLC: restablecer.

Varias de las acciones indicadas en la tabla son las acciones normales que se realizan al recibir el campo que indica la acción en cuestión (lo que significa que en la especificación del procedimiento ya está implícitamente cubierto por la especificación del procedimiento): XCG-MAC liberar/añadir, XCG-RLC liberar/añadir, trayectoria PDCP UL (trayectoria de datos). Si este es el caso de la liberación de MCG-RLC al cambiar el tipo de DRB depende de los detalles de señalización reales. Se supone que al cambiar de División a SCG-DRB, la señalización indica la liberación de SCG-RLC. En caso de que se utilice la señalización delta al cambiar el SCG (lo que significa que los campos RLC y MAC no se liberan ni se añaden), es necesario introducir declaraciones que reflejen que el SCG-MAC se restablece y el SCG-RLC también.

Teniendo en cuenta lo anterior, la especificación de procedimiento sólo necesita cubrir adicionalmente las acciones del UE subrayadas en la Tabla 3 Simplificada anterior. El UE realiza (asumiendo la señalización completa en el cambio de SCG y el cambio de tipo de DRB):

- Restablecimiento de PDCP al cambiar el tipo de DRB MCG ^ SCG, división ^ SCG, así como de SCG DRB al cambiar SCG

- Restablecimiento parcial de PDCP al cambiar el tipo de DRB dividido ^ MCG tras reconfiguración diferente a HO, así como de DRB dividido al cambiar de SCG

Así, la presente solicitud proporciona un procedimiento de un UE que tiene acciones adicionales especificadas para especificar completamente las acciones del UE requeridas para realizar procedimientos de reconfiguración de d Rb y cambios de tipo de DRB en DC. Es decir, el UE, al detectar la reconfiguración de un DRB que tiene o cambia a un tipo de DRB dividido o DRB SCG, si la reconfiguración incluye: un tipo de procedimiento de reconfiguración que no incluya el traspaso para DRB en el que el tipo de DRB cambia entre (a) un DRB dividido o un DRB MCG; y (b) un DRB SCG; o un procedimiento de cambio SCG para un DRB SCG; el UE restablece la entidad PDCP para el DRB en cuestión. Alternativamente, o además, el UE, al detectar la reconfiguración de un DRB que tiene o cambia a un tipo de DRB dividido o DRB SCG, si la reconfiguración incluye: un tipo de procedimiento de reconfiguración que no incluye el traspaso para DRB en el que el tipo de DRB cambia de un DRB dividido a un DRB MCG en el que los datos DL se reciben sólo de las celdas servidoras de un MCG; o un procedimiento de cambio de SCG para un DRB dividido; el UE restablece parcialmente la entidad PDCP para el DRB en cuestión.

La operación de restablecimiento parcial de PDCP que ha sido identificada como necesaria puede ser realmente innecesaria. Se ha observado que, en realidad, puede ser mejor evitar la complejidad adicional de introducir este restablecimiento parcial de PDCP y, en cambio, activar siempre un restablecimiento completo de PDCP en los casos que actualmente se supone que activan un restablecimiento parcial de PDCP. Esto puede lograrse si un UE configurado con un DRB dividido realiza un restablecimiento PDCP regular (al igual que en el caso de HO sin DC) cuando el DRB se cambia a MCG DRB, así como al cambiar el SCG. De hecho, en estos casos, si se produce una reconfiguración que incluye: un tipo de procedimiento de reconfiguración que no incluye el traspaso para DRB en el que el tipo de d Rb cambia de un DRB dividido a un DRB MCG en el que los datos d L se reciben sólo de las celdas servidoras de un MCG; o un procedimiento de cambio de SCG para un DRB dividido, el MeNB puede iniciar los procedimientos de traspaso y señalar al UE adecuadamente (por ejemplo, incluyendo el campo mobilityControllnfo en el mensaje de reconfiguración de la conexión RRC).

Así, la presente solicitud proporciona una alternativa al restablecimiento parcial de PDCP, en la que un UE está configurado de manera tal que si se produce una reconfiguración que incluye: un tipo de procedimiento de reconfiguración que no incluye el traspaso para DRB en los que el tipo de DRB cambia de un DRB dividido a un DRB MCG; o un procedimiento de cambio de SCG para un DRB dividido; y se recibe señalización que indica procedimientos de traspaso; entonces el UE realiza los procedimientos indicados para el traspaso.

Dada la señalización y los procedimientos anteriores necesarios para configurar y reconfigurar un UE con CC, es deseable un mecanismo de señalización eficiente entre la E-UTRAN y el UE. En el caso de que E-UTRA configure un equipo de usuario con doble conectividad, la configuración radioeléctrica dedicada del equipo de usuario comprende 2 partes: una configuración MCG y una configuración SCG. El MeNB tiene la responsabilidad general de establecer los parámetros de configuración del UE y, en particular, controla exclusivamente la configuración del MCG. El SeNB generalmente decide los valores de los parámetros de configuración del SCG, pero el MeNB puede especificar algunas restricciones/limitaciones que debe observar el SeNB para garantizar que la combinación de la configuración del MCG y del SCG no exceda las capacidades del UE. Generalmente, la configuración de SCG señalada al UE es generada por el SeNB. Sin embargo, hay algunas excepciones en las que la configuración de la SCG, tal y como se señala, es generada por el MeNB. Por ejemplo:

- El MeNB puede generar un campo que indique que el UE debe liberar todo el SCG.

- El MeNB señala el Contador de Celdas Pequeñas (SCC) que el UE utiliza cuando deriva la clave de seguridad asociada a SCG (es decir, S-KeNB) a partir de la clave de seguridad asociada al MCC/ MeNB

- El MeNB puede decidir liberar un DRB dividido, en cuyo caso es necesario liberar las partes MCG y SCG de la configuración del DRB. No está del todo claro qué nodo generaría la liberación de la parte de configuración del SCG en tal caso, pero puede ser beneficioso que el MeNB pueda hacerlo.

Una opción de señalización que se ha identificado es que el MeNB actualice los campos de la configuración SCG recibida del SeNB. En esta opción, el SeNB envía los parámetros de configuración SCG (denominados Elemento de Información (IE) SCG-Configuration) en un contenedor a través de X2 (por ejemplo, en una cadena de octetos) a MeNB. El IE SCG-Configuration incluye parámetros que son establecidos por el MeNB, por ejemplo, el SCC, fullConfigSCG. El SeNB no establece estos parámetros, o los establece con un valor ficticio. Este parámetro está en la parte original REL-12 de la IE SCG-Configuration. Esto significa que cualquier MeNB que soporte la Conectividad Dual puede establecer el parámetro incluso si el SeNB añade extensiones a la Configuración SCG IE. El MeNB incluye la IE SCG-Configuration recibida en un contenedor (por ejemplo, en una cadena de octetos) a través de la interfaz Uu hacia el UE (es decir, en el mensaje RRCConnectionReconfiguration). El uso de este contenedor hace posible que el MeNB reenvíe cualquier extensión que el SeNB haya incluido, aunque el MeNB no la comprenda. El MeNB establece los parámetros de la SCG en esta SCG-Configuration que decide, por ejemplo, la SCC, fullConfigSCG. El siguiente ASN.1 especifica este enfoque.

— ASNISTART^

R R C C o n n e c tio n R e c o n fig u ra tio n -v l2 x y -IE s : := SEQUENCE

-+ s e g - C o n f ig u r a t i c n - r l2 - » -*-+-* OCTET-5TRIN6 • (SC G -C onfiguration-rl2)-O PT IO N W L , - — Need ON*-*

n o n C r i t i c a l E x t e n s i o n •-* -♦ -* SEQUENCE {} -+ -♦ -* -♦ OPTION&l^

)<-’

S C G -C o n f ig u ra tio n -r l2 -* -♦ CHOICE {<•'

r e le a s e - * •••* ■■■* NUIL,*-'

-* s e tu p - * - * - * - * - > - > - * ■ - * SEQUENCE • {«-•

-* -+ — -FFS how to i n d í c a t e r e l e a s e an d a d d i t i o n i n s i n g l e r e c o n f i g u r a t io n ( i . e . change o f SeNB)

fu llC o n fig S C G -r 12 - * ■ -*■ •••* -♦ ENUMERAIED { tru e} -* -*■ O P T IO N A L ,C o n d SCG-Cha^'

-* -♦ sec u rity C o n f ig S C G -rl2 -* - - * - * - » S ecu rity C o n fig S C G -rl2 -» - -*■ OPTIONM»,^— Cond SCG-Est*-'

-•* * rad ioR esourceC cnfigD ed ica tedS C G -rl2 -*R ad ioR esourceC onfigD ed icatedS C G -rl2 -* -O P T IO N A L ,;— Cond SCG-E at« :

— FFS i s t h e r e - is -a -need - f o r s C e llT c R e le a se L is tS C G -o r w h e th e r - t h i s i s -done by MCG c o n f ig ^

s C e l lT o R e le a s e L is tS C 5 - r l2 S C e llT o R e le a se L is t-r lO -* -»■ OFTIONftL,*— Need 0N+-’

sC ellT oA ddM odL iatSC G -rl2 -+ -♦ S C ellT o A d d M o d L ist-r lO -♦ -* O F T IO N A L ,C o n d SCG -Est^

— FFS how t o i n d í c a t e UE s h a l l a p p ly RA i n SCG and w hat t o signal-*-1

m o b ili ty C c n tro I XnfoSCG- r l 2 ■** -■* M obil í t y Con t r o 1 Xnf oSCG- r l 2~*QPXI0NAL”* Cond SCG- E o t<-1

S e c u r i t y C o n f i g S C G - r l 2 - SEQUENCE

-* s c g - C c u n t - r l 2 -*-*-*- INTEGER ( 0 . . 65535 ) ,+>

-* c i p h e r i n g A l g o r i t h r a S C G - r l 2 C i p h e r i n g A l g o r i t h m - r l 2 ,

}*

Sin embargo, como en este enfoque de señalización Uu, el SeNB debe tratar algunos de los campos (por ejemplo, fullConfigSCG y scg-Count) más o menos como campos ficticios, el MeNB no puede reenviar de forma transparente la información recibida por el SeNB, sino que necesita decodificar y recodificar la información recibida del SeNB antes de la señalización al UE.

Un enfoque alternativo consiste en que el MeNB reenvíe los parámetros de configuración de la SCG que decida al SeNB, que posteriormente los incluye en SCG-Configuration. Esta última variante permite al MeNB reenviar de forma transparente la información de configuración del SCG recibida del SeNB.

En algunos casos puede ser realmente el SeNB el que establezca fullConfigSCG, es decir, cuando la señalización delta es soportada tras el cambio de SCG. En estos casos, el SeNB puede decidir, por ejemplo, cuando la configuración SCG recibida incluye extensiones no comprendidas, aplicar la señalización full en lugar de la delta (es decir, por las mismas razones que para la fullConfig normal).

En vista de lo anterior, se desvela en la presente memoria una opción de señalización alternativa que permite el simple reenvío transparente por parte del MeNB de los parámetros de configuración de SCG recibidos del SeNB sería aquella en la que puede añadir IE adicionales en el mensaje al UE. En esta opción de señalización Uu, el SeNB envía los parámetros de configuración SCG (denominados elemento de información SCG-Configuration) en un contenedor sobre X2 (por ejemplo, en una cadena de octetos). El IE SCG-Configuration enviado al UE consiste en dos partes: una primera parte establecida por el MeNB y una segunda parte representada por el campo scg-ConfigurationPart2, que contiene los parámetros establecidos por el SeNB.

En este enfoque, sólo la segunda parte se transporta en un contenedor, y el MeNB puede reenviar esta parte de la configuración SCG que se recibe del SeNB de forma transparente al UE. El siguiente ASN.1 especifica este enfoque de señalización en dos partes.

— ASNlSTAPT

R R C C o n n e c tio n R e c o n fig u ra tio n -v l2 x y -IE s : := SEQUENCE

-+■ scg -C c n f ig u r a t ic n - r - 12 -* ~+ CCTET -STRING -(S C G -C o n f ig u ra tío n -r !2 ) -¡OPTIONAL,

-* n o n C r i t ic a lE x te n s io n -* SEQUENCE {} OPTIONSL*J

S C G -C o n f ig u ra tic n - r !2 -: := -+ -♦ CHOICE - {

-♦ r e le a s e -i-*-*-* - - * NUIL,^

-» 3 e tu p - * - * - * - * -* -* - SEQUENCE {*-’

-+ -* s c g - C c n f i g P a r t l - r l 2 -+ -* - -* SEQUENCE - {

^{-* •* fu llC o n f igSC G -rl2-» •* -}-* ENUMERATED {true}-* -*• OPTIONAL,*— Cond SCG-Cha^

" ■ “* - * s e c u rity C o n f ig S C G -rl2 -* - -♦ -► S e c u r ity C o n f ig S C G -P a r t l - r l2 O P n 0 N A I ,í—--Ccnd-SCG-Est*--* -* -* -+ -* -* OPTIONAL,..........— Need

ON,

a c g - C o n f ig P a r t2 - r l2 CCTET STRING {SCG-Conf i g u r a t i o n P a r t 2 - r l 2 ) OPTIONAL,-- Need

S C G - C o n f i g u r a t i o n P a r t 2 - r l 2 : : = -#■ SEQUENCE {~

- 9- — FFS h o v - t o i n d í c a t e - r e l e a s e -and - a d d i t i o n - in - s in g l e •r e c o n f i g u r a t io n • ( i . e . - change o f • SeNB) *~

-* sec u rity C o n fig 5 C G -rl2 -* * -+->-+ S e c u r ity C o n f ig S C G -P a r t2 - r l2 í -* OPTIONAL,»— Cond SCG-Est»-1

ra d io R e so u r ceC onfigD edicatedSC G -rl2-~*R adioR escurceC onf ig D e d ic a tedS C G -r 12 OPTIONAL, — Cond SCG-Est*--+ — FFS i s t h e r e -ia -a n e e d f o r sC e llT o R e lease L is tS C G o r w h e th e r t h i s is-done-by-M C G ■ c o n f ig v

-■» s C e llT o R e le a se L is tS C G -r!2 -♦ -■-*■ S C e llT o R e le a s e L is t - r lO » -+ OPTIONAL — Need ON<‘

-*■ sC ellToA ddM odListSC G -rl2 -* S C ellT oA ddM odL ist-rlO -+ --*• OPTIONAL, Cond - SCG-Est*-’

-* — -FFS h o v to i n d i c a r e UE - s h a l l a p p ly R A -inSC G an d w h a t- to s í g n a l a

9 r a o b il i ty C o n tr o lI n fc S C G -r l2 * ♦ 9 H o b i l i ty C o n tro lIn f o S C G -r l2 »OPTIONAL Cond SCG -Est^

K

S e c u r i t y C o n f i g S C G - P a r t l - r l 2 • : : = * SEQUENCE • {*

-* s c g - C o u n t - r l 2 -* - -* • ~* -* INTEGER -( 0 . . -65535 ) ,+>

S e c u r i t y C c n f i g S C G - P a r t 2 - r l 2 - : :=-* SEQUENCE { --#• c i p h e r in g A lg o r i t h r & S C G - r l2 -* C i p h e r i n g A l g o r i t h m - r 12 ,

El ASN.1 anterior ilustra que con ambos enfoques de señalización Uu, todos los parámetros de configuración SCG se señalizan juntos en una estructura, lo que facilita la liberación de todos los parámetros de una sola vez.

Con ambos enfoques, el uso de contenedores permite al nodo receptor reenviar la información recibida del eNB de origen sin tener que comprender la información completa (es decir, incluyendo todas las extensiones introducidas en versiones posteriores) generada por el nodo de origen.

El primer enfoque de señalización Uu implica, sin embargo, que el MeNB necesita decodificar y recodificar la información recibida del SeNB, lo que supone un inconveniente. Una ventaja del segundo enfoque de señalización Uu en el que se utilizan dos partes es que es posible reenviar de forma transparente la información recibida del SeNB. Además, con el segundo enfoque, la información enviada al equipo de usuario se divide en función del nodo de la red que establece la información.

Por lo tanto, para permitir que la E-UTRAN configure el UE con CC en el que el MeNB puede reenviar de forma eficiente y transparente los parámetros de configuración SCG recibidos del SeNB, la presente solicitud proporciona un procedimiento de un UE que incluye la recepción de señalización de una configuración DRB que incluye parámetros de configuración SCG proporcionados juntos en una única estructura de información que comprende dos partes: una primera parte que incluye parámetros de configuración SCG generados por el MeNB; y una segunda parte que incluye parámetros de configuración SCG generados por el SeNB. Se proporciona un contenedor (tal como una cadena de octetos) alrededor de los parámetros de la primera y la segunda parte o se proporciona un contenedor alrededor sólo de los parámetros de la segunda parte.

La presente solicitud también proporciona un procedimiento de un eNB, que actúa como el MeNB, que incluye la transmisión de la señalización de una configuración de un DRB, la configuración del DRB señalizada incluye parámetros de configuración SCG proporcionados juntos en una única estructura de información que comprende dos partes: una primera parte que incluye parámetros de configuración SCG generados por el MeNB; y una segunda parte que incluye parámetros de configuración SCG generados por el SeNB. Las dos partes de los parámetros de configuración SCG transmitidos se proporcionan en conjunto en una única estructura de información. El MeNB establece la primera parte de los parámetros de configuración SCG y recibe la segunda parte de los parámetros de configuración SCG del SeNB, y transmite al UE los parámetros de configuración SCG proporcionados en una única estructura de información que comprende las dos partes.

En un ejemplo no cubierto por las reivindicaciones, se proporciona un contenedor alrededor de los parámetros de las primeras y segundas partes. En este caso, el MeNB transmite la primera parte de los parámetros de configuración SCG al SeNB, y recibe del SeNB y reenvía de forma transparente al UE los parámetros de configuración SCG proporcionados en una única estructura de información que comprende las dos partes. Alternativamente, el MeNB puede decodificar los parámetros de configuración SCG de la segunda parte y recodificar los parámetros de configuración SCG de la primera y segunda parte, al colocarlos en conjunto en un contenedor antes de transmitir los parámetros de configuración SCG al UE.

En otro ejemplo no cubierto por las reivindicaciones, se proporciona un contenedor alrededor de sólo los parámetros de la segunda parte. En este ejemplo, el MeNB recibe la segunda parte de los parámetros de configuración SCG desde el SeNB, y los reenvía de forma transparente al UE, colocados dentro de un contenedor y que junto con la primera parte de los parámetros de configuración SCG se proporciona en una única estructura de información que comprende las dos partes.

Además, la presente solicitud proporciona un eNB que actúa como un SeNB que incluye la transmisión de parámetros de configuración, para uso en la señalización de una configuración de un d Rb , los parámetros de configuración del DRB transmitidos comprenden parámetros de configuración de SCG generados por el SeNB. Los parámetros de configuración del DRB se transmiten al MeNB a través de la interfaz X2. El SeNB recibe los parámetros de configuración SCG generados por el MeNB y proporciona los parámetros de configuración DRB transmitidos juntos en una única estructura de información que comprende dos partes: una primera parte que incluye los parámetros de configuración SCG generados por el MeNB; y una segunda parte que incluye los parámetros de configuración SCG generados por el SeNB.

Otro aspecto de la conectividad dual en el que la presente solicitud proporciona una propuesta de alteración del comportamiento del UE es evitar los retrasos de transferencia en la detección de un fallo de enlace de radio (RFL) o la liberación de un SCG DRB, como se explicará a continuación.

Cuando se detecta la RLF de un SCG (SCG-RLF), la comunicación de datos a través del SCG es imposible dado que el UE suspende la transmisión del enlace ascendente a través del SCG. Además, el UE informa el problema al MeNB. Actualmente, hasta que el MeNB haya resuelto el problema, los paquetes transferidos a través de los DRB para los que los datos se transfieren (parcialmente) a través del SCG sufren un mayor retraso en la transferencia. Para evitarlo, al detectar la liberación de SCG-RLF o SCG, el UE inicia la reconfiguración autónoma de los DRB cuyos datos se transfieren (parcialmente) a través del SCG. Por ejemplo, al detectar SCG-RLF, el UE reconfigura de forma autónoma los DRB divididos a MCG DRB liberando la entidad SCG-RLC asociada y asociando el canal lógico SCG. En otro ejemplo, al detectar SCG-RLF, el UE reconfigura de forma autónoma uno o más SCG DRB a MCG DRB liberando la entidad SCG-RLC asociada y el canal lógico SCG asociado mientras establece una nueva entidad MCG con una configuración por defecto. El PDCP asociado se restablece (al igual que en el traspaso) y se reconfigura a una configuración por defecto. La configuración por defecto puede ser una configuración especificada en la norma, o la configuración utilizada en el SCG, o la última configuración utilizada en el MCG para el mismo portador EPS (es decir, antes de que se cambiara a SCG DRB).

Por otra parte, la configuración por defecto puede ser diferente para las distintas partes del protocolo (PDCP, RLC, canal lógico).

Por ejemplo, la Tabla 4 a continuación muestra una ilustración de que para diferentes partes del protocolo se puede utilizar un valor predeterminado diferente.

Tabla 4

[Tabla 4]

Tabla 4. Ejemplo de configuración por defecto por parte de protocolo en la reconfiguración autónoma

Para utilizar la configuración utilizada en SCG como predeterminada, MeNB necesita conocer la configuración vigente de SCG. Como el SeNB siempre señala esto a través del MeNB, MeNB siempre debe tener la última configuración SCG. Sin embargo, puede ser que el SeNB configure extensiones no comprendidas por MeNB. Si este es el caso, el MeNB puede decidir utilizar otro valor por defecto, por ejemplo, el valor por defecto especificado en la norma, o puede indicar que el UE debe liberar toda la extensión más allá de una determinada versión del protocolo. Como el objetivo de las acciones autónomas del UE es evitar el aumento de los retrasos de transferencia, esto debe configurarse antes de que se detecte el SCG-RLF (es decir, si estuviera en un mensaje por el que el MeNB indica que el UE está autorizado a reanudar la transferencia de datos a través de los antiguos s Cg DRB, el objetivo principal sería derrotado). Por lo tanto, el MeNB debe indicar qué configuración por defecto debe aplicar el UE, lo que se hace antes de la liberación del SCG-RLF o del SCG. Cuando el MeNB indica que la configuración utilizada en la SCG es la predeterminada, puede indicar adicionalmente que, al aplicar esta predeterminada, el UE libera todas las extensiones más allá de una determinada versión del protocolo, si está configurada.

En caso de que E-UTRAN libere SCG, el UE puede realizar las mismas operaciones de reconfiguración autónoma definidas para la detección de SCG-RLF. Esto significa que la red sólo tiene que configurar cualquier cambio en comparación con las configuraciones (por defecto) resultantes de las reconfiguraciones autónomas del UE. Esto puede reducir la señalización al liberar el SCG, ya que el MeNB puede limitarse a señalar la nueva configuración al liberar el SCG.

Se apreciará que las realizaciones de la presente invención pueden realizarse en forma de hardware, software o una combinación de hardware y software. Dicho software puede almacenarse en forma de almacenamiento volátil o no volátil, por ejemplo, un dispositivo de almacenamiento tal como una ROM, ya sea borrable o reescribible o no, o en forma de memoria, por ejemplo, RAM, chips de memoria, dispositivo o circuitos integrados o en un medio legible óptica o magnéticamente, por ejemplo, un CD, DVD, disco magnético o cinta magnética o similares. Se apreciará que los dispositivos de almacenamiento y los medios de almacenamiento son realizaciones de almacenamiento legible por máquina que son adecuadas para almacenar un programa o programas que comprenden instrucciones que, cuando se ejecutan, implementan realizaciones de la presente invención. En consecuencia, las realizaciones proporcionan un programa que comprende un código para implementar un aparato o un procedimiento como se reivindica en cualquiera de las reivindicaciones de esta especificación y un almacenamiento legible por máquina que almacena dicho programa. Más aún, dichos programas pueden ser transmitidos electrónicamente a través de cualquier medio, incluyendo una señal de comunicación llevada a cabo a través de una conexión cableada o inalámbrica, y las realizaciones abarcan adecuadamente los mismos.

A lo largo de la descripción y de las reivindicaciones de esta especificación, los términos "comprenden" y "contienen" y sus variaciones significan "incluyendo pero sin limitación a", y no pretenden (ni excluyen) otros componentes, números enteros o etapas. A lo largo de la descripción y las reivindicaciones de esta especificación, el singular abarca el plural a menos que el contexto requiera lo contrario. En particular, cuando se utiliza el artículo indefinido, debe entenderse que la especificación contempla tanto la pluralidad como la singularidad, a menos que el contexto requiera lo contrario.

Los rasgos, números enteros o características descritos en relación con un aspecto, una realización o un ejemplo particular de la invención deben entenderse como aplicables a cualquier otro aspecto, realización o ejemplo descrito en la presente memoria, a menos que sean incompatibles con estos. Todas las características desveladas en esta especificación (incluidas las reivindicaciones, el resumen y los dibujos adjuntos), y/o todas las etapas de cualquier procedimiento o proceso desvelado, pueden combinarse en cualquier combinación, excepto las combinaciones en las que al menos algunas de dichas características y/o etapas son mutuamente excluyentes. La invención no se limita a los detalles de las realizaciones anteriores. La invención se extiende a cualquier novedad, o cualquier combinación novedosa, de las características desveladas en esta especificación (incluyendo las reivindicaciones, el resumen y los dibujos adjuntos), o a cualquier novedad, o cualquier combinación novedosa, de las etapas de cualquier procedimiento o proceso desvelado. También se apreciará que, a lo largo de la descripción y las reivindicaciones de esta especificación, el lenguaje en la forma general de "X para Y" (en el que Y es alguna acción, actividad o etapa y X es algún medio para llevar a cabo esa acción, actividad o etapa) abarca los medios X adaptados o dispuestos específicamente, pero no exclusivamente, para hacer Y.

Las realizaciones anteriores deben entenderse como ejemplos ilustrativos de la invención. Se prevén otras realizaciones de la invención. Debe entenderse que cualquier característica descrita en relación con cualquier realización puede utilizarse sola, o en combinación con otras características descritas, y también puede utilizarse en combinación con una o más características de cualquier otra de las realizaciones, o cualquier combinación de cualquier otra de las realizaciones.

Claims

REIVINDICACIONES

1. Un procedimiento realizado por una estación base maestra para proporcionar conectividad dual a un terminal (600), en un sistema de comunicación inalámbrica, el procedimiento comprendiendo:

transmitir, a una estación base secundaria, un mensaje de solicitud de adición que incluye una configuración vigente de grupo celular secundario, SCG, configurada para el terminal;

recibir, desde la estación base secundaria, un mensaje de acuse de recibo para un cambio de SCG del terminal, el mensaje de acuse de recibo incluyendo una nueva configuración de SCG configurada para el terminal por la estación base secundaria e información que indica si el terminal debe liberar la configuración de SCG vigente antes de aplicar la nueva configuración de SCG; y

transmitir, al terminal, un mensaje de control de recursos de radio, RRC, para el cambio de SCG, el mensaje RRC incluyendo la nueva configuración SCG configurada al terminal por la estación base secundaria.

2. El procedimiento de la reivindicación 1,

en el que, en un caso de que el mensaje RRC incluya además la información que indica si el terminal debe liberar la configuración SCG vigente antes de aplicar la nueva configuración SCG, la configuración SCG vigente se libera y el terminal aplica la nueva configuración SCG; y

en el que, en un caso en que el mensaje RRC no incluya la información que indica si el terminal debe liberar la configuración SCG vigente antes de aplicar la nueva configuración SCG, se reutiliza para el terminal una configuración del protocolo de convergencia de datos de paquetes, PDCP, asociada a la configuración SCG vigente.

3. El procedimiento de la reivindicación 1,

en el que una clave de seguridad asociada a un SCG se deriva en base a un valor de contador incluido en el mensaje RRC y una clave de seguridad asociada a la estación base maestra, y

en el que el mensaje RRC se utiliza para restablecer al menos una de las entidades PDCP o una entidad de control de radioenlace, RLC.

4. Un procedimiento realizado por una estación base secundaria para proporcionar conectividad dual a un terminal (600), en un sistema de comunicación inalámbrica, el procedimiento comprendiendo:

recibir, desde una estación base maestra, un mensaje de solicitud de adición que incluye una configuración vigente de grupo celular secundario, SCG, configurada para el terminal; y

transmitir, a la estación base maestra, un mensaje de acuse de recibo para un cambio de SCG del terminal, el mensaje de acuse de recibo incluyendo una nueva configuración SCG configurada para el terminal por la estación base secundaria e información que indica si el terminal debe liberar la configuración SCG vigente antes de aplicar la nueva configuración SCG.

5. Una estación base maestra para proporcionar conectividad dual a un terminal (600), en un sistema de comunicación inalámbrica, la estación base maestra que comprendiendo:

un transceptor; y

un controlador acoplado al transceptor y configurado para controlar para:

transmitir, a una estación base secundaria, un mensaje de solicitud de adición que incluya una configuración vigente de grupo celular secundario, SCG, configurada para el terminal,

recibir, de la estación base secundaria, un mensaje de acuse de recibo para un cambio de SCG del terminal, el mensaje de acuse de recibo incluyendo una nueva configuración de SCG configurada para el terminal por la estación base secundaria e información que indica si el terminal debe liberar la configuración de SCG vigente antes de aplicar la nueva configuración de SCG, y

transmitir, al terminal, un mensaje de control de recursos de radio, RRC, para el cambio de SCG, el mensaje RRC incluyendo la nueva configuración de SCG configurada al terminal por la estación base secundaria.

6. La estación base principal de la reivindicación 5,

en la que, en un caso en que el mensaje RRC incluya además la información que indica si el terminal debe liberar la configuración SCG vigente antes de aplicar la nueva configuración SCG, la configuración SCG vigente se libera y la nueva configuración SCG es aplicada por el terminal, y

en la que, en un caso en que el mensaje RRC no incluya la información que indica si el terminal debe liberar la configuración SCG vigente antes de aplicar la nueva configuración SCG, se reutiliza para el terminal una configuración del protocolo de convergencia de datos de paquetes, PDCP, asociada a la configuración SCG vigente.

7. La estación base maestra de la reivindicación 5,

en la que una clave de seguridad asociada a un SCG se deriva en base a un valor de contador incluido en el mensaje RRC y una clave de seguridad asociada a la estación base maestra, y

en la que el mensaje RRC se utiliza para restablecer al menos una de las entidades PDCP o una entidad de control de enlace de radio, RLC.

8. Una estación base secundaria para proporcionar conectividad dual a un terminal, (600), en un sistema de comunicación inalámbrica, la estación base secundaria comprendiendo:

un transceptor; y

un controlador acoplado al transceptor y configurado para controlar para:

recibir, desde una estación base maestra, un mensaje de solicitud de adición que incluya una configuración vigente de grupo celular secundario, SCG, configurada para el terminal, y

transmitir, a la estación base principal, un mensaje de acuse de recibo para un cambio de SCG del terminal, el mensaje de acuse de recibo incluyendo una nueva configuración de SCG configurada al terminal por la estación base secundaria e información que indica si el terminal debe liberar la configuración de SCG vigente antes de aplicar la nueva configuración de SCG.