ES2875829T3 - Métodos, nodo de red, dispositivo inalámbrico y producto de programa informático para reanudar una conexión con configuración completa - Google Patents

Abstract

Un método en un nodo de red, el método comprende: - recibir, desde un dispositivo inalámbrico, una solicitud para reanudar una conexión en una red de comunicación; - en respuesta a la solicitud, enviar un mensaje de reanudación al dispositivo inalámbrico, caracterizándose el método porque el mensaje comprende una indicación para realizar una configuración completa.

Description

DESCRIPCIÓN

Métodos, nodo de red, dispositivo inalámbrico y producto de programa informático para reanudar una conexión con configuración completa

Solicitudes relacionadas

La presente solicitud reivindica los beneficios de la prioridad de la solicitud de patente provisional de los Estados Unidos No. 62/631467, titulada "Reanudación de ^r R^c con configuración completa", y presentada en la oficina de marcas y patentes de los Estados Unidos el 15 de febrero de 2018.

Campo técnico

La presente descripción se refiere en general a comunicaciones inalámbricas y, más particularmente, a reanudar una conexión para un dispositivo inalámbrico.

Antecedentes

Protocolo de control de recursos de radio (RRC)

Al igual que en la evolución a largo plazo (LTE), el protocolo de control de recursos de radio (RRC) se usa para configurar/establecer y mantener la conexión de radio entre el equipo de usuario (UE) y el nodo de red (por ejemplo, eNB). Cuando el UE recibe un mensaje RRC del eNB, aplicará la configuración (el término "compilar" también puede usarse para referirse a la aplicación de la configuración). Y si esto tiene éxito, el UE genera un mensaje RRC completo que indica la identidad (ID) de transacción del mensaje que activa esta respuesta.

Desde la versión de LTE (versión) 8, tres portadores de radio de señalización (SRB), a saber, SRB0, SRB1 y SRB2, han estado disponibles para el transporte de mensajes RRC y de estrato sin acceso (NAS) entre el equipo de usuario (UE) y el eNB. También se introdujo un nuevo SRB, conocido como SRB Ibis, en la versión 13 para soportar DoNAS (datos sobre NAS) en el Internet de las cosas de banda estrecha (NB-IoT).

SRB0 se usa para mensajes RRC que usan el canal lógico de canal de control común (CCCH) y se usa para manejar el establecimiento de la conexión RRC, la reanudación de la conexión RRC y el restablecimiento de la conexión RRC. Una vez que el UE está conectado al eNB (es decir, la configuración de la conexión RRC o el restablecimiento/reanudación de la conexión RRC se ha realizado correctamente), SRB1 se usa para manejar mensajes RRC (que pueden incluir un mensaje NAS superpuesto), así como para mensajes NAS antes del establecimiento de SRB2, todos usando el canal lógico de canal de control dedicado (DCCH).

SRB2 se usa para mensajes RRC que incluyen información de medición registrada y para mensajes NAS, todos usando el canal lógico DCCH. SRB2 tiene una prioridad más baja que SRB1, porque la información de medición registrada y los mensajes NAS pueden ser largos y pueden causar el bloqueo de mensajes SRB1 más urgentes y más pequeños. SRB2 siempre está configurado por la red de acceso de radio terrestre (E-UTRAN) del servicio universal de telecomunicaciones móviles evolucionado (UMTS) después de la activación de seguridad.

Conectividad dual (DC) en LTE

La red de acceso de radio terrestre de UMTS evolucionado (E-UTRAN) soporta la operación de conectividad dual (DC) mediante la cual un UE de recepción/transmisión (Rx/Tx) múltiple en RRC_CONNECTED está configurado para utilizar los recursos de radio proporcionados por dos planificadores distintos, ubicados en dos eNB conectados a través de un retorno no ideal a través de la interfaz X2 (véase 3GPP 36.300). Los eNB involucrados en DC para un determinado UE pueden asumir dos roles diferentes: un eNB puede actuar como un nodo maestro (MN) o como un nodo secundario (SN). En DC, un UE está conectado a un MN y un SN.

En DC LTE, la arquitectura del protocolo de radio que usa un portador en particular depende de cómo esté configurado el portador. Existen tres tipos de portadores: portador del grupo de células principal (MCG), portador del grupo de células secundario (SCG) y portadores divididos. El RRC se encuentra en MN y los SRB siempre se configuran como un tipo de portador MCG y, por lo tanto, solo usan los recursos de radio del MN. La figura 1 ilustra el plano de usuario de DC LTE (UP), con los 3 tipos de portadores en un UE.

Conectividad dual LTE-NR

DC LTE-NR (LTE-New Radio) (también conocido como interfuncionamiento estrecho LTE-NR) se está discutiendo actualmente para la versión 15. En este contexto, los principales cambios de DC LTE son:

la introducción del portador dividido del SN (conocido como portador dividido SCG);

la introducción del portador dividido para RRC;

la introducción de un RRC directo desde el SN (también denominado SRB de SCG).

Las figuras 2 y 3 muestran las arquitecturas UP y plano de control (CP) respectivamente para el interfuncionamiento estrecho LTE-NR.

El SN a veces se denomina SgNB (donde gNB es una estación base NR) y el MN como MeNB en caso de que LTE sea el nodo maestro y NR sea el nodo secundario. En el otro caso, donde NR es el maestro y LTE es el nodo secundario, los términos correspondientes son SeNB y MgNB.

Los mensajes RRC divididos se usan principalmente para crear diversidad, y el remitente puede decidir si elige uno de los enlaces para planificar los mensajes RRC o puede duplicar el mensaje en ambos enlaces. En el enlace descendente, la conmutación de ruta entre los tramos MCG o SCG o la duplicación en ambos se deja a la implementación de la red. Por otro lado, para UL, la red configura el UE para usar MCG, SCG o ambos tramos. Los términos "tramo" y "ruta" se usan indistintamente a lo largo de este documento.

Las siguientes terminologías se usan a lo largo de esta divulgación para diferenciar diferentes escenarios de conectividad dual:

DC: DC LTE (es decir, tanto MN como SN emplean LTE);

EN-DC: conectividad dual LTE-NR donde LTE es el maestro y NR es el secundario;

NE-DC: conectividad dual LTE-NR donde NR es el maestro y LTE es el secundario;

NR-DC (o NR-NR DC): tanto MN como SN emplean NR;

MR-DC (multi-RAT DC): un término genérico para describir dónde MN y SN emplean diferentes tecnologías de acceso de radio (RAT), EN-DC y NE-DC son dos casos de ejemplo diferentes de MR-DC.

Armonización de portadores en EN-DC

En la red de acceso de radio 2 (RAN2), se ha acordado armonizar lo que antes se llamaba portadores MCG, portadores divididos MCG, portadores SCG y portadores divididos SCG de la siguiente manera:

a) Es posible configurar el UE para usar el protocolo de convergencia de datos en paquetes (PDCP) NR para todos los portadores (incluso cuando el UE está operando en modo LTE autónomo y EN-DC no está configurado); b) Para todos los portadores configurados con PDCP NR, es posible configurar el UE para usar KeNB o S-KeNB como clave de seguridad;

c) La configuración de las capas PDCP está separada de la configuración de las capas inferiores del tramo MCG y SCG.

Desde el punto de vista del UE, esto significa que solo hay 3 portadores diferentes (como se puede ver en la figura 4) a saber:

d) el portador MCG que usa el enlace de radio hacia el nodo MN solamente;

e) el portador SCG que usa la radio del nodo SN únicamente;

f) y el portador dividido que usa la radio tanto del MN como del SN.

Dónde estos portadores terminen en la red ya no es importante desde la perspectiva del UE, es decir, el UE solo usará la clave que se está configurando desde cada portador. Desde el punto de vista de RAN2, se soporta totalmente configurar portadores MCG terminados en el nodo SN usando S-KeNB y portadores SCG terminados en el nodo MN. De manera similar, es posible soportar portadores terminados en SN y MN al mismo tiempo, es decir, portadores divididos terminados en Sⁿ y portadores divididos terminados en MN.

Procedimiento de restablecimiento de LTE

El propósito del procedimiento de restablecimiento de LTE es restablecer la conexión RRC al detectar fallo de enlace de radio, fallo de traspaso, movilidad por fallo de E-UTRA, fallo de verificación de integridad en SRB o fallo de reconfiguración de conexión de RRC. El restablecimiento implica la reanudación de SRB1, la reactivación de la seguridad y la configuración de solo la célula primaria (PCell), es decir, las operaciones de agregación de portadoras (CA) o DC no se restablecen.

Cuando el eNB de destino recibe una solicitud de restablecimiento, identifica el eNB/célula de origen desde la ReestabUEIdentity incluida en la solicitud y puede enviar un mensaje X2 de indicación de fallo de enlace de radio (RLF) al eNB de origen. El eNB de origen puede responder con un mensaje de solicitud de traspaso que incluye el contexto de UE (contexto RRC y contexto S1). Si el eNB de destino es capaz de comprender el contexto de UE, el restablecimiento se realiza correctamente y el eNB de destino envía un mensaje RRCConnectionReestablishment al UE. Si el eNB de destino no recibe el contexto de UE o no comprende el contexto, puede rechazar el restablecimiento y el UE tiene que ir a RRC_IDLE para volver a conectarse. Si el eNB de destino no comprende el contexto RRC pero puede comprender el contexto S1, no necesariamente rechaza el restablecimiento y aún puede responder con RRCConnectionReestablishment y luego usar la reconfiguración completa para reconfigurar los portadores de acuerdo con el contexto S1.

En caso de que el restablecimiento tenga éxito, el funcionamiento de SRB1 se reanuda mientras el funcionamiento de otros portadores de radio (SRB2 y DRB) permanece suspendido. Si la seguridad de estrato de acceso (AS) no se ha activado, el UE no inicia el procedimiento, sino que se mueve directamente a RRC_IDLE.

E-UTRAN aplica el procedimiento de restablecimiento de la siguiente manera:

Cuando se ha activado la seguridad AS:

- reconfigurar SRB1 y reanudar la transferencia de datos solo para este portador de radio;

- reactivar la seguridad AS sin cambiar los algoritmos.

Después de esto, el UE envía el mensaje RRCConnectionReestablishmentComplete, y el eNB de destino responde enviando un mensaje RRCConnectionReconfiguration para reconfigurar SRB2 y los DRB.

El flujo del procedimiento de restablecimiento de la conexión RRC se muestra en las figuras 5 (caso de éxito) y la figura 6 (caso de fallo). SRB0 se usa para enviar los mensajes RRCConnectionReestablishmentRequest, RRCConnectionReestablishment y RRCConnectionReestablishementReject, mientras que RRCConnectionReestablishmentComplete usa SRB1.

Procedimiento de suspensión/reanudación de LTE

La funcionalidad de suspensión/reanudación de RRC se ha introducido en LTE versión 13. Se puede considerar que un UE suspendido está en un estado intermedio entre INACTIVO y CONECTADO, donde el contexto de AS de UE se mantiene tanto en el UE como en la RAN, y el UE puede verse como si estuviera en modo conectado pero suspendido desde el punto de vista de la red central (CN) y en modo INACTIVO desde el punto de vista de RAN. La ventaja de operar en este modo es una señalización reducida y una transición más rápida al modo CONECTADO en comparación con las transiciones del modo INACTIVO-CONECTADO heredado, mientras se mantienen las ventajas de ahorro de energía del UE del modo INACTIVO.

Cuando la red toma la decisión de mover el UE al estado suspendido, el eNB envía al UE un mensaje RRCConnectionRelease con el valor de causa de liberación de rrc-suspend. El mensaje RRCConnectionRelease también contiene un ID de reanudación. El UE almacena el ID de reanudación y el contexto de AS de UE (incluida la configuración actual de RRC, el contexto de seguridad actual, el estado de PDCP, incluido el estado de compresión de encabezado robusta (ROHC), el identificador temporal de red de radio celular (C-RNTI) usado en la PCell de origen, la identidad de la célula (cellID) y la identidad física de la célula de la PCell de origen); restablece todas las entidades de control de enlace de radio (RLC) (tanto para SRB como para DRB); y suspende todos los DRB y SRB excepto SRB0.

Cuando el UE más adelante desea reanudar la conexión (en respuesta a los datos UL que se enviarán o una solicitud de radioseñalización de datos DL), envía un mensaje RRCConnectionResumeRequest con el ID de reanudación guardado. Si la operación de reanudación se realiza en un eNB distinto del eNB que estaba sirviendo al UE cuando se suspendió el UE, el nuevo eNB puede realizar una búsqueda de contexto usando el procedimiento recuperar contexto de UE X2 del antiguo eNB (ya que el ID de reanudación incluye información sobre el antiguo eNB/célula). Al obtener el contexto (si se reanuda en un nuevo eNB) o si la reanudación fue en el mismo eNB, el eNB de destino responde con un mensaje RRCConnectionResume, y tanto el UE como el eNB restauran el contexto de UE guardado y se puede reanudar la transmisión/recepción de datos desde/al UE.

El flujo del procedimiento de reanudación de la conexión RRC se muestra en la figura 7 (caso de éxito) y la figura 8 (retorno al establecimiento de la conexión RRC). La figura 9 (rechazo o liberación de la red) muestra el procedimiento de reanudación en LTE. SRB0 se usa para enviar RRCConnectionResumeRequest, RRCConnectionSetup y RRCConnectionReestablishementReject, mientras que los mensajes RRCConnectionResume y RRCConnectionResumeComplete usan ^s RB1.

La principal diferencia entre reanudación y restablecimiento es (desde una perspectiva de procedimiento): SRB1 se usa para el mensaje RRCConnectionResume, mientras que SRB0 se usa para el mensaje RRCConnectionReestablishment.

El mensaje RRCConnectionResume, a diferencia del mensaje RRCConnectionReestablishement, puede contener la configuración SRB2/DRB y, por lo tanto, RRCConnectionReconfiguration no es necesario después de la reanudación (aunque es necesario en el caso de restablecimiento reconfigurar SRB2/DRB).

El procedimiento 1000 de suspensión de conexión RRC detallado se ilustra en la figura 10.

Más específicamente, en el paso 1010 de la figura 10, debido a algunos desencadenantes, por ejemplo, la expiración de un temporizador de inactividad de UE, el eNB decide suspender la conexión RRC.

En el paso 1020, el eNB inicia el procedimiento de suspensión de contexto de UE de protocolo de aplicación (AP) SI para informar a la entidad de gestión de movilidad (MME) que la conexión RRC se va a suspender. Para hacerlo, el eNB envía una solicitud de suspensión de contexto de UE. Como nota, S1 se refiere a la interfaz entre el eNB y la red central.

En el paso 1030, la MME solicita a la pasarela de servicio (S-GW) que libere todos los portadores S1-U para el UE. El S1-U se refiere al plano de usuario S1 y los portadores S1-U son los portadores que transportan los datos del usuario entre el eNB y la red central.

En el paso 1040, la MME reconoce el paso 1020. Por ejemplo, la MME envía una respuesta a la solicitud del paso 1020.

En el paso 1050, el eNB suspende la conexión RRC enviando un mensaje RRCConnectionRelease con el releaseCause establecido en rrc-Suspend, al UE. El mensaje incluye resumeIdentity que es almacenado por el UE. En el paso 1060, el UE almacena el contexto de AS, suspende todos los SRB y DRB. El UE entra en el estado de luz conectado RRC_IDLE.

Cuando el UE más adelante desea reanudar la conexión (en respuesta a los datos UL que se enviarán o una solicitud de radioseñalización de datos DL), envía un mensaje RRCConnectionResumeRequest con la resumeIdentity guardada. El eNB responde con un mensaje RRCConnectionResume, y tanto el UE como el eNB restauran el contexto de UE guardado, y se puede reanudar la transmisión/recepción de datos desde/hacia el UE. Téngase en cuenta que la operación de reanudación se puede realizar en un eNB distinto del eNB que estaba sirviendo al UE cuando se suspendió el UE. En ese caso, el nuevo eNB puede realizar una búsqueda de contexto, por ejemplo, usando el procedimiento recuperar contexto de UE del antiguo eNB (ya que resumeIdentity incluye información sobre el eNB/célula antiguo).

El procedimiento de reanudación de la conexión RRC en el mismo eNB y el nuevo eNB se ilustran en las figuras 11 y 12, respectivamente.

La figura 11 ilustra un procedimiento 1100 de reanudación de la conexión RRC en el mismo eNB.

En el paso 1110, el UE envía un preámbulo de acceso aleatorio al eNB, para acceder a la red.

En el paso 1120, el eNB responde enviando una respuesta de acceso aleatorio, para confirmar que el UE está conectado al nodo de red (eNB).

En el paso 1130 de la figura 11, en algún momento posterior (por ejemplo, cuando el UE está siendo radioseñalizado o cuando llegan nuevos datos al búfer de enlace ascendente), el UE reanuda la conexión enviando una RRCConnectionResumeRequest al eNB. El UE puede incluir su ID de reanudación, la causa de establecimiento y el token de autenticación. El token de autenticación se calcula de la misma manera que el código de integridad de autenticación de mensaje corto (MAC-I) usado en el restablecimiento de la conexión RRC y permite que el eNB verifique la identidad del UE.

En el paso 1140, siempre que exista el ID de reanudación y el token de autenticación se haya validado satisfactoriamente, el eNB responde con un RRCConnectionResume. El mensaje incluye el valor del recuento de encadenamiento del siguiente salto (NCC) que se requiere para restablecer la seguridad del AS.

En el paso 1150, el UE reanuda todos los SRB y DRB y restablece la seguridad del AS. El UE está ahora en RRC_CONNECTED.

En el paso 1160, el UE responde con un RRCConnectionResumeComplete confirmando que la conexión RRC se reanudó con éxito.

En el paso 1170, el eNB inicia el procedimiento de reanudación de contexto S1-AP para notificar a la MME sobre el cambio de estado del UE.

En el paso 1180, la MME solicita a la S-GW que active los portadores S1-U para el UE.

En el paso 1190, la MME reconoce el paso 1170.

La figura 12 ilustra el procedimiento 1200 de reanudación de RRC en un eNB diferente del eNB de origen donde se suspendió el UE.

Los pasos 1205 a 1215 son los mismos que los pasos 1110 a 1130 en la figura 11.

En el paso 1220 (X2-AP: recuperar solicitud de contexto de UE), el nuevo eNB localiza el antiguo eNB usando el ID de reanudación y recupera el contexto de UE por medio del procedimiento recuperar contexto de UE X2-AP.

En el paso 1225 (X2-AP: recuperar respuesta de contexto de UE), el eNB antiguo responde al nuevo eNB con el contexto de AS de UE asociado con el ID de reanudación.

En el paso 1230, es el mismo paso que el paso 1140 de la figura 11 (en la reanudación de la conexión dentro de eNB).

En el paso 1235, es el mismo paso que el paso 1150 de la figura 11 (en la reanudación de la conexión dentro de eNB).

En el paso 1240, es el mismo que el paso 1160 de la figura 11 (en la reanudación de la conexión dentro de eNB). En el paso 1245, el nuevo eNB inicia el procedimiento de conmutación de ruta S1-AP para establecer una conexión de señalización asociada al UE S1 con la MME de servicio y para solicitar a la MME que reanude el contexto de UE. En el paso 1250, la MME solicita a la S-GW que active los portadores S1-U para el UE y actualiza la ruta del enlace descendente.

En el paso 1255, la MME reconoce el paso 1245.

En el paso 1260 (X2-AP: liberación de contexto de UE), después del procedimiento de conmutación de ruta S1-AP, el nuevo eNB activa la liberación del contexto de UE en el eNB antiguo por medio del procedimiento de liberación de contexto de UE X2-AP.

El procedimiento de reanudación es un procedimiento oportunista en el que puede haber casos en los que el nodo RAN no tenga el contexto de UE almacenado. En este caso, se ha especificado una solución que permite a la RAN recuperar el contexto de UE usando el procedimiento de establecimiento de conexión de RRC que implica la señalización de UE a la CN y luego la CN reconstruyendo el contexto de UE en la RAN. El procedimiento r Rc para esto se muestra en la figura 8. En la figura 13, se muestra un procedimiento más detallado para este caso. Este caso también podría denominarse uso de recuperación NAS o transición a través de INACTIVO (ya que se elimina el contexto de AS de UE). La figura 13 es conocida en la técnica, como tal, no se describirá más.

Configuraciones completas de RRC en LTE

En LTE, durante un traspaso (HO) o restablecimiento, el contexto de UE se pasa desde el eNB de origen al de destino. Si el eNB de destino no comprende ninguna parte de la configuración del UE, activa la configuración completa. El procedimiento de configuración completo se especifica en la especificación técnica del proyecto de asociación de tercera generación (3GPP TS) 36.331, sección 5.3.5.8, como se muestra a continuación.

La UE deberá:

1> liberar/borrar todas las configuraciones de radio dedicadas actuales excepto MCG C-RNTI, la configuración de seguridad de MCG y las configuraciones de canal lógico PDCP, RLC para los RB y la configuración de medición registrada;

NOTA 1: la configuración de radio no es solo la configuración de recursos sino incluye otras configuraciones como MeasConfig y OtherConfig.

1> si el mensaje RRCConnectionReconfiguration incluye mobilityControlInfo:

2> liberar/borrar todas las configuraciones de radio comunes actuales;

2> usar los valores predeterminados especificados en 9.2.5 para el temporizador T310, T311 y la constante N310, N311;

1> else:

2> usar valores para los temporizadores T301, T310, T311 y las constantes N310, N311, como se incluye en ue-TimersAndConstants recibidos en SystemInformationBlockType2 (o SystemInformationBlockType2-NB en NB-IoT); 1> aplicar la configuración del canal físico predeterminada como se especifica en 9.2.4;

1> aplicar la configuración de planificación semipersistente predeterminada como se especifica en 9.2.3;

1> aplicar la configuración principal MAC predeterminada como se especifica en 9.2.2;

1> si el UE es un UE NB-IoT; o

1> para cada valor de srb-Identity incluido en srb-ToAddModList (reconfiguración de SRB):

2> aplicar la configuración especificada definida en 9.1.2 para el SRB correspondiente;

2> aplicar la configuración RLC predeterminada correspondiente para el SRB especificado en 9.2.1.1 para SRB1 o en 9.2.1.2 para SRB2;

2> aplicar la configuración de canal lógico predeterminada correspondiente para el SRB como se especifica en 9.2.1.1 para SRB1 o en 9.2.1.2 para SRB2;

NOTA 2: Esto es para llevar a los SRB (SRB1 y SRB2 para traspaso y SRB2 para reconfiguración después del restablecimiento) a un estado conocido desde el cual el mensaje de reconfiguración puede realizar configuraciones adicionales.

1> para cada valor de eps-BearerIdentity incluido en drb-ToAddModList que es parte de la configuración actual de UE:

2> liberar la entidad PDCP;

2> liberar la entidad o entidades RLC;

2> liberar el canal lógico DTCH;

2> liberar la drb-identity;

NOTA 3: esto retendrá eps-bearerIdentity pero eliminará los DRB, incluida la drb-identity de estos portadores, de la configuración actual del UE y activará la configuración de los DRB dentro del AS en la sección 5.3.10.3 usando la nueva configuración. Eps-bearerIdentity actúa como el ancla para asociar el DRB liberado y restablecido. En el AS, la reinstalación del DRB es equivalente a una nueva configuración del DRB (incluidas las nuevas configuraciones de PDCP y canales lógicos).

1> para cada valor de eps-BearerIdentity que es parte de la configuración actual del UE pero que no forma parte de drb-ToAddModList:

2> realizar la liberación de DRB como se especifica en 5.3.10.2;

Como se puede ver desde arriba, la opción de configuración completa incluye una inicialización de la configuración de radio, lo que hace que el procedimiento sea independiente de la configuración usada en la célula o células de origen con la excepción de que los algoritmos de seguridad continúan para el restablecimiento de RRC. Si un DRB no está incluido en drb-ToAddModList, el DRB se liberará y, por lo tanto, se enviará un mensaje a las capas superiores indicando la liberación del portador (es decir, se requiere una configuración de portador completa desde cero para continuar con el servicio o servicios de datos asociados con el portador o portadores liberados). Para aquellos portadores incluidos en drb-toAddModList, las entidades PDCP/RLC/canal lógico (LCH) se liberan y se establecen nuevamente.

Las ventajas de usar la configuración completa es que el nodo de destino (del traspaso) no necesita comprender la configuración del UE en el nodo de origen. Esto hace posible soportar la movilidad entre diferentes nodos que soportan diferentes versiones de protocolo del RRC y otros protocolos. También hace posible manejar casos en los que los nodos de origen y destino soportan diferentes soluciones para el manejo y la configuración de UE (por ejemplo, usando diferentes algoritmos).

La desventaja de usar la configuración completa (es decir, la ventaja de usar la señalización delta) es que la configuración completa puede conducir a mensajes más grandes enviados por radio en comparación con la señalización delta donde solo se reconfiguran partes relevantes del contexto UE.

Cabe señalar que aunque normalmente se emplea la configuración completa durante e1HO o el restablecimiento, la red puede decidir realizar una reconfiguración completa del UE en cualquier momento. "Proyecto de asociación de tercera generación; red de acceso de radio del grupo de especificaciones técnicas; acceso de radio terrestre universal evolucionado (E-UTRA); 3GPP TS 36.331 V15.0.1 (01-2018) control de recursos de radio (RRC); especificación de protocolo (versión 15)", 11-01-2018, divulga el estado de la técnica de reanudación de conexiones.

Sumario

El procedimiento de configuración completo descrito anteriormente se realiza enviando un mensaje RRCConnectionReconfiguation con el indicador fullConfig activada y no está disponible para otros mensajes de reconfiguración de radio, como restablecimiento y reanudación. En el caso de restablecimiento, el procedimiento siempre va seguido de un procedimiento RRCConnectionReconfiguation y, como tal, se puede realizar la configuración completa durante esta etapa. Por otro lado, uno de los objetivos principales del procedimiento de reanudación es hacer que el UE pase al modo conectado lo más rápido posible (con la menor señalización posible), reutilizando la configuración guardada del UE cuando se suspendió y, por lo tanto, una RRCConnectionReconfiguation adicional no es necesaria.

Sin embargo, hay escenarios en los que, durante la reanudación después de la suspensión, el nodo de destino no comprende la configuración de radio del UE y, dado que no es soportada la configuración completa, la única opción viable para que el UE reanude será a través del modo INACTIVO (como ilustrado en las figuras 8 y 12), que incurre en retrasos adicionales en la continuidad del servicio en el UE.

En el contexto de la versión 15 y EN-DC, estas situaciones pueden suceder fácilmente. Por ejemplo, un UE puede configurarse para usar PDCP NR para algunos de los portadores de radio (SRB o DRB), incluso cuando no está en modo EN-DC, puede reanudarse en un eNB que no soporta PDCP NR.

Para resolver este problema en cierta medida, se propuso una solución en la solicitud de patente provisional número 62/565,067, presentada ante la USPTO el 28 de septiembre de 2017, y posteriormente plasmada en un acuerdo que se realizó en la reunión RAN2 # 100 [ftp://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_100/Report/RAN2-100-Reno-Chair-Notes-2017-12-01-eom.docx

Esta solución asegura que el eNB podrá enviar el comando RRCConnectionResume en SRB1 que usa PDCP LTE, y el UE podrá entenderlo. Sin embargo, la solución aún requiere que el eNB comprenda el contexto (o configuración) del UE en la célula de origen para saber cómo debería poder configurar el UE en la célula de destino. Si la célula de destino (o nodo de red) no comprende el contexto de UE, no tendrá opción para permitir que el UE realice la recuperación del NAS enviando un mensaje de establecimiento de la conexión RRC al UE (como se ilustra en las figuras 8 y 12).

La invención se lleva a cabo de acuerdo con las reivindicaciones independientes adjuntas. Las características

opcionales de la invención se llevan a cabo de acuerdo con las reivindicaciones dependientes.

Breve descripción de los dibujos

Las realizaciones de ejemplo se describirán con más detalle con referencia a las siguientes figuras, en las que:

La figura 1 ilustra un diagrama de bloques esquemático de un plano de usuario (UP) de DC LTE.

La figura 2 es un diagrama de bloques esquemático de un interfuncionamiento estrecho LTE-NR para el UP.

La figura 3 es un diagrama de bloques esquemático de un interfuncionamiento estrecho LTE-NR para el plano de

control (CP).

La figura 4 ilustra un diagrama de bloques esquemático de la configuración de 3 portadores en una red de

comunicaciones.

La figura 5 ilustra un diagrama de señales de un procedimiento exitoso de restablecimiento de la conexión RRC.

La figura 6 ilustra un diagrama de señales de un procedimiento fallido de restablecimiento de la conexión RRC.

La figura 7 ilustra un diagrama de señales de un procedimiento exitoso de reanudación de la conexión RRC.

La figura 8 ilustra un diagrama de señales de un procedimiento de recuperación de reanudación de la conexión RRC

al procedimiento de establecimiento de la conexión RRC satisfactorio.

La figura 9 ilustra un diagrama de señales de un procedimiento de reanudación de una conexión RRC, con un

rechazo o liberación de la red.

La figura 10 es un diagrama de señales de una conexión RRC suspendida.

La figura 11 es otro diagrama de señales de un procedimiento de reanudación de la conexión RRC.

La figura 12 es un diagrama de señales de un procedimiento de reanudación de la conexión RRC en un nodo de red

de destino que es diferente del nodo de red de origen donde se suspendió el UE.

La figura 13 ilustra

diagrama de señales para manejar el caso cuando no se puede recuperar un contexto de La figura 14 ilustra

diagrama de bloques esquemático de una red de comunicaciones.

La figura 15 ilustra un diagrama de flujo de un método en un nodo de red, de acuerdo con una realización.

La figura 16 ilustra un diagrama de flujo de otro método en un nodo de red, de acuerdo con la invención.

La figura 17 ilustra

diagrama de flujo de un método en un dispositivo inalámbrico, de acuerdo con la invenció La figura 18 ilustra un diagrama de flujo de otro método más en un nodo de red, de acuerdo con un ejemplo útil comprender la presente invención.

Las figuras 19 y 20 ilustran diagramas de bloques esquemáticos de un nodo de red, de acuerdo con la invención.

Las figuras 21 y 22 ilustran diagramas de bloques esquemáticos de un dispositivo inalámbrico de acuerdo con

algunas realizaciones.

La figura 23 ilustra un diagrama de bloques esquemático que ilustra un entorno de virtualización en el que las

funciones implementadas por algunas realizaciones pueden virtualizarse.

Descripción detallada

Las realizaciones expuestas a continuación representan información para permitir a los expertos en la técnica poner

en práctica las realizaciones. Al leer la siguiente descripción a la luz de las figuras adjuntas, los expertos en la

técnica comprenderán los conceptos de la descripción y reconocerán las aplicaciones de estos conceptos que no se

tratan particularmente en el presente documento. Debe entenderse que estos conceptos y aplicaciones caen dentro

del alcance de la descripción.

En la siguiente descripción, se exponen numerosos detalles específicos. Sin embargo, se entiende que se pueden practicar realizaciones sin estos detalles específicos. En otros casos, los circuitos, estructuras y técnicas bien conocidos no se han mostrado en detalle para no dificultar la comprensión de la descripción. Los expertos en la técnica, con la descripción incluida, podrán implementar la funcionalidad apropiada sin experimentación indebida. Las referencias en la especificación a "una realización", "una realización", "una realización de ejemplo", etc. indican que la realización descrita puede incluir un rasgo, estructura o característica particular, pero cada realización puede no incluir necesariamente el rasgo, estructura o característica particular. Además, tales frases no se refieren necesariamente a la misma realización. Además, cuando se describe un rasgo, estructura o característica particular en relación con una realización, se afirma que está dentro del conocimiento de un experto en la técnica implementar tal rasgo, estructura o característica en relación con otras realizaciones, ya se describa explícitamente o no.

Como se usa en el presente documento, las formas singulares "un", "una", "el" y "la" pretenden incluir las formas plurales también, a menos que el contexto indique claramente lo contrario. Se entenderá además que los términos "comprende", "que comprende", "incluye" y/o "que incluye", cuando se usan en el presente documento, especifican la presencia de rasgos, números enteros, pasos, operaciones, elementos y/o componentes indicados, pero no excluyen la presencia o adición de una o más de otros rasgos, números enteros, pasos, operaciones, elementos, componentes y/o grupos de los mismos.

La figura 14 ilustra una red 200 de comunicación inalámbrica para comunicaciones inalámbricas. La red 200 de comunicación inalámbrica incluye dispositivos inalámbricos 210 (por ejemplo, equipos de usuario, UE) y una pluralidad de nodos 220 de red (por ejemplo, eNB, gNB, estaciones base, etc.) conectados a uno o más nodos 240 de red central a través de una red 230 de interconexión. Los dispositivos inalámbricos 210 dentro de un área de cobertura pueden ser capaces cada uno de comunicarse directamente con los nodos 220 de red a través de una interfaz inalámbrica. Los UE 210 son UE capaces de MIMO masivo (M-MIMO), por ejemplo. El nodo de red puede ser el nodo de red de servicio del UE M-MIMO o cualquier nodo de red con el que el UE M-MIMO pueda establecer o mantener un enlace de comunicación y/o recibir información (por ejemplo, a través de un canal de difusión). Como tal, el nodo de red puede comprender múltiples antenas, distribuidas en una pluralidad de RRH.

En determinadas realizaciones, los dispositivos inalámbricos 210 también pueden comunicarse entre sí a través de la comunicación de dispositivo a dispositivo (D2D). En determinadas realizaciones, los nodos 220 de red también pueden ser capaces de comunicarse entre sí, por ejemplo, a través de una interfaz (por ejemplo, X2 en LTE u otra interfaz adecuada).

Como ejemplo, el dispositivo inalámbrico 210 puede comunicarse con el nodo 220 de red a través de una interfaz inalámbrica. Es decir, el dispositivo inalámbrico 210 puede transmitir señales inalámbricas y/o recibir señales inalámbricas desde el nodo 220 de red. Las señales inalámbricas pueden contener tráfico de voz, tráfico de datos, señales de control y/o cualquier otra información adecuada. En algunas realizaciones, un área de cobertura de señal inalámbrica asociada con un nodo 220 de red puede denominarse célula.

En algunas realizaciones, el dispositivo inalámbrico 210 puede denominarse indistintamente por el término no limitativo de equipo de usuario (UE). El dispositivo inalámbrico 210 puede ser cualquier tipo de dispositivo inalámbrico capaz de al menos comunicaciones M-MIMO con un nodo de red u otro UE a través de señales de radio. Ejemplos de tales UE M-MIMO son un sensor, módem, teléfono inteligente, dispositivo tipo máquina (MTC) también conocido como dispositivo máquina a máquina (M2M), PDA, iPAD, tableta, teléfono inteligente, computadora portátil integrada equipada (LEE), equipo montado en computadora portátil (LME), llaves USB, etc.

En algunas realizaciones, el "nodo de red" puede ser cualquier tipo de nodo de red. Ejemplos de nodo de red son eNodoB, Nodo B, estación base, punto de acceso inalámbrico (AP), controlador de estación base, controlador de red de radio, relé, relé de control de nodo donante, estación de transceptor base (BTS), puntos de transmisión, nodos de transmisión, unidad de radio remota (RRU), cabecera de radio remota (RRH), nodos en el sistema de antena distribuida (DAS), nodo de red central, entidad de gestión de movilidad (MME), etc.

En determinadas realizaciones, los nodos 220 de red pueden interactuar con un controlador de red de radio (no mostrado). El controlador de red de radio puede controlar los nodos 220 de red y puede proporcionar ciertas funciones de gestión de recursos de radio, funciones de gestión de movilidad y/u otras funciones adecuadas. En determinadas realizaciones, las funciones del controlador de red de radio pueden incluirse en el nodo 220 de red. El controlador de red de radio puede interactuar con el nodo 240 de red central. En ciertas realizaciones, el controlador de red de radio puede interactuar con el nodo 240 de red central a través de la red 230 de interconexión.

La red 230 de interconexión puede referirse a cualquier sistema de interconexión capaz de transmitir audio, video, señales, datos, mensajes o cualquier combinación de los anteriores. La red 230 de interconexión puede incluir la totalidad o una parte de una red telefónica pública conmutada (PSTN), una red de datos pública o privada, una red de área local (LAN), una red de área metropolitana (MAN), una red de área amplia (WAN), una red informática o de comunicación local, regional o global, como Internet, una red alámbrica o inalámbrica, una intranet empresarial o cualquier otro enlace de comunicación adecuado, incluidas las combinaciones de los mismos.

En algunas realizaciones, el nodo 240 de red central puede gestionar el establecimiento de sesiones de comunicación y otras funcionalidades diversas para los dispositivos inalámbricos 210. Los ejemplos del nodo 340 de red central pueden incluir MSC, MME, SGW, PGW, O&M, OSS, SON, nodo de posicionamiento (por ejemplo, E-SMLC), nodo MDT, etc. Los dispositivos inalámbricos 210 pueden intercambiar ciertas señales con el nodo 240 de red central usando la capa de estrato sin acceso. En la señalización de estrato sin acceso, las señales entre los dispositivos inalámbricos 310 y el nodo 240 de red central pueden pasarse de forma transparente a través de la red de acceso de radio. En ciertas realizaciones, los nodos 220 de red pueden interactuar con uno o más de otros nodos de red a través de una interfaz de internodo. Por ejemplo, los nodos 220 de red pueden interactuar entre sí a través de una interfaz X2.

Aunque la figura 14 ilustra una disposición particular de la red 200, la presente divulgación contempla que las diversas realizaciones descritas en el presente documento pueden aplicarse a una variedad de redes que tengan cualquier configuración adecuada. Por ejemplo, la red 200 puede incluir cualquier número adecuado de dispositivos inalámbricos 210 y nodos 220 de red, así como cualquier elemento adicional adecuado para soportar la comunicación entre dispositivos inalámbricos o entre un dispositivo inalámbrico y otro dispositivo de comunicación (como un teléfono fijo). Las realizaciones pueden implementarse en cualquier tipo apropiado de sistema de telecomunicaciones que soporte cualquier estándar de comunicación adecuado y use cualquier componente adecuado, y son aplicables a cualquier tecnología de acceso de radio (RAT) o sistemas multi-RAT en los que el dispositivo inalámbrico recibe y/o transmite señales (por ejemplo, datos).

Aunque en esta divulgación se ha usado terminología de 3GPP LTE (o E-UTRAN) para ejemplificar las realizaciones y describir tanto los nodos de red de servicio como los víctima, esto no debe verse como una limitación del alcance de la divulgación solo al sistema mencionado anteriormente. Otros sistemas inalámbricos, incluidos WCDMA, UTRA FDD, UTRA TDD y GSM/GERAN/EDGE, también pueden beneficiarse de la explotación de las ideas cubiertas en esta divulgación. Además, las realizaciones de esta divulgación pueden aplicarse a escenarios en los que los nodos de servicio y víctima emplean diferentes tecnologías de acceso de radio (RAT).

Como se mencionó anteriormente, el procedimiento de reconfiguración (o configuración) completo no está disponible para procedimientos de control de radio como los procedimientos de restablecimiento y reanudación.

Las realizaciones de esta divulgación pueden abordar los inconvenientes de los procedimientos actuales de reanudación de LTE y NR, para el caso en el que un UE se reanuda en un eNB/gNB que no soporta todas las funcionalidades del eNB de origen. En tal caso, es posible que el eNB/gNB de destino no pueda leer la información contenida en el contexto de AS de UE, lo que hace imposible reanudar la conexión UE sin volver al modo INACTIVO (también conocido como recuperación NAS). El uso de la recuperación del NAS puede generar retrasos y señales adicionales. Algunas realizaciones mitigan este problema, al introducir la posibilidad de realizar una reconfiguración completa durante el procedimiento de reanudación, por ejemplo.

Parte A

La parte A propone utilizar una configuración completa hacia el UE en el procedimiento de reanudación, como se muestra en la figura 12, pero donde el nuevo eNB no es compatible con el antiguo eNB, lo que significa que el nuevo eNB no puede leer, identificar, comprender ni acceder a algunos archivos, como la información de configuración (por ejemplo, el contexto de AS de UE).

Más específicamente, el procedimiento de reanudación se ha mejorado para soportar una configuración completa (o reconfiguración). Cuando un eNB de destino/nuevo (gNB) recibe una solicitud de reanudación de un UE (véase, por ejemplo, el paso 1215 de la figura 12), recupera un contexto de AS de UE del eNB de origen/antiguo (véanse los pasos 1220 y 1225 de la figura 12). En caso de que el eNB de destino/nuevo y el eNB de origen/antiguo sean diferentes (usando diferentes tecnologías de acceso de radio o diferentes versiones de la tecnología), es posible que el eNB de destino no pueda acceder o leer completamente el contexto de AS de UE.

La figura 15 ilustra un método 300 para reanudar una conexión en un nodo de red, como el nuevo eNB. En tal caso, el eNB de destino (gNB) realiza los siguientes pasos u operaciones de:

Paso 305: recibir, desde un dispositivo inalámbrico, una solicitud para reanudar una conexión en la red de comunicación.

Paso 310: basado en la solicitud, recuperar información de configuración (por ejemplo, contexto de AS de UE) para el dispositivo inalámbrico.

Paso 315: en respuesta a la determinación de que la información de configuración recuperada no es identificable, generar nuevos parámetros de configuración.

Paso 320: enviar un mensaje de respuesta de reanudación al dispositivo inalámbrico, el mensaje comprende una indicación para realizar una configuración completa usando los nuevos parámetros de configuración.

En el paso 305, la solicitud de reanudación puede ser una solicitud de reanudación de conexión RRC.

En el paso 315: después de determinar que la información de configuración recuperada no es identificable, el nuevo eNB puede simplemente ignorar la información de contexto de AS de UE recuperada. Entonces, puede preparar (o generar) una nueva información de contexto de AS de UE a partir de la información de contexto S1 o NG que se proporciona durante la recuperación del contexto de AS de UE. El contexto S1 y NG contiene información que la red central ha enviado a la RAN durante la configuración del contexto de UE inicial o en una señalización posterior. Esta información podría comprender parámetros de radio para la configuración e información sobre los diferentes portadores. Esta información debería ser suficiente para que el eNB de destino reconstruya el contexto de AS de UE.

En el paso 320: el nuevo eNB prepara el mensaje de reanudación de RRC que incluye la nueva información de contexto de AS de UE para enviarla al dispositivo inalámbrico. Para hacerlo, el nuevo eNB establece un indicador para la configuración completa en el mensaje de reanudación de RRC. Una vez que se establece el indicador, se podría denominar el indicador fullConfig. En los sistemas actuales, no existe tal indicador en el mensaje de reanudación. Luego, el nuevo eNB envía el mensaje de reanudación de RRC al UE con el indicador.

En respuesta a la recepción del mensaje de reanudación de RRC que contiene el indicador fullConfig, el UE descartará la configuración de portador antigua y otros parámetros de radio antiguos, por ejemplo. Luego, solo aplicará la (nueva) configuración que recibió en el mensaje de reanudación de RRC. De esta manera, el UE podría cambiar a una nueva configuración desde un nodo de red que no puede entender la configuración anterior. Cabe señalar que algunos parámetros, como las claves de seguridad, se mantendrán en el UE incluso después de recibir el indicador fullConfig, ya que la protección de cifrado e integridad ya está en funcionamiento cuando el nodo de red (gNB) envía el mensaje de reanudación de RRC.

Cabe señalar que se pueden realizar modificaciones, adiciones u omisiones al método 300 de la figura 15. Además, uno o más pasos en el método 300 se pueden realizar en paralelo o en cualquier orden adecuado. Como tal, la figura 16 ilustra el método 300 de la invención para reanudar una conexión con un nodo de red. Este método se denomina método 330 y se puede realizar en un nodo 220 de red de la figura 14. Este nodo de red puede denominarse nuevo nodo de red o eNB de destino o gNB. El método 330 incluye los siguientes pasos:

Paso 335: recibir, desde un dispositivo inalámbrico, una solicitud para reanudar una conexión en la red de comunicación.

Paso 340: en respuesta a la solicitud, enviar un mensaje de respuesta de reanudación al dispositivo inalámbrico, el mensaje comprende una indicación para realizar una configuración completa.

En algunos ejemplos, el nodo 220 de red (por ejemplo, un nuevo eNB) puede recuperar información de configuración (por ejemplo, el contexto de AS de UE) del eNB de origen/antiguo al recibir la solicitud de reanudación. Además, en caso de que el eNB de destino/nuevo y el eNB de origen/antiguo sean diferentes (usando diferentes tecnologías de acceso de radio o diferentes versiones de la tecnología), es posible que el eNB de destino no pueda acceder o leer completamente el contexto de AS de UE. En este caso, el nuevo eNB puede generar parámetros de configuración (que son nuevos en comparación con los parámetros de configuración actuales) para la configuración completa. En algunas realizaciones, el nuevo nodo de red puede determinar que la información de configuración recuperada no es identificable/ilegible, el nuevo eNB puede simplemente ignorar la información de contexto de AS de UE recuperada. Luego, puede preparar (o generar) parámetros de configuración, por ejemplo, nueva información de contexto de AS de UE de la información de contexto S1 o NG que se proporciona durante la recuperación del contexto de AS de UE. Los contextos S1 y NG contienen información que la red central ha enviado a la RAN durante la configuración del contexto de UE inicial o en una señalización posterior. Esta información podría comprender parámetros de radio para la configuración e información sobre los diferentes portadores. Esta información debería ser suficiente para que el eNB de destino reconstruya el contexto de AS de UE. Como nota, S1 es la interfaz entre el eNB y la red central, cuando la red central es el centro de paquetes mejorado (EPC). NG es la interfaz entre un eNB/gNB y la red central, cuando la red central es 5GC.

En algunas realizaciones, el nuevo eNB prepara el mensaje de reanudación de RRC que incluye la nueva información de contexto de AS de UE (o parámetros de configuración) para ser enviado al dispositivo inalámbrico. El nuevo eNB establece un indicador para la configuración completa en el mensaje de reanudación de RRC. Una vez que se establece el indicador, se podría denominar como el indicador fullConfig. Luego, el nuevo eNB envía el mensaje de reanudación de RRC al UE con el indicador.

En respuesta a recibir el mensaje de reanudación de RRC que contiene el indicador fullConfig, el UE descartará la configuración de portador antigua y otros parámetros de radio antiguos, por ejemplo. Luego, solo aplicará la (nueva) configuración que recibió en el mensaje de reanudación de RRC. De esta manera, el UE podría cambiar a una nueva configuración desde un nodo de red que no puede entender la configuración anterior. Cabe señalar que algunos parámetros, como las claves de seguridad, se mantendrán en el UE incluso después de recibir el indicador fullConfig, ya que la protección de cifrado e integridad ya está en funcionamiento cuando el nodo de red (gNB) envía el mensaje de reanudación de RRC.

En algunas realizaciones, los parámetros de configuración comprenden uno o más de la configuración del portador, la configuración del protocolo de convergencia de datos en paquetes (PDCP), la configuración del control de enlace de radio (RLC).

Pasando ahora a la figura 17, se describirá un método 350 de la invención en un dispositivo inalámbrico/UE para reanudar una conexión. El dispositivo inalámbrico podría ser el UE 210 de la figura 14.

El método 350 comprende los siguientes pasos:

Paso 355: enviar a un nodo de red una solicitud para reanudar una conexión en la red de comunicaciones.

Paso 360: recibir un mensaje de respuesta de reanudación del nodo de red, el mensaje comprende una indicación para realizar una configuración completa.

Paso 365: aplicar (o realizar) la configuración completa.

En algunas realizaciones, el método 350 puede comprender además descartar una configuración de portador antigua y parámetros de radio antiguos.

En algunas realizaciones, el método 350 puede comprender además mantener claves de seguridad. En algunas realizaciones, el método 350 puede comprender además recibir una nueva configuración. En algunas realizaciones, el método 350 puede comprender además aplicar la nueva configuración. Parte B

La parte B aborda la incompatibilidad entre los nodos de red de origen y de destino (por ejemplo, eNB) considerando la falta de coincidencia del contexto de UE desde el punto de vista de la red.

Por ejemplo, se podrían considerar las siguientes mejoras de red para resolver el problema de incompatibilidad de los nodos de red:

1) La información de contexto de AS de UE que se pasa desde el nodo de red de origen se puede codificar de tal manera que el nodo de red de destino sea capaz de comprender los elementos de información heredados (IE) (por ejemplo, configuraciones de PDCP LTE), aunque es posible que se hayan introducido algunos IE nuevos en versiones posteriores del estándar que en la versión del eNB heredado.

2) Cuando el nodo de red de origen sabe que el nodo de red de destino es un eNB heredado, puede convertir la información de contexto de AS de UE a un formato que el eNB heredado es capaz de comprender (por ejemplo, convertir configuraciones PDCP NR en configuraciones PDCP LTE).

En el primer caso, el nodo de red de destino puede obtener la información del portador relevante que puede comprender (por ejemplo, el DRB-id y el RLC y las configuraciones de la capa inferior) a través de la codificación adecuada. Puede obtener el resto de la información para ese portador particular del contexto del portador S1 (es decir, para que pueda reconfigurar el UE con la versión PDCP LTE adecuada). El problema con esta solución es que asume que un eNB heredado realiza algo nuevo (combina el contexto S1 o NG con otro contexto de UE recibido del nodo de red de origen) para manejar este caso (es decir, no es en realidad un eNB heredado) pero al menos debería ser posible agregar nuevos parámetros en el futuro que no necesitan ser entendidos por los eNB existentes, ya que estos eNB obtendrían toda la información relevante de las partes que comprenden del contexto UE y el contexto S1. Esas partes son las partes que se han codificado correctamente para que sean entendidas por todos los nodos de red (heredados y nuevas generaciones de nodos de red).

En el segundo caso, el eNB de destino comprenderá el contexto de UE a partir del eNB de origen. Sin embargo, necesita señalar todos los DRB al UE para que active el UE para que cambie esos DRB de la configuración anterior (no comprendida por el eNB de destino). Normalmente, el eNB no necesita señalizar la configuración de DRB para los DRB que no desea cambiar (ya que se usa la señalización delta). Por lo tanto, un impacto adicional de esta solución sería agregar una función al eNB de destino para activar la señalización DRB para todos los DRB. Esto requeriría que se actualice el eNB de destino, pero al menos debería ser posible agregar nuevos parámetros en el futuro que no necesitan ser entendidos por los eNB existentes/heredados, ya que el eNB comprenderá todos los parámetros enviados desde el eNB de origen y enviará siempre la configuración de DRB al UE.

Como se puede ver anteriormente, la primera y la segunda solución se basan en nuevas funcionalidades tanto en los nodos de destino como de origen, pero la ventaja es que una vez que esos nodos se hayan actualizado, en el futuro debería ser posible agregar nuevas características al estándar y solo actualizar los nodos de red que soportan las funciones.

A continuación, se muestra un resumen de algunas funcionalidades nuevas de ejemplo que deben ser soportadas por la parte B:

[Caso 1] El nodo de origen debe enviar un contexto de UE codificado de tal manera que el nodo de destino pueda comprender todos los parámetros heredados necesarios e ignorar los nuevos parámetros. La codificación podría, por ejemplo, utilizar extensiones no críticas, que los eNB de destino heredados podrían ignorar.

[Caso 1] El nodo de destino debe reconstruir el contexto UE usando una combinación de información de contexto S1 o NG y parámetros que comprende del contexto UE enviado desde el nodo de origen.

[Caso 2] El nodo de origen debe obtener información del nodo de destino sobre qué versión de la especificación del estándar comprende o qué rasgos soporta. Esto podría señalizarse en un mensaje desde el nodo de destino al de origen durante la configuración de X2 o Xn.

[Caso 2] El nodo de origen debe codificar la información de contexto de UE de una manera que el nodo de destino pueda entender. En caso de que el nodo de destino soporte versiones posteriores que el nodo de origen, se supone que el nodo de destino debe entender el código del nodo de origen de acuerdo con su propia versión. A continuación, el contexto se envía a través de X2, Xn o mediante la red central al nodo de destino.

[Caso 2] El nodo de destino debe activar una reconfiguración de todos los portadores u otros parámetros de configuración relevantes, incluso en caso de que use la misma configuración que antes. El propósito de esto es informar al UE, que soporta versiones posteriores, que la configuración se revierte a la configuración heredada. Pasando ahora a la figura 18, se describirá un diagrama de flujo de un método 370 para reanudar una conexión para un dispositivo inalámbrico en una red de comunicaciones, de acuerdo con un ejemplo útil para comprender la invención. El nodo de red de comunicaciones puede ser la red 200. El dispositivo inalámbrico puede ser el UE 210. El método 370 se puede implementar en un nodo de red, como la red 220 de la figura 14.

El método 370 incluye:

Paso 375: recibir, desde un dispositivo inalámbrico, una solicitud para reanudar una conexión en una red de comunicación;

Paso 380: basándose en la solicitud, recuperar información de configuración para el dispositivo inalámbrico; en el que la información de configuración se adapta desde un nodo de red de origen al nodo de red para que pueda ser usada por el nodo de red; y

Paso 385: enviar un mensaje de respuesta de reanudación al dispositivo inalámbrico para reanudar la conexión basándose en la información de configuración adaptada.

Por ejemplo, la información de configuración puede adaptarse codificando al menos partes de la información de configuración para que sean legibles tanto por el nodo de red como por el nodo de red de origen.

En algunos ejemplos, la información de configuración se adapta convirtiendo el formato de la información de configuración del nodo de red de origen a un formato del nodo de red.

La figura 19 es un diagrama de bloques de un nodo 220 de red de radio de ejemplo, de acuerdo con ciertas realizaciones. El nodo 220 de red de radio puede incluir uno o transceptores 420 con múltiples antenas, procesador 440, memoria 450 e interfaz 430 de red. En algunas realizaciones, el transceptor facilita la transmisión de señales inalámbricas y la recepción de señales inalámbricas desde el dispositivo inalámbrico 210 (por ejemplo, a través de transmisores (Tx), receptores (Rx) y antenas). El procesador 440 ejecuta instrucciones para proporcionar algunas o todas las funcionalidades descritas anteriormente como proporcionadas por un nodo 220 de red de radio, la memoria almacena las instrucciones ejecutadas por el procesador en algunas realizaciones, el procesador 440 y la memoria 450 forman la circuitería 410 de procesamiento. La interfaz de red comunica señales a los componentes de la red de fondo, como una puerta de enlace, conmutador, enrutador, Internet, red telefónica pública conmutada (PSTN), nodos de red central o controladores de red de radio, etc.

El procesador 440 puede incluir cualquier combinación adecuada de hardware para ejecutar instrucciones y manipular datos para realizar algunas o todas las funciones descritas del nodo 220 de red de radio, como las descritas anteriormente, por ejemplo, los métodos 300 de la figura 15 y 330 de la figura 16 y sus realizaciones relacionadas. En algunas realizaciones, el procesador puede incluir, por ejemplo, una o más computadoras, una o más unidades centrales de procesamiento (CPU), uno o más microprocesadores, uno o más circuitos integrados de aplicación específica (ASIC), una o más matrices de puertas programables en campo. (FPGA) y/u otra lógica.

La memoria es generalmente operable para almacenar instrucciones, tales como un programa informático, software, una aplicación que incluye una o más de lógica, reglas, algoritmos, código, tablas, etc. y/u otras instrucciones que pueden ser ejecutadas por un procesador. Los ejemplos de memoria incluyen memoria informática (por ejemplo, memoria de acceso aleatorio (RAM) o memoria de solo lectura (ROM)), medios de almacenamiento masivo (por ejemplo, un disco duro), medios de almacenamiento extraíbles (por ejemplo, un disco compacto (CD) o un disco de video digital (DVD)), y/o cualquier otro dispositivo de memoria volátil o no volátil, no transitorio, legible por computadora y/o ejecutable por computadora que almacene información.

En algunas realizaciones, la interfaz de red está acoplada comunicativamente al procesador y puede referirse a cualquier dispositivo adecuado que pueda funcionar para recibir la entrada para el nodo 220 de red de radio, enviar la salida desde el nodo 220 de red de radio, realizar el procesamiento adecuado de la entrada o la salida o ambas, comunicar a otros dispositivos, o cualquier combinación de los anteriores. La interfaz de red puede incluir hardware apropiado (por ejemplo, puerto, módem, tarjeta de interfaz de red, etc.) y software, incluidas las capacidades de conversión de protocolo y procesamiento de datos, para comunicarse a través de una red.

Otras realizaciones del nodo 220 de red de radio pueden incluir componentes adicionales más allá de los que se muestran en la figura 19 que pueden ser responsables de proporcionar ciertos aspectos de las funcionalidades del nodo de red de radio, incluida cualquiera de las funcionalidades descritas anteriormente y/o cualquier funcionalidad adicional (incluida cualquier funcionalidad necesaria para soportar las soluciones descritas anteriormente). Los diversos tipos diferentes de nodos de red pueden incluir componentes que tienen el mismo hardware físico pero configurados (por ejemplo, mediante programación) para soportar diferentes tecnologías de acceso de radio, o pueden representar componentes físicos parcial o completamente diferentes.

Los procesadores, interfaces y memoria similares a los descritos con respecto a la figura 19 pueden incluirse en otros nodos de red (como el nodo 230 de red central). Otros nodos de red pueden incluir opcionalmente o no una interfaz inalámbrica (como el transceptor descrito en la figura 19).

En algunas realizaciones, el nodo 220 de red puede comprender una serie de módulos 510 (véase la figura 20) configurados para implementar las funcionalidades del nodo 220 de red descritas anteriormente. Con referencia a la figura 20, en algunas realizaciones, el nodo 220 de red puede comprender un módulo de recepción configurado para recibir, desde un dispositivo inalámbrico, una solicitud para reanudar una conexión. La red 220 puede comprender, por ejemplo, un módulo de envío configurado para enviar un mensaje de respuesta de reanudación al dispositivo inalámbrico, comprendiendo el mensaje una indicación para realizar una configuración completa. El nodo 220 de red también puede comprender un módulo de recepción configurado para recibir una solicitud para reanudar una conexión desde un dispositivo inalámbrico. El nodo de red puede comprender otros módulos configurados para realizar las funcionalidades del método 300 de la figura 15, por ejemplo.

Se apreciará que los diversos módulos se pueden implementar como una combinación de hardware y/o software, por ejemplo, el procesador, la memoria y el transceptor o transceptores del nodo 220 de red de radio que se muestra en la figura 19. Algunas realizaciones también pueden incluir módulos adicionales para soportar funcionalidades adicionales y/u opcionales.

En algunos ejemplos útiles para comprender la invención, el módulo de recuperación también puede configurarse para recuperar información de configuración para el dispositivo inalámbrico, en el que la información de configuración se adapta desde un nodo de red de origen al nodo de red para que pueda ser usada por el nodo de red. En algunos ejemplos útiles para comprender la invención, el módulo de envío también puede configurarse para enviar un mensaje de respuesta de reanudación al dispositivo inalámbrico para reanudar la conexión basándose en la información de configuración adaptada.

La figura 21 ilustra un diagrama de bloques esquemático de un dispositivo inalámbrico 210 de acuerdo con algunas realizaciones de la presente divulgación. Como se ilustra, el dispositivo inalámbrico 210 incluye circuitería/circuito 610 que comprenden uno o más procesadores 620 (por ejemplo, unidades centrales de procesamiento (CPU), circuitos integrados de aplicación específica (ASIC), matrices de puertas programables en campo (FPGA) y/o similares) y memoria 630. El dispositivo inalámbrico 210 también incluye uno o más transceptores 640, cada uno de los cuales incluye uno o más transmisores 650 y uno o más receptores 660 acoplados a una o más antenas 670. En algunas realizaciones, la funcionalidad del dispositivo inalámbrico 210 descrito anteriormente puede implementarse total o parcialmente en software que, por ejemplo, se almacena en la memoria 630 y se ejecuta por el procesador 620. Por ejemplo, el procesador 620 está configurado para realizar cualquier operación relacionada con el UE, por ejemplo, el método 350 de la figura 17.

En algunas realizaciones, se proporciona un programa informático que incluye instrucciones que, cuando se ejecuta por al menos dicho procesador 620, hace que al menos dicho procesador 620 lleve a cabo la funcionalidad del dispositivo inalámbrico 210 de acuerdo con cualquiera de las realizaciones descritas en el presente documento (por ejemplo cualquier operación relacionada con el UE, por ejemplo, el método 350 de la figura 17). En algunas realizaciones, se proporciona una portadora que contiene el producto de programa informático mencionado anteriormente. La portadora es una señal electrónica, una señal óptica, una señal de radio o un medio de almacenamiento legible por computadora (por ejemplo, un medio legible por computadora no transitorio como la memoria).

La figura 22 es un diagrama de bloques esquemático del dispositivo inalámbrico 210 de acuerdo con algunas otras realizaciones de la presente divulgación. El dispositivo inalámbrico 210 incluye uno o más módulos 700, cada uno de los cuales está implementado en software. El módulo o módulos 700 proporcionan la funcionalidad del dispositivo inalámbrico 210 descrito en el presente documento. Por ejemplo, los módulos 700 pueden comprender un módulo de envío operable para realizar al menos el paso 355 de la figura 17, un módulo receptor operable para realizar al menos el paso 360 de la figura 17 y un módulo de aplicación operable para realizar al menos el paso 365 de la figura 17.

Las realizaciones también se pueden practicar en entornos informáticos distribuidos donde las tareas se realizan mediante dispositivos de procesamiento remotos que están conectados a través de una red de comunicaciones.

Por ejemplo, la figura 23 es un diagrama de bloques esquemático que ilustra un entorno 800 de virtualización en el que las funciones implementadas por algunas realizaciones pueden virtualizarse. En el presente contexto, virtualizar significa crear versiones virtuales de aparatos o dispositivos que pueden incluir virtualizar plataformas de hardware, dispositivos de almacenamiento y recursos de red. Como se usa en el presente documento, la virtualización se puede aplicar a un nodo 220 de red (por ejemplo, una estación base virtualizada o un nodo de acceso de radio virtualizado) o a un dispositivo 210 (por ejemplo, un UE, un dispositivo inalámbrico o cualquier otro tipo de dispositivo de comunicación) o componentes del mismo y se relaciona con una implementación en la que al menos una parte de la funcionalidad se implementa como uno o más componentes virtuales (por ejemplo, a través de una o más aplicaciones, componentes, funciones, máquinas virtuales o contenedores que se ejecutan en uno o más nodos de procesamiento físico en una o más redes).

En algunas realizaciones, algunas o todas las funciones descritas en el presente documento pueden implementarse como componentes virtuales ejecutados por una o más máquinas virtuales implementadas en uno o más entornos virtuales 800 alojados por uno o más de los nodos de hardware QQ330. Además, en realizaciones en las que el nodo virtual no es un nodo de acceso de radio o no requiere conectividad por radio (por ejemplo, un nodo de red central), entonces el nodo de red puede virtualizarse por completo.

Las funciones pueden ser implementadas por una o más aplicaciones QQ320 (que alternativamente pueden denominarse instancias de software, dispositivos virtuales, funciones de red, nodos virtuales, funciones de red virtuales, etc.) operativas para implementar algunas de las características, funciones y/o beneficios de algunas de las realizaciones divulgadas en el presente documento. Las aplicaciones QQ320 se ejecutan en el entorno 800 de virtualización que proporciona hardware QQ330 que comprende la circuitería de procesamiento QQ360 y la memoria QQ390. La memoria QQ390 contiene las instrucciones QQ395 ejecutables mediante la circuitería de procesamiento QQ360 mediante las cuales la aplicación QQ320 está operativa para proporcionar una o más de las características, beneficios y/o funciones divulgadas en el presente documento.

El entorno 800 de virtualización comprende dispositivos de hardware de red de uso general o de propósito especial QQ330 que comprende un conjunto de uno o más procesadores o circuitería de procesamiento QQ360, que pueden ser procesadores comerciales listos para usar (COTS), circuitos integrados de aplicación específica (ASIC) dedicados, o cualquier otro tipo de circuitería de procesamiento, incluidos componentes de hardware digitales o analógicos o procesadores de propósito especial. Cada dispositivo de hardware puede comprender la memoria QQ390-1 que puede ser una memoria no persistente para almacenar temporalmente las instrucciones QQ395 o el software ejecutado por la circuitería de procesamiento QQ360. Cada dispositivo de hardware puede comprender uno o más controladores de interfaz de red (NIC) QQ370, también conocidos como tarjetas de interfaz de red, que incluyen la interfaz de red física QQ380. Cada dispositivo de hardware también puede incluir un medio de almacenamiento QQ390-2 no transitorio, persistente y legible por máquina que tiene almacenado en el mismo el software QQ395 y/o instrucciones ejecutables mediante la circuitería de procesamiento QQ360. El software QQ395 puede incluir cualquier tipo de software, incluido el software para crear instancias de una o más capas de virtualización QQ350 (también conocidas como hipervisores), software para ejecutar máquinas virtuales QQ340, así como software que le permite ejecutar funciones, rasgos y/o beneficios descritos en relación con algunas realizaciones descritas en el presente documento.

Las máquinas virtuales QQ340 comprenden procesamiento virtual, memoria virtual, red virtual o interfaz y almacenamiento virtual, y pueden ser ejecutadas por una capa de virtualización QQ350 o hipervisor correspondiente. Se pueden implementar diferentes realizaciones de la instancia del dispositivo virtual QQ320 en una o más de las máquinas virtuales QQ340, y las implementaciones se pueden realizar de diferentes formas.

Durante el funcionamiento, la circuitería de procesamiento QQ360 ejecuta el software QQ395 para instanciar el hipervisor o la capa de virtualización QQ350, que a veces puede denominarse monitor de máquina virtual (VMM). La capa de virtualización QQ350 puede presentar una plataforma operativa virtual que aparece como hardware de red en la máquina virtual QQ340.

Como se muestra en la figura QQ3, el hardware QQ330 puede ser un nodo de red independiente con componentes genéricos o específicos. El hardware QQ330 puede comprender la antena QQ3225 y puede implementar algunas funciones a través de la virtualización. Alternativamente, el hardware QQ330 puede ser parte de un grupo de hardware más grande (por ejemplo, en un centro de datos o en un equipo en las instalaciones del cliente (CPE)) donde muchos nodos de hardware funcionan juntos y se gestionan mediante gestión y orquestación (MANO) QQ3100, que, entre otros, supervisa la gestión del ciclo de vida de las aplicaciones QQ320.

En algunos contextos, la virtualización del hardware se denomina virtualización de funciones de red (NFV). NFV se puede usar para consolidar muchos tipos de equipos de red en hardware de servidor de alto volumen estándar de la industria, conmutadores físicos y almacenamiento físico, que se pueden ubicar en centros de datos y equipos en las instalaciones del cliente.

En el contexto de NFV, la máquina virtual QQ340 puede ser una implementación de software de una máquina física que ejecuta programas como si se estuvieran ejecutando en una máquina física no virtualizada. Cada una de las máquinas virtuales QQ340, y la parte del hardware QQ330 que ejecuta esa máquina virtual, ya sea hardware dedicado a esa máquina virtual y/o hardware compartido por esa máquina virtual con otras de las máquinas virtuales QQ340, forma elementos de red virtual separados (VNE).

Aún en el contexto de NFV, la función de red virtual (VNF) es responsable de manejar funciones de red específicas que se ejecutan en una o más máquinas virtuales QQ340 sobre la infraestructura de red de hardware QQ330 y corresponde a la aplicación QQ320 en la figura QQ3.

En algunas realizaciones, una o más unidades de radio QQ3200 que cada una incluye uno o más transmisores QQ3220 y uno o más receptores QQ3210 pueden acoplarse a una o más antenas QQ3225. Las unidades de radio QQ3200 pueden comunicarse directamente con los nodos de hardware QQ330 a través de una o más interfaces de red apropiadas y pueden usarse en combinación con los componentes virtuales para proporcionar un nodo virtual con capacidades de radio, como un nodo de acceso de radio o una estación base.

En algunas realizaciones, se puede realizar alguna señalización con el uso del sistema de control QQ3230 que puede usarse alternativamente para la comunicación entre los nodos de hardware QQ330 y las unidades de radio QQ3200.

Algunas realizaciones pueden representarse como un producto de software no transitorio almacenado en un medio legible por máquina (también denominado medio legible por computadora, medio legible por procesador o medio utilizable por computadora que tiene un código de programa legible por computadora incorporado en el mismo) . El medio legible por máquina puede ser cualquier medio tangible adecuado, incluido un medio de almacenamiento magnético, óptico o eléctrico, incluido un disquete, un disco compacto de memoria de solo lectura (CD-ROM), un disco versátil digital de memoria de solo lectura (DVD-ROM), un dispositivo de memoria (volátil o no volátil) o un mecanismo de almacenamiento similar. El medio legible por máquina puede contener varios conjuntos de instrucciones, secuencias de códigos, información de configuración u otros datos que, cuando se ejecutan, hacen que un procesador realice pasos en un método de acuerdo con una o más de las realizaciones descritas. Los expertos en la técnica apreciarán que también se pueden almacenar en el medio legible por máquina otras instrucciones y operaciones necesarias para implementar las realizaciones descritas. El software que se ejecuta desde el medio legible por máquina puede interactuar con la circuitería para realizar las tareas descritas.

Las realizaciones descritas anteriormente están destinadas a ser solo ejemplos. Los expertos en la técnica pueden realizar alteraciones, modificaciones y variaciones en las realizaciones particulares sin apartarse del alcance de la descripción.

Claims (15)

REIVINDICACIONES

1. - Un método en un nodo de red, el método comprende:

- recibir, desde un dispositivo inalámbrico, una solicitud para reanudar una conexión en una red de comunicación; - en respuesta a la solicitud, enviar un mensaje de reanudación al dispositivo inalámbrico, caracterizándose el método porque el mensaje comprende una indicación para realizar una configuración completa.

2. - El método de la reivindicación 1, en el que la indicación comprende un indicador.

3. - El método de la reivindicación 2, que comprende además establecer el indicador en configuración completa.

4. - El método de una cualquiera de las reivindicaciones 1 a 3, que comprende además recuperar información de configuración para el dispositivo inalámbrico; en el que, como opción, la información de configuración recuperada comprende el contexto de equipo de usuario (UE) del dispositivo inalámbrico.

5. - El método de una cualquiera de las reivindicaciones 1 a 4, en el que el mensaje comprende además parámetros de configuración; en el que, como opción, la indicación comprende una indicación para realizar una configuración completa usando los parámetros de configuración.

6. - El método de una cualquiera de las reivindicaciones 1 a 5, en el que el mensaje de respuesta de reanudación es uno de un RRCConnectionResume y un RRCResume.

7. - El método de la reivindicación 4, que comprende además en respuesta a la determinación de que la información de configuración recuperada es ilegible, generando parámetros de configuración; en el que, como opción, la generación de los parámetros de configuración se basa en el contexto S1 y NG que contiene información del portador usada durante una configuración de contexto inicial.

8. - El método de la reivindicación 5 o 7, en el que los parámetros de configuración comprenden uno o más de la configuración de portador, la configuración de protocolo de convergencia de datos en paquetes (PDCP), la configuración de control de enlace de radio (RLC).

9. - Un nodo de red que comprende:

una interfaz de comunicación; y

uno o más circuitos de procesamiento conectados comunicativamente a la interfaz de comunicación, dicho o más circuitos de procesamiento que comprenden al menos un procesador y una memoria, la memoria contiene instrucciones que, cuando se ejecutan, hacen que al menos dicho procesador realice el método de cualquiera de las reivindicaciones 1 hasta 8.

10. - Un método en un dispositivo inalámbrico, el método comprende:

- enviar a un nodo de red una solicitud para reanudar una conexión en una red de comunicación;

- recibir un mensaje de reanudación del nodo de red, el método se caracteriza

- porque el mensaje comprende una indicación para realizar una configuración completa; y

- por aplicar la configuración completa.

11. - El método de la reivindicación 10, que comprende además descartar una configuración de portador antigua y parámetros de radio antiguos.

12. - El método de la reivindicación 10 u 11, que comprende además mantener llaves de seguridad.

13. - El método de una cualquiera de las reivindicaciones 10 a 12, que comprende además recibir una configuración y, opcionalmente, aplicar la configuración recibida.

14. - Un dispositivo inalámbrico, que comprende una interfaz de comunicación; y uno o más circuitos de procesamiento conectados comunicativamente a la interfaz de comunicación, comprendiendo dicho o más circuitos de procesamiento al menos un procesador y una memoria, conteniendo la memoria instrucciones que, cuando se ejecutan, hacen que al menos dicho procesador realice el método de cualquiera de las reivindicaciones 10 a 13.

15.- Un producto de programa informático que comprende un medio (450, 630) de almacenamiento legible por computadora no transitorio que tiene un código de programa legible por computadora incorporado en el medio, estando configurado el código de programa legible por computadora para hacer que al menos un procesador (440, 620) realice el método de cualquiera de las reivindicaciones 1 a 8 y 10 a 13 cuando se ejecuta por al menos dicho procesador (440, 620).