ES2947738T3 - Manejo de la configuración de medida en el traspaso condicional - Google Patents

Abstract

Las realizaciones incluyen métodos para la movilidad condicional en una red de acceso por radio (RAN), realizados por un equipo de usuario (UE). Dichos métodos incluyen recibir, desde uno o más nodos RAN (por ejemplo, nodo RAN de origen y/o nodo RAN de destino), uno o más mensajes relacionados con la movilidad que incluyen: una primera indicación de una operación de movilidad; una segunda indicación de una condición de activación para la operación de movilidad; una segunda configuración de medición relacionada con la condición de disparo; y una tercera configuración de medición relacionada con una o más celdas objetivo. Dichos métodos también incluyen, en base a la segunda configuración de medición, detectar el cumplimiento de la condición de activación con respecto a una celda objetivo particular y ejecutar la operación de movilidad hacia la celda objetivo particular. y posteriormente realizar e informar terceras mediciones en la celda objetivo particular en base a la tercera configuración de medición. Las realizaciones también incluyen métodos complementarios realizados por nodos de RAN de origen y nodos de RAN de destino. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Manejo de la configuración de medida en el traspaso condicional

Campo técnico

La presente solicitud se relaciona, en general, con el campo de las comunicaciones inalámbricas, y más específicamente con dispositivos, métodos, y medios legibles por ordenador que mejoran las operaciones de movilidad de dispositivos inalámbricos o equipos de usuario (UEs) en una red inalámbrica.

Antecedentes

En general, todos los términos utilizados en la presente memoria deben interpretarse según su significado ordinario en el campo técnico relevante, a menos que se proporcione claramente un significado diferente y/o esté implícito a partir del contexto en el que se utiliza. Todas las referencias a un/una/el elemento, aparato, componente, medio, paso, etc. deben interpretarse abiertamente como referencias a, al menos, una instancia del elemento, aparato, componente, medio, paso, etc., a menos que se indique explícitamente lo contrario. Los pasos de los métodos y/o procedimientos descritos en la presente memoria no tienen que realizarse en el orden exacto descrito, a menos que un paso se describa explícitamente como siguiente o anterior a otro paso y/o donde esté implícito que un paso debe seguir o preceder a otro paso. Cualquier característica de cualquiera de las realizaciones descritas en la presente memoria puede aplicarse a cualquier otra realización, donde sea apropiado. Asimismo, cualquier ventaja de cualquiera de las realizaciones puede aplicar a cualquier otra realización, y viceversa. Otros objetivos, características y ventajas de las realizaciones adjuntas serán evidentes a partir de la siguiente descripción.

La Evolución a Largo Plazo (LTE) es un término general para las llamadas tecnologías de acceso por radio de cuarta generación (4G) desarrolladas dentro del Proyecto de Asociación de Tercera generación (3GPP) e inicialmente estandarizadas en las Versiones 8 y 9, también conocidas como UTRAN Evolucionado (E-UTRAN). LTE está dirigido a varias bandas de frecuencia con licencia y va acompañado de mejoras en aspectos que no son de radio comúnmente denominados Evolución de la Arquitectura del Sistema (SAE), que incluye la red Central de Paquetes Evolucionada (EPC). LTE continúa evolucionando a través de versiones posteriores que se desarrollan según procesos de establecimiento de estándares con el 3GPP y sus grupos de trabajo (WGs), incluido el WG de la Red de Acceso por Radio (RAN), y sub-grupos de trabajo. (p.ej, RANI, rAn 2, etc...).

La Versión 10 (Rel-10) de LTE admite anchos de banda superiores a 20 MHz. Un requisito importante en Rel-10 es garantizar la compatibilidad con versiones anteriores con LTE Versión-8. Esto también debería incluir compatibilidad de espectro. Como tal, una portadora de LTE Rel-10 de banda ancha (p. ej., más ancha de 20 MHz) debería aparecer como una serie de portadoras para un terminal de LTE Rel-8 ("heredado"). Cada uno de dichas portadoras puede denominarse Portadora de Componentes (CC). Para un uso eficiente de una portadora amplia también para terminales heredados, los terminales heredados pueden programarse en todas las partes de la portadora de LTE Rel-10 de banda ancha. Una forma ejemplar de lograr esto es mediante la Agregación de Portadora (CA), mediante la cual un terminal de Rel-10 puede recibir múltiples CCs, cada una de las cuales tiene, preferiblemente, la misma estructura que una portadora de Rel-8. Una de las mejoras en LTE Rel-11 es un Canal Físico de Control del Enlace Descendente mejorado (ePDCCH), que tiene los objetivos de aumentar la capacidad y mejorar la reutilización espacial de los recursos del canal de control, mejorar la coordinación de interferencia entre celdas (ICIC), y admitir formación de haces de antena y/o diversidad de transmisión para el canal de control. Además, LTE Rel-12 introdujo la conectividad dual (DC) mediante la cual un UE puede conectarse a dos nodos de red simultáneamente, mejorando así la robustez y/o capacidad de la conexión.

Se muestra en la Figura 1 una arquitectura ejemplar general de una red que comprende LTE y SAE. E-UTRAN 100 comprende uno o más Nodos B evolucionados (eNBS), como eNBs 105, 110 y 115, y uno o más equipos de usuario (UE), como UE 120. Como se utiliza dentro de los estándares del 3GPP, "equipo de usuario" o "UE" significa cualquier dispositivo de comunicación inalámbrico (p. ej., un teléfono inteligente o un dispositivo informático) que es capaz de comunicarse con un equipo de red compatible con estándares del 3GPP, incluidos E-UTRAN así como UTRAN y/o GERAN, como se conocen comúnmente las redes de acceso por radio del 3GPP de tercera ("3G") y segunda generación ("2G").

Según lo especificado por el 3GPP, E-UTRAN 100 es responsable de todas las funciones relacionadas con la radio en la red, incluido el control del portador de radio, el control de la admisión de radio, el control de la movilidad de radio, la programación, y la asignación dinámica de recursos a los UEs en el enlace ascendente y el enlace descendente, así como la seguridad de las comunicaciones con el UE. Estas funciones residen en los eNBs, como los eNBs 105, 110, y 115. Los eNBs en la E-UTRAN se comunican entre sí a través de la interfaz X2, como se muestra en la Figura 1. Los eNBs también son responsables de la interfaz de la E-UTRAN a la EPC 130, específicamente la interfaz S1 para la Entidad de Gestión de la Movilidad (MME) y la Puerta de Enlace de Servicio (SGW), mostradas colectivamente como MME/S-GW 134 y 138 en la Figura 1. En términos generales, la MME/S-GW maneja tanto el control general del UE como el flujo de datos entre el UE y el resto de la EPC. Más específicamente, la MME procesa los protocolos de señalización (p. ej., plano de control) entre el UE y la EPC, que se conocen como protocolos de Estrato Sin Acceso (NAS). La S-GW maneja todos los paquetes de datos del Protocolo de Internet (IP) (p. ej., datos o plano de usuario) entre el UE y la EPC, y sirve como ancla de movilidad local para los portadores de datos cuando el UE se mueve entre eNBs, como los eNBs 105, 110, y 115.

La EPC 130 también puede incluir un Servidor Local de Abonado (HSS) 131, que gestiona la información relacionada con el usuario y el abonado. El HSS 131 también puede proporcionar funciones de soporte en gestión de la movilidad, configuración de llamadas y sesiones, autenticación de usuarios y autorización de acceso. Las funciones del HSS 131 pueden relacionarse con las funciones del Registro Local de Ubicación (HLR) heredado y con las funciones u operaciones del Centro de Autenticación (AuC).

En algunas realizaciones, el HSS 131 puede comunicarse con un repositorio de datos de usuario (UDR), etiquetado como EPC-UDR 135 en la Figura 1, a través de una interfaz Ud. El EPC-UDR 135 puede almacenar credenciales de usuario después de que hayan sido encriptadas por algoritmos del AuC. Estos algoritmos no están estandarizados (es decir, son específicos del proveedor), de modo que las credenciales encriptadas almacenadas en el EPC-UDR 135 a menudo son inaccesibles para cualquier otro proveedor que no sea el proveedor del HSS 131.

La Figura 2A muestra un diagrama de bloques de alto nivel de una arquitectura LTE ejemplar en términos de sus entidades constituyentes - UE, E-UTRAN, y EPC - y una división funcional de alto nivel en el Estrato de Acceso (AS) y el Estrato Sin Acceso (NAS). La Figura 2A también ilustra dos puntos de interfaz en particular, a saber, Uu (Interfaz de Radio UE/E-UTRAN) y S1 (interfaz E-UTRAN/EPC), cada uno utilizando un conjunto específico de protocolos, es decir, Protocolos de Radio y Protocolos S1. Aunque no se muestra en la Figura 2A, cada uno de los conjuntos de protocolos puede segmentarse aún más en la funcionalidad del protocolo del plano de usuario y del plano de control. Los planos de usuario y de control también se denominan plano U y plano C, respectivamente. En la interfaz Uu, el plano U transporta información del usuario (p. ej., paquetes de datos) mientras que el plano C transporta información de control entre el UE y la E-UTRAN.

La Figura 2B ilustra un diagrama de bloques de una pila de protocolos del plano C ejemplar entre un UE, un eNB, y una MME. La pila de protocolos ejemplo incluye capas Física (PHY), de Control de Acceso al Medio (MAC), de Control del Enlace de Radio (RLC), del Protocolo de Convergencia de Datos en Paquetes (PDCP), y de Control de Recursos de Radio (RRC) entre el UE y el eNB. La capa PHY se ocupa de cómo y qué características se utilizan para transferir datos a través de canales de transporte en la interfaz de radio lTe . La capa MAC proporciona servicios de transferencia de datos en canales lógicos, asigna canales lógicos a canales de transporte PHY, y reasigna recursos PHY para admitir estos servicios. La capa RLC proporciona detección y/o corrección de errores, concatenación, segmentación, y re-ensamblaje, reordenación de datos transferidos hacia o desde las capas superiores. Las capas PHY, MAC, y r Lc realizan funciones idénticas tanto para el plano U como para el plano C. La capa PDCP proporciona cifrado/descifrado y protección de integridad tanto para el plano U como para el plano C, así como otras funciones para el plano U, como la compresión de la cabecera. La pila de protocolos ejemplar también incluye señalización de estrato sin acceso (NAS) entre el UE y la MME.

La Figura 2C muestra un diagrama de bloques de una arquitectura del protocolo de la interfaz de radio LTE ejemplar desde la perspectiva de la capa PHY. Las interfaces entre las distintas capas son proporcionadas por Puntos de Acceso al Servicio (SAPs), indicados por los óvalos en la Figura 2C. La capa PHY interactúa con las capas del protocolo MAC y RRC descritas anteriormente. PHY, MAC y RRC también se denominan Capas 1 -3, respectivamente, en la figura. El MAC proporciona diferentes canales lógicos a la capa del protocolo RLC (también descrito anteriormente), caracterizados por el tipo de información transferida, mientras que la PHY proporciona un canal de transporte al MAC, caracterizado por cómo se transfiere la información a través de la interfaz de radio. Al proporcionar este servicio de transporte, la PHY realiza varias funciones, que incluyen detección y corrección de errores; ajuste de tasa y mapeo del canal de transporte codificado en canales físicos; ponderación de potencia, modulación, y demodulación de canales físicos; diversidad de transmisión; y procesamiento de antena de formación de haces de entrada múltiple y salida múltiple (MIMO). La capa PHY también recibe información de control (p. ej., comandos) del RRC y proporciona información diversa al RRC, como medidas de radio.

Los canales físicos del enlace descendente (es decir, nodo de red a UE) proporcionados por la PHY LTE incluyen el Canal Físico Compartido del Enlace Descendente (PDSCH), el Canal Físico de Multidifusión (PMCH), el Canal Físico de Control del Enlace Descendente (PDCCH), el Canal Físico de Control del Enlace Descendente de Retransmisión (R-PDCCH), el Canal Físico de Emisión (Pb Ch ), el Canal Físico Indicador del Formato de Control (PCFICH), y el Canal Físico Indicador de ARQ Híbrida (PHICH). Además, el enlace descendente PHY LTE incluye varias señales de referencia, señales de sincronización, y señales de descubrimiento.

Los canales físicos del enlace ascendente (es decir, UE a nodo de red) proporcionados por la PHY LTE incluyen el Canal Físico Compartido del Enlace Ascendente (PUSCH), el Canal Físico de Control del Enlace Ascendente (PUCCH), y el Canal Físico de Acceso aleatorio (PRACH). Además, el enlace ascendente PHY LTE incluye varias señales de referencia que incluyen señales de referencia de demodulación (DM-RS), que se transmiten para ayudar al nodo de red en la recepción de un PUCCH o PUSCH asociado; y señales de referencia de sondeo (SRS), que no están asociadas con ningún canal del enlace ascendente.

El esquema de acceso múltiple para la PHY LTE se basa en Multiplexación por División de Frecuencias Ortogonales (OFDM) con un prefijo cíclico (CP) en el enlace descendente, y en Acceso Múltiple por División de Frecuencia de Portadora Única (SC-FDMA) con un prefijo cíclico en el enlace ascendente. Para admitir la transmisión en espectro emparejado y no emparejado, la PHY LTE admite tanto Duplexación por División de Frecuencia (FDD) (incluido el funcionamiento tanto full como semidúplex) como Duplexación por División de Tiempo (TDD). La trama de radio del enlace descendente (DL) FDD LTE tiene una duración fija de 10 ms y consta de 20 intervalos, etiquetados del 0 al 19, cada uno con una duración fija de 0,5 ms. Una subtrama de 1 ms comprende dos intervalos consecutivos donde la subtrama i consta de los intervalos 2i y 2i + 1. Cada intervalo del DL FDD ejemplar consta de N^DLsymb símbolos OFDM, cada uno de los cuales se compone de N^sc subportadoras OFDM. Valores ejemplares de N^DLsymb pueden ser 7 (con un CP normal) o 6 (con un CP de longitud extendida) para un ancho de banda de subportadora de 15 kHz. El valor de N^sc se puede configurar según el ancho de banda del canal disponible. Dado que las personas de habilidad ordinaria en la técnica están familiarizadas con los principios de OFDM, se omiten más detalles en esta descripción.

Además, una combinación de una subportadora en particular en un símbolo en particular se conoce como elemento de recurso (RE). Cada RE se utiliza para transmitir un número en particular de bits, dependiendo del tipo de modulación y/o constelación de mapeo de bits utilizada para ese RE. Por ejemplo, algunos REs pueden transportar dos bits utilizando modulación QPSK, mientras que otros REs pueden transportar cuatro o seis bits usando 16- o 64-QAM, respectivamente. Los recursos de radio de la PHY LTE también se definen en términos de bloques físicos de recursos (PRBs). Un PRB abarca N^RBsc subportadoras durante la duración de un intervalo (es decir, N^DLsymb símbolos), donde N^RBsc suele ser 12 (con un ancho de banda de subportadora de 15 kHz) o 24 (ancho de banda de 7,5 kHz). Un PRB que abarca las mismas N^RBsc subportadoras durante una subtrama completa (es decir, 2N^DLsymb símbolos) se conoce como un par PRB. En consecuencia, los recursos disponibles en una subtrama del DL de la PHY LTE comprenden N^{d l rb} pares PRB, cada uno de los cuales comprende 2N^DLsymb ^ N^RBsc REs. Para un CP normal y un ancho de banda de subportadora de 15 KHz, un par PRB comprende 168 REs.

La trama de radio del enlace ascendente (UL) FDD LTE se configura de manera similar a la trama de radio del DL FDD ejemplar discutida anteriormente. Utilizando terminología consistente con la descripción del DL anterior, cada intervalo del UL consta de N^ULsymb símbolos OFDM, cada uno de los cuales se compone de N^sc subportadoras OFDM.

Como se discutió anteriormente, la PHY LTE asigna los diversos canales físicos del DL y del UL a los recursos PHY. Por ejemplo, el PHICH transporta retroalimentación HARQ (p. ej., ACK/NAK) para transmisiones del UL por parte de los UEs. De manera similar, un PDCCH transporta asignaciones de programación, retroalimentación de la calidad del canal (p. ej., CSI) para el canal del UL, y otra información de control. Del mismo modo, un PUCCH transporta información de control del enlace ascendente, como solicitudes de programación, CSI para el canal del enlace descendente, retroalimentación HARQ para transmisiones del DL del nodo de red, y otra información de control. Tanto el PDCCH como el PUCCH pueden transmitirse en agregaciones de uno o varios elementos del canal de control (CCEs) consecutivos, y un CCE se asigna al recurso físico en función de grupos de elementos de recursos (REGs), cada uno de los cuales se compone de una pluralidad de REs. Por ejemplo, un CCE puede comprender nueve (9) REGs, cada uno de los cuales puede comprender cuatro (4) REs.

Desde la versión 8 de LTE, tres Portadores de Radio de Señalización (SRBs), a saber, SRB0, SRB1 y SRB2, han estado disponibles para el transporte de mensajes RRC y de Estrato Sin Acceso (NAS) entre el UE y el nodo de red. También se introdujo un nuevo SRB, conocido como SRB1bis, en la rel-13 para admitir DoNAS (Datos Sobre NAS) en NB-IoT. SRB0 es para mensajes RRC que utilizan el canal lógico CCCH, y se utiliza para manejar la configuración 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 nodo de red (es decir, la configuración de la conexión RRC o el restablecimiento/reanudación de la conexión RRC ha tenido éxito), SRB1 se utiliza para manejar mensajes RRC (que pueden incluir un mensaje NAS superpuesto), así como para mensajes NAS antes del establecimiento de SRB2, todos utilizando el canal lógico DCCH. Por otro lado, SRB2 se utiliza para mensajes RRC, que incluyen información de medida registrada, así como para mensajes NAS, todos utilizando el canal lógico DCCH. SRB2 tiene una prioridad más baja que SRB1, porque la información de medida registrada y los mensajes NAS pueden ser extensos y podrían causar el bloqueo de mensajes SRB1 más urgentes y más pequeños. SRB2 siempre se configura mediante E-UTRAN después de la activación de seguridad.

Como se mencionó brevemente anteriormente, la capa RRC LTE (mostrada en las Figuras 2B-C) controla las comunicaciones entre un UE y un eNB en la interfaz de radio, así como la movilidad de un UE entre celdas en la E-UTRAN. Un procedimiento de movilidad común para UEs en estado RRC_CONECTADO (p. ej., con una conexión activa) es el traspaso (HO) entre celdas. Más específicamente, un UE se entrega desde una celda de origen o de servicio, proporcionada por un nodo de origen, a una celda objetivo proporcionada por un nodo objetivo. En general, para LTE, los nodos de origen y objetivo del traspaso son eNBs diferentes, aunque también es posible un traspaso dentro del nodo entre diferentes celdas proporcionadas por un solo eNB.

El concepto de “señalización delta” se ha introducido en los estándares del 3GPP para reducir la cantidad de señalización RCC entre red y UE. En los traspasos, por ejemplo, el nodo de origen puede proporcionar la configuración RRC actual del UE al nodo objetivo. Dada esta información, cuando el nodo objetivo prepara la configuración RRC a utilizar por parte del UE en la celda objetivo después del traspaso, solo necesita señalar el "delta" o la "diferencia" entre la configuración del UE actual y la nueva a utilizar en la celda objetivo. Dicha señalización delta normalmente se implementa con algunas características del protocolo, como "códigos de necesidad", listas AddMod, y variables del UE donde se almacenan las configuraciones recibidas.

Sin embargo, el traspaso puede tener varios problemas relacionados con la robustez. Por ejemplo, el comando HO (p.ej., RRCConnectionReconfiguration con mobilityControlInfo o RRCReconfiguration con una reconfigurationWithSync) normalmente se envía cuando las condiciones de radio para el UE ya son bastante malas. Como tal, el comando HO puede necesitar segmentarse (p. ej., para permitir la redundancia para proteger contra errores) y/o retransmitir (p. ej., utilizando HARQ) una o más veces antes de que llegue al UE. En dicho caso, el comando HO puede no llegar al UE a tiempo (o en absoluto) antes de que se interrumpa la conexión degradada con el nodo de origen (p. ej., el nodo que alberga la celda de servicio actual del UE).

Se han propuesto algunas técnicas de "movilidad condicional" para abordar estas y otras dificultades con los traspasos y otros procedimientos de movilidad. Sin embargo, estas técnicas propuestas adolecen de varias deficiencias -particularmente relacionadas con el uso de la señalización delta- que las hacen inadecuadas en varios casos de uso, escenarios, y/o condiciones. El documento KR20180122963 describe un método realizado por un terminal para realizar el traspaso a una celda objetivo candidata. Más particularmente, el documento KR20180122963 describe un método que comprende transmitir un primer mensaje que incluye información sobre una celda objetivo candidata (130). Un segundo mensaje que incluye información sobre la condición para el traspaso condicional asociado con la celda objetivo candidata se recibe desde una estación base (120) de servicio. El traspaso a la celda objetivo candidata se realiza cuando un resultado de medida sobre la celda objetivo candidata satisface una condición del traspaso condicional. La información delta aplicada a la configuración de la medida según un tipo de medida y la información de la configuración del estrato de acceso se utilizan si se realiza un proceso de traspaso en la celda objetivo candidata.

Compendio

Las realizaciones ejemplares de la presente descripción abordan los problemas relacionados con la movilidad en las redes de comunicación inalámbrica al proporcionar mejoras para las operaciones de movilidad, como traspasos (incluidos los traspasos condicionales) entre un nodo (o celda) de origen y un nodo (o celda) objetivo.

La invención se define en las reivindicaciones adjuntas.

Las realizaciones ejemplares de la presente descripción incluyen métodos (p. ej., procedimientos) para movilidad condicional en una red de acceso por radio (RAN). El método y/o procedimiento ejemplar puede ser realizado por un equipo de usuario (UE, p.ej., dispositivo inalámbrico, dispositivo MTC, dispositivo NB-IoT, módem, etc. o componente del mismo) en comunicación con un nodo de red (p.ej., estación base, eNB, gNB, etc., o componentes del mismo) que da servicio a una celda en la RAN (p. ej., E-UT^rAⁿ , NG-RAN).

En algunas realizaciones, estos métodos ejemplares pueden incluir recibir, desde un nodo RAN de origen que da servicio a la celda de origen del UE, una primera configuración de medida; almacenar la primera configuración de medida recibida; y realizar y reportar primeras medidas en la celda de origen del UE en función de la primera configuración de medida.

Estos métodos ejemplares también pueden incluir recibir, de la RAN, uno o más mensajes relacionados con la movilidad que comprenden: una primera indicación de una operación de movilidad; una segunda indicación de una condición de activación para la operación de movilidad; una segunda configuración de medida relacionada con una celda de origen; y una tercera configuración de medida relacionada con una o más celdas objetivo. En algunas realizaciones, uno o más mensajes relacionados con la movilidad pueden incluir un comando de movilidad condicional, recibido de un nodo de origen, que comprende las indicaciones primera y segunda y las configuraciones de medida segunda y tercera. Además, las configuraciones de medida segunda y tercera pueden incluir configuraciones de medida respectivas para cada celda objetivo que es una candidata para la operación de movilidad indicada.

En otras realizaciones, uno o más mensajes relacionados con la movilidad pueden incluir un comando de movilidad condicional, recibido de un nodo de origen, que incluye las indicaciones primera y segunda y la segunda configuración de medida; y un mensaje de reconfiguración, recibido de un nodo objetivo, que comprende la tercera configuración de medida.

Estos métodos ejemplares también pueden incluir, en función de la segunda configuración de medida, detectar el cumplimiento de la condición de activación con respecto a una en particular de las celdas objetivo y ejecutar la operación de movilidad hacia el objetivo en particular.

En algunas realizaciones, detectar el cumplimiento de la condición de activación puede incluir la realización de segundas medidas en la celda de origen en función de la segunda configuración de medida. En algunas realizaciones, ejecutar la operación de movilidad puede incluir una o más de las siguientes operaciones: detener la realización de segundas medidas en función de la segunda configuración de medida; borrar o liberar, al menos, una parte de una segunda configuración de medida almacenada; y almacenar la tercera configuración de medida.

En algunas realizaciones, la tercera configuración de medida puede recibirse como una configuración de medida completa. En dichas realizaciones, ejecutar la operación de movilidad puede incluir reemplazar una primera configuración de medida almacenada con la tercera configuración de medida.

En otras realizaciones, la tercera configuración de medida puede recibirse como un delta con respecto a la primera configuración de medida y/o a la segunda configuración de medida. En dichas realizaciones, ejecutar la operación de movilidad puede incluir determinar una configuración de medida, para las terceras medidas, en función de la tercera configuración de medida y una o más de la primera configuración de medida y de la segunda configuración de medida.

En algunas realizaciones, como cuando uno o más mensajes relacionados con la movilidad incluyen un comando de movilidad condicional y un mensaje de reconfiguración, ejecutar la operación de movilidad puede incluir realizar y reportar terceras medidas en la celda objetivo en particular en función de la segunda configuración de medida (p. ej., recibido en el comando de movilidad condicional), y posteriormente recibir el mensaje de reconfiguración que comprende la tercera configuración de medida (p. ej., en el mensaje de reconfiguración).

Estos métodos ejemplares también pueden incluir realizar y reportar terceras medidas en la celda objetivo en particular en función de la tercera configuración de medida.

Otras realizaciones ejemplares de la presente descripción incluyen métodos adicionales (p. ej., procedimientos) para la movilidad condicional de un equipo de usuario (UE) en una red de acceso por radio (RAN). Estos métodos ejemplares pueden ser realizados por un nodo RAN de origen (p. ej., estación base, eNB, gNB, etc., o componente del mismo) que da servicio a uno o más equipos de usuario (UEs, p. ej., dispositivos inalámbricos, dispositivos MTC, dispositivos NB-IoT, módems, etc. o componentes de los mismos) en una celda de la RAN (p. ej., E-UTRAN, NG-RAN).

En algunas realizaciones, estos métodos ejemplares pueden incluir enviar, al UE, una primera configuración de medida relacionada con una celda de origen, para el UE, que es servida por el nodo RAN de origen; puede recibir primeras medidas realizadas por el UE en la celda de origen en función de la primera configuración de medida; y determinar que se requiere una operación de movilidad para el UE, en función de las primeras medidas.

Estos métodos ejemplares también pueden incluir enviar, a un nodo objetivo, una solicitud para aceptar una operación de movilidad relacionada con el UE (p. ej., como se determinó anteriormente). En algunas realizaciones, la solicitud puede incluir la primera configuración de medida para el UE. Estos métodos ejemplares también pueden incluir recibir, del nodo RAN objetivo, una confirmación de la operación de movilidad, incluyendo la confirmación una tercera configuración de medida relacionada con una o más celdas objetivo servidas por el nodo RAN objetivo. Estos métodos ejemplares también pueden incluir determinar una segunda configuración de medida relacionada con una condición de activación para la operación de movilidad. Por ejemplo, la segunda configuración de medida puede utilizarse para detectar el cumplimiento de la condición de activación en la celda de origen del UE. En algunas realizaciones, determinar la segunda configuración de medida también puede incluir enviar la segunda configuración de medida al nodo RAN objetivo.

En algunas realizaciones, aplica, al menos, una de las siguientes condiciones: la segunda configuración de medida se determina como un delta con respecto a la primera configuración de medida; la tercera configuración de medida se recibe como un delta con respecto a la primera configuración de medida; y la tercera configuración de medida se recibe como un delta con respecto a la primera y a la segunda configuración de medida.

Estos métodos ejemplares también pueden incluir enviar, al UE, un mensaje relacionado con la movilidad que comprende: una primera indicación de la operación de movilidad; una segunda indicación de la condición de activación; y la segunda configuración de medida. En algunas realizaciones, el comando de movilidad condicional también puede incluir la tercera configuración de medida, y las configuraciones de medida segunda y tercera pueden incluir configuraciones de medida respectivas para cada celda objetivo que es una candidata para la operación de movilidad indicada.

En algunas realizaciones, estos métodos ejemplares también pueden incluir recibir, del nodo RAN objetivo, una tercera indicación de que la operación de movilidad se ha completado; y en respuesta a la tercera indicación, eliminar o liberar, al menos, una parte de las configuraciones de medida primera y segunda almacenadas.

Otras realizaciones ejemplares de la presente descripción incluyen métodos adicionales (p. ej., procedimientos) para la movilidad condicional de un equipo de usuario (UE) en una red de acceso por radio (RAN). Estos métodos ejemplares pueden ser realizados por un nodo RAN objetivo (p.ej., estación base, eNB, gNB, etc., o componente del mismo) que da servicio a una celda de la RAN (p. ej., E-UTRAN, NG-RAN).

Estos métodos ejemplares pueden incluir recibir, de un nodo RAN de origen, una solicitud para aceptar una operación de movilidad relacionada con el UE. La solicitud puede incluir una primera configuración de medida para el UE. Estos métodos ejemplares también pueden incluir determinar una tercera configuración de medida para el UE en relación con una o más celdas objetivo, servidas por el nodo RAN objetivo. La tercera configuración de medida puede basarse en (p. ej., un delta con respecto a) la primera configuración de medida.

Estos métodos ejemplares también pueden incluir enviar, al nodo RAN de origen, una confirmación de la operación de movilidad, incluyendo la confirmación la tercera configuración de medida. En varias realizaciones, la tercera configuración de medida puede enviarse como una configuración de medida completa, o como un delta con respecto a la primera configuración de medida y/o a la segunda configuración de medida. Estos métodos ejemplares también pueden incluir recibir, del UE, medidas realizadas en una en particular de las celdas objetivo en función de la tercera configuración de medida.

En algunas realizaciones, estos métodos ejemplares también pueden incluir recibir medidas realizadas por el UE para la celda objetivo en particular en función de la segunda configuración de medida y, posteriormente enviar, al UE, un mensaje de reconfiguración que incluye la tercera configuración de medida.

En estas realizaciones, estos métodos ejemplares también pueden incluir recibir, del nodo RAN de origen, una segunda configuración de medida para el UE. La segunda configuración de medida puede recibirse como un delta con respecto a la primera configuración de medida. En dichas realizaciones, la tercera configuración de medida, incluida en el mensaje de reconfiguración, puede ser un delta con respecto a la primera configuración de medida y a la segunda configuración de medida.

En algunas realizaciones, estos métodos ejemplares también pueden incluir enviar, al nodo RAN de origen, una indicación de que se ha completado la operación de movilidad.

Otras realizaciones ejemplares incluyen equipos de usuario (UEs, p. ej., dispositivos inalámbricos, dispositivos MTC, dispositivos NB-IoT, módems, etc. o componentes de los mismos) y nodos de red (p. ej., estaciones base, gNBs, eNBs, etc. o componentes de los mismos) configurados para realizar las operaciones correspondientes a cualquiera de los métodos ejemplares descritos en la presente memoria. Otras realizaciones ejemplares incluyen un medio legible por ordenador, no transitorio, que almacena instrucciones ejecutables por ordenador que, cuando son ejecutadas por el circuito de procesamiento de un UE o de un nodo de red, configuran dichos UEs o nodos de red para realizar las operaciones correspondientes a cualquiera de los métodos ejemplares descritos en la presente memoria.

Estos y otros objetos, características y ventajas de las realizaciones ejemplares de la presente descripción se harán evidentes al leer la siguiente Descripción Detallada en vista de los Dibujos descritos brevemente a continuación.

Breve descripción de los dibujos

La Figura 1 es un diagrama de bloques de alto nivel de una arquitectura ejemplar de la red UTRAN Evolucionada (E-UTRAN) y Central de Paquetes Evolucionada (EPC) de Evolución a Largo Plazo (LTE), según lo estandarizado por el 3GPP.

La Figura 2A es un diagrama de bloques de alto nivel de una arquitectura E-UTRAN ejemplar en términos de sus componentes constituyentes, protocolos, e interfaces.

La Figura 2B es un diagrama de bloques de capas de protocolo ejemplares de la parte del plano de control de la interfaz de radio (Uu) entre un equipo de usuario (UE) y la E-UTRAN.

La Figura 2C es un diagrama de bloques de una arquitectura del protocolo de la interfaz de radio LTE ejemplar desde la perspectiva de la capa PHY.

La Figura 3 ilustra una vista de alto nivel de la arquitectura de red 5G, incluida la arquitectura dividida de unidad central dividida (CU) y unidad distribuida (DU) de gNBs.

La Figura 4, que se divide en las Figuras 4A y 4B, ilustra un flujo de señalización ejemplar entre un UE, un nodo de origen (p. ej., gNB de origen) y un nodo objetivo (p. ej., gNB objetivo) durante un procedimiento de traspaso en una red NR.

La Figura 5, que incluye las Figuras 5A-5C, muestra tres estructuras de datos ASN.1 ejemplares utilizadas para transferir y almacenar configuraciones de medida para un UE.

La Figura 6, que incluye las Figuras 6A-6B, ilustra dos problemas de robustez ejemplares que pueden ocurrir durante las operaciones de movilidad del UE, como un traspaso.

La Figura 7 muestra un flujo de señalización de un traspaso condicional (CHO) ejemplar que implica una sola celda de servicio y una sola celda objetivo.

La Figura 8 muestra un flujo de señalización entre un UE, un nodo de origen, y un nodo objetivo para CHO, según realizaciones ejemplares de la presente descripción.

La Figura 9, que incluye las Figuras 9A-9C, muestra tres técnicas diferentes para configurar un UE con una condición de activación de movilidad condicional (p. ej., CHO).

La Figura 10 muestra un flujo de señalización de una técnica ejemplar que utiliza señalización delta para proporcionar a un UE configuraciones de medida a utilizar durante, y después, de una operación de movilidad condicional (p. ej., CHO).

La Figura 11 muestra un flujo de señalización de una técnica mejorada para proporcionar a un UE configuraciones de medida a utilizar durante las fases de monitorización y ejecución de una operación de movilidad condicional (p. ej., CHO), según varias realizaciones ejemplares de la presente descripción.

La Figura 12 muestra un flujo de señalización de otra técnica mejorada para proporcionar a un UE configuraciones de medida a utilizar durante las fases de monitorización y ejecución de una operación de movilidad condicional (p. ej., CHO), según varias realizaciones ejemplares de la presente descripción.

La Figura 13 ilustra un método y/o procedimiento ejemplar realizado por un equipo de usuario (UE) para la movilidad condicional en una red de acceso por radio (RAN), según varias realizaciones ejemplares de la presente descripción.

La Figura 14 ilustra un método y/o procedimiento ejemplar realizado por un nodo de origen, en una red de acceso por radio (RAN), para la movilidad condicional de un UE, según varias realizaciones ejemplares de la presente descripción.

La Figura 15 ilustra un método y/o procedimiento ejemplar realizado por un nodo objetivo, en una red de acceso por radio (RAN), para la movilidad condicional de un UE, según varias realizaciones ejemplares de la presente descripción.

La Figura 16 ilustra una realización ejemplar de una red inalámbrica, de acuerdo con varios aspectos descritos en la presente memoria.

La Figura 17 ilustra una realización ejemplar de un UE, de acuerdo con varios aspectos descritos en la presente memoria.

La Figura 18 es un diagrama de bloques que ilustra un entorno de virtualización ejemplar que se puede utilizar para la implementación de varias realizaciones los de nodos de red descritos en la presente memoria.

Las Figuras 19-20 son diagramas de bloques de varios sistemas y/o redes de comunicación ejemplares, de acuerdo con varios aspectos descritos en la presente memoria.

Las Figuras 21-24 son diagramas de flujo de métodos y/o procedimientos ejemplares para la transmisión y/o recepción de datos de usuario que pueden implementarse, por ejemplo, en los sistemas y/o redes de comunicación ejemplares ilustrados en las Figuras 17-18.

Descripción detallada

Algunas de las realizaciones contempladas en la presente memoria se describirán ahora con más detalle con referencia a los dibujos adjuntos. Sin embargo, otras realizaciones están contenidas dentro del alcance del tema en cuestión descrito en la presente memoria, el tema en cuestión descrito no debe interpretarse como limitado únicamente a las realizaciones establecidas en la presente memoria; más bien, estas realizaciones se proporcionan a modo de ejemplo para transmitir el alcance del tema en cuestión a los expertos en la técnica. Además, los siguientes términos se utilizan a lo largo de la descripción proporcionada a continuación:

• Nodo de Radio: Como se utiliza en la presente memoria, un "nodo de radio" puede ser un "nodo de acceso por radio" o un "dispositivo inalámbrico".

• Nodo de Acceso por Radio: Como se utiliza en la presente memoria, un "nodo de acceso por radio" (o "nodo de la red de radio") puede ser cualquier nodo en una red de acceso por radio (RAN) de una red de comunicaciones celulares que opera para transmitir y/o recibir señales de forma inalámbrica. Algunos ejemplos de un nodo de acceso por radio incluyen, pero no se limitan a, una estación base (p. ej., una estación base (gNB) de Radio Nueva (NR) en una red NR de Quinta Generación (5G) del 3GPP o un Nodo B mejorado o evolucionado (nodo de red) en una red LTE del 3GPP), una macro estación base o de alta potencia, una estación base de baja potencia (p. ej., una micro estación base, una pico estación base, un eNB doméstico, o similar), un nodo de retorno de acceso integrado (IAB), y un nodo de retransmisión.

• Nodo de Red Central: Como se utiliza en la presente memoria, un "nodo de red central" es cualquier tipo de nodo en una red central. Algunos ejemplos de un nodo de red central incluyen, p. ej., una Entidad de Gestión de la Movilidad (MME), una Puerta de Enlace de la Red de Datos por Paquetes (P-GW), una Función de Exposición de la Capacidad del Servicio (SCEF), o similares.

• Dispositivo Inalámbrico: Como se utiliza en la presente memoria, un "dispositivo inalámbrico" (o "WD" para abreviar) es cualquier tipo de dispositivo que tiene acceso a (es decir, es servido por) una red de comunicaciones celulares mediante la comunicación inalámbrica con nodos de red y/u otros dispositivos inalámbricos. A menos que se indique lo contrario, el término "dispositivo inalámbrico" se utiliza en la presente memoria de forma intercambiable con "equipo de usuario" (o "UE" para abreviar). Algunos ejemplos de un dispositivo inalámbrico incluyen, pero no se limitan a, un UE en una red del 3GPP y un dispositivo de Comunicación de Tipo Máquina (MTC). La comunicación inalámbrica puede implicar transmitir y/o recibir señales inalámbricas utilizando ondas electromagnéticas, ondas de radio, ondas infrarrojas, y/u otros tipos de señales adecuadas para trasportar información a través del aire.

• Nodo de Red: Como se utiliza en la presente memoria, un "nodo de red" es cualquier nodo que es parte de la red de acceso por radio o de la red central de una red de comunicaciones celulares. Funcionalmente, un nodo de red es un equipo capaz, configurado, dispuesto, y/u operable para comunicarse directa o indirectamente con un dispositivo inalámbrico y/o con otros nodos de red o equipos en la red de comunicaciones celulares, para permitir y/o proporcionar acceso inalámbrico a el dispositivo inalámbrico, y/o para realizar otras funciones (p.ej., administración) en la red de comunicaciones celulares.

Tenga en cuenta que la descripción proporcionada en la presente memoria se centra en un sistema de comunicaciones celulares del 3GPP y, como tal, a menudo se utiliza terminología del 3GPP o terminología similar a la terminología del 3GPP. Sin embargo, los conceptos descritos en la presente memoria no se limitan a un sistema del 3GPP. Otros sistemas inalámbricos, incluidos sin limitación, Acceso Múltiple por División de Código de Banda Ancha (WCDMA), Interoperabilidad Mundial para Acceso por Microondas (WiMax), Banda Ancha Ultra Móvil (UMB) y el Sistema Global para Comunicaciones Móviles (GSM), pueden también beneficiarse de los conceptos, principios, y/o realizaciones descritas en la presente memoria.

Además, las funciones y/u operaciones descritas en la presente memoria como que son realizadas por un dispositivo inalámbrico o un nodo de red pueden distribuirse sobre una pluralidad de dispositivos inalámbricos y/o nodos de red. Además, aunque el término "celda" se utiliza en la presente memoria, debe entenderse que (particularmente con respecto a NR 5G) pueden utilizarse haces en lugar de celdas y, como tal, los conceptos descritos en la presente memoria aplican por igual tanto a celdas como a haces.

Como se discutió anteriormente, el proceso de traspaso (HO) actual en las redes del 3GPP tiene varios problemas relacionados con la robustez. Por ejemplo, el comando HO (p.ej., RRCConnectionReconfiguration con mobilityControlInfo o RRCReconfiguration con una reconfigurationWithSync) normalmente se envía cuando las condiciones de radio para el UE ya son bastante malas. Como tal, el comando HO puede necesitar segmentarse (p. ej., para permitir la redundancia para proteger contra errores) y/o retransmitir (p. ej., utilizando HARQ) una o más veces antes de que llegue al UE. En dicho caso, el comando HO puede no llegar al UE a tiempo (o en absoluto) antes de que se interrumpa la conexión degradada con el nodo objetivo.

Una solución para mejorar la robustez de la movilidad se llama "traspaso condicional" ("CHO" para abreviar) o "comando precoz de traspaso". Para evitar la dependencia de las condiciones del enlace de radio de servicio en el momento en que el UE debe ejecutar el traspaso, la señalización RRC para el traspaso puede proporcionarse al UE antes, mientras que las condiciones en el enlace de radio son mejores. Dicha señalización RRC CHO puede basarse en la señalización delta, discutida anteriormente, que proporciona ventajas similares a las del traspaso convencional (es decir, no condicional). Aun así, el uso de señalización delta puede crear varios problemas, inconsistencias, y/o problemas durante la operación de CHO, particularmente cuando se utiliza para configurar medidas del UE. Estos problemas y mejoras específicas proporcionadas por las realizaciones ejemplares de la presente descripción se discuten a continuación con más detalle.

Antes de la Rel-13, había dos estados RRC definidos para un UE. Más específicamente, después de encender un UE, estará en el estado RRC_IDLE hasta que se establezca una conexión RRC, en cuyo momento pasará al estado RRC_CONNECTED (p. ej., donde puede ocurrir la transferencia de datos). Después de que se libera una conexión, el UE vuelve a RRC_IDL^e . En el estado RRC_IDLE, la radio del UE está activa en un programa de recepción discontinua (DRX) configurado por las capas superiores. Durante los períodos activos de DRX, un UE RRC_IDLE recibe información del sistema (SI) emitida por una celda de servicio, realiza medidas de celdas vecinas para admitir la re-selección de celda, y monitoriza un canal de paginación en el PDCCH para buscar páginas de la EPC a través del eNB. Un UE RRC_IDLE es conocido en la EPC y tiene una dirección IP asignada, pero el eNB de servicio no lo conoce (p. ej., no hay un contexto almacenado).

En la Rel-13 de LTE, se introdujo un mecanismo para que el UE sea suspendido por la red en un estado suspendido similar a RRC_IDLE pero con algunas diferencias importantes. Primero, el estado suspendido no es un tercer "estado" RRC junto con RRC_IDLE y RRC_CONNECTED; más bien puede verse como un "sub-estado" de RRC_IDLE. Segundo, tanto el UE como el eNB de servicio almacenan el contexto AS (p. ej., S1-AP) y el contexto RRC del UE después de la suspensión. Cuando el UE suspendido necesita reanudar una conexión (p. ej., para enviar datos del UL), en lugar de pasar a través del procedimiento de solicitud de servicio convencional, el UE suspendido simplemente envía un mensaje RRCConnectionResumeRequest al eNB. El eNB reanuda el contexto S1AP y responde con un mensaje RRCConnectionResume. No hay un intercambio elaborado de contexto de seguridad entre la MME y el eNB y no hay configuración del contexto de seguridad AS. Los contextos AS y RRC conservados simplemente se reanudan desde donde se suspendieron anteriormente. La reducción de la señalización puede proporcionar una latencia del UE reducida (p.ej. para teléfonos inteligentes que acceden a Internet) y una señalización de UE reducida, lo que puede conducir a un consumo de energía del UE reducido, particularmente para dispositivos de comunicación de tipo máquina (MTC) que envían muy pocos datos (es decir, la señalización siendo un consumidor primario de energía).

Para admitir la movilidad (p.ej., traspaso o re-selección) entre celdas y/o haces, un UE puede realizar búsquedas periódicas de celdas y medidas de potencia y calidad de la señal (p.ej., potencia recibida de la señal de referencia, RSRP, y calidad recibida de la señal de referencia, RSRQ) en los modos tanto RRC_CONNECTED como RRC_IDLE. El UE es responsable de detectar nuevas celdas vecinas, y de rastrear y monitorizar celdas ya detectadas. Las celdas detectadas y los valores de medida asociados se reportan a la red. Un UE de LTE puede realizar dichas medidas en varias señales de referencia (RS) del enlace descendente que incluyen, p.ej., Señal de Referencia específica de celda (CRS), RS MBSFN, demodulación RS específica del UE (DM-RS) asociada con el PDSCH, DM-RS asociada con el EPDCCH o M/NPDCCH, posicionamiento RS (PRS), y RS de información de estado del canal (CSI-RS).

Los reportes de medida del UE a la red pueden configurarse para que sean periódicos o no periódicos en función de un evento en particular. Por ejemplo, la red puede configurar un UE para realizar medidas en varias frecuencias de portadora y varias tecnologías de acceso por radio (RATs) correspondientes a celdas vecinas, así como para diversos fines, incluidos, p.ej., la movilidad y/o el posicionamiento. La configuración de cada una de estas medidas se denomina "objeto de medida". Además, el UE puede configurarse para realizar las medidas según un "patrón de espacio de medida" (o "patrón de espacio" para abreviar), que puede incluir un período de repetición de espacio de medida (MGRP, es decir, con qué frecuencia está disponible un espacio recurrente para medidas) y una longitud del espacio de medida (MGL, es decir, la longitud de cada espacio recurrente).

En LTE, el concepto de Tiempo de Activación (TTT) se utiliza para garantizar que el criterio de activación del evento se cumpla durante un tiempo suficiente antes de que el UE envíe un reporte de medida. El criterio de activación y el TTT se configuran en un mensaje reportConfig (o en un elemento de información, IE, de un mensaje) enviado por la red al UE. El valor de TTT proporcionado en reportConfig es aplicable a todas las celdas vecinas del UE que podrían activar un reporte de medida en función del criterio de activación especificado.

Mientras que LTE se diseñó principalmente para comunicaciones de usuario a usuario, las redes celulares 5G (también denominadas "NR") están previstas para admitir tanto altas tasas de datos de un solo usuario (p.ej., 1 Gbis) como a gran escala, y comunicaciones de máquina a máquina que involucran transmisiones cortas, y en ráfagas, desde muchos dispositivos diferentes que comparten el ancho de banda de frecuencia. Los estándares de radio 5G (también denominados "Radio Nueva" o "NR") se dirigen actualmente a una amplia gama de servicios de datos, incluidos eMBB (Banda Ancha Móvil mejorada) y URLLC (Comunicación Ultra-Confiable de Baja Latencia). Estos servicios pueden tener diferentes requisitos y objetivos. Por ejemplo, URLLC está destinada a proporcionar un servicio de datos con requisitos de error y latencia extremadamente estrictos, p. ej., probabilidades de error tan bajas como 10^-5 o inferiores y latencia de extremo a extremo de 1 ms o inferior. Para eMBB, los requisitos en latencia y probabilidad de error pueden ser menos estrictos, mientras que la tasa de pico admitida y/o la eficiencia espectral requeridas pueden ser mayores.

Similar a LTE, la PHY NR utiliza CP-OFDM (Multiplexación por División de Frecuencia Ortogonal de Prefijo Cíclico) en el DL y tanto CP-OFDM como OFDM de expansión de la DFT (DFT-S-OFDM) en el UL. En el dominio del tiempo, los recursos físicos del DL y del UL de NR se organizan en subtramas de igual tamaño, de 1 ms. Cada subtrama incluye uno o más intervalos, y cada intervalo incluye 14 (para el prefijo cíclico normal) o 12 (para el prefijo cíclico extendido) símbolos en el dominio del tiempo.

La Figura 3 ilustra una vista de alto nivel de la arquitectura de red 5G, que incluye una RAN de próxima generación (NG-RAN) 399 y una red central 5G (5GC) 398. La NG-RAN 399 puede incluir uno o más gNodos B (gNBs) conectados a la 5GC a través de una o más interfaces NG, como los gNBs 300, 350 conectados a través de las interfaces 302, 352, respectivamente. Más específicamente, los gNBs 300, 350 pueden conectarse a una o más Funciones de Gestión del Acceso y la Movilidad (AMF) en la 5GC 398 a través de las respectivas interfaces NG-C. De manera similar, los gNBs 300, 350 pueden conectarse a una o más Funciones del Plano de Usuario (UPFs) en 5GC 398 a través de las respectivas interfaces NG-U. NG-C y NG-U son partes del plano de control y del plano de usuario, respectivamente, de las interfaces NG 302 y 352 mostradas en la Figura 3.

Aunque no se muestra, en algunos despliegues la 5GC 398 puede ser reemplazada por un Núcleo de Paquetes Evolucionado (EPC), que convencionalmente se ha utilizado junto con E-UTRAN LTE. En dichas implementaciones, los gNBs 300, 350 pueden conectarse a una o más Entidades de Gestión de la Movilidad (MMEs) en EPC a través de las respectivas interfaces S1-C. De manera similar, los gNBs 300, 350 pueden conectarse a una o más Puertas de Enlace de Servicio (SGW) en EPC a través de las respectivas interfaces NG-U.

Además, los gNBs pueden conectarse entre sí a través de una o más interfaces Xn, como la interfaz Xn 340 entre los gNBs 300 y 350. La tecnología de radio para NG-RAN a menudo se denomina "Radio Nueva" (NR). Para la interfaz de NR a los UEs, cada uno de los gNBs puede admitir la duplexación por división de frecuencia (FDD), la duplexación por división de tiempo (TDD), o una combinación de las mismas.

La NG-RAN 399 puede dividirse en una Capa de la Red de Radio (RNL) y una Capa de la Red de Transporte (TNL). La arquitectura NG-RAN, es decir, los nodos lógicos NG-RAN y las interfaces entre ellos, se define como parte de la RNL. Para cada interfaz NG-RAN (NG, Xn, F1) se especifica el protocolo TNL relacionado y la funcionalidad. La TNL proporciona servicios para transporte del plano de usuario y transporte de la señalización. En algunas configuraciones ejemplares, cada gNB está conectado a todos los nodos 5GC dentro de una "Región AMF" que se define en la TS 23.501 (v15.4.0) del 3GPP. Si se admite la protección de seguridad para los datos CP y UP en la TNL de las interfaces NG-Ra N, se aplicará NDS/IP (definido en la TS 33.401 v15.6.0 del 3GPP).

Los nodos lógicos NG-RAN mostrados en la Figura 3 (y descritos en la TS 38.401 v15.4.0 del 3GPP y el TR 38.801 v14.0.0 del 3GPP) incluyen una Unidad central (CU o gNB-CU) y una o más Unidades Distribuidas (DU o gNB- DU).

Por ejemplo, el gNB 300 incluye la gNB-CU 310 y los gNB-DUs 320 y 330. Las CUs (p. ej., gNB-CU 310) son nodos lógicos que alojan protocolos de capa superior y realizan diversas funciones del gNB, como controlar el funcionamiento de las DUs. Una DU (p. ej., gNB-DUs 320, 330) es un nodo lógico descentralizado que alberga protocolos de capa inferior y puede incluir, dependiendo de la opción de división funcional, varios subconjuntos de las funciones del gNB. Como tal, cada una de las CUs y DUs puede incluir varios circuitos necesarios para realizar sus respectivas funciones, incluidos circuitos de procesamiento, circuitos transceptores (p. ej., para comunicación), y circuitos de suministro de potencia. Además, los términos "unidad central" y "unidad centralizada" se utilizan indistintamente en la presente memoria, al igual que los términos "unidad distribuida" y "unidad descentralizada".

Una gNB-CU se conecta a una o más gNB-DUs a través de las respectivas interfaces lógicas F1, como las interfaces 322 y 332 mostradas en la Figura 3. Sin embargo, una gNB-DU puede conectarse solamente a una única gNB-CU. La gNB-CU y la(s) gNB-DU(s) conectadas solo son visibles para otros gNBs y el 5GC como un gNB. En otras palabras, la interfaz F1 no es visible más allá de la gNB-CU. Además, la interfaz F1 entre la gNB-CU y la gNB-DU se especifica y/o se basa en los siguientes principios generales:

F1 es una interfaz abierta;

F1 admite el intercambio de información de señalización entre puntos finales respectivos, así como la transmisión de datos a los puntos finales respectivos;

desde un punto de vista lógico, F1 es una interfaz punto a punto entre los puntos finales (incluso en ausencia de una conexión física directa entre los puntos finales);

F1 admite la separación del plano de control (CP) y del plano de usuario (UP), de modo que una gNB-CU puede separarse en CP y UP;

F1 separa la Capa de la Red de Radio (RNL) y la Capa de la Red de Transporte (TNL);

F1 permite el intercambio de información asociada al equipo de usuario (UE) y de información no asociada al UE;

F1 se define como una prueba de futuro con respecto a nuevos requisitos, servicios, y funciones;

Un gNB termina las interfaces X2, Xn, NG y S1 -U y, para la interfaz F1 entre la DU y la CU, utiliza el protocolo de parte de aplicación F1 (F1 -AP) que se define en la TS 38.473 del 3GPP.

Además, una CU puede alojar protocolos como RRC y PDCP, mientras que una DU puede alojar protocolos como RLC, MAC y PHY. Sin embargo, pueden existir otras variantes de distribuciones de protocolos entre CU y DU, como alojar el r Rc , PDCP y parte del protocolo RLC en la CU (p.ej., función de Solicitud de Retransmisión Automática (ARQ)), mientras aloja las partes restantes del protocolo ^r L^c en la DU, junto con MAC y PHY. En algunas realizaciones ejemplares, la CU puede albergar RRC y PDCP, donde se supone que PDCP maneja tanto el tráfico UP como el tráfico CP. Sin embargo, otras realizaciones ejemplares pueden utilizar otras divisiones de protocolos alojando ciertos protocolos en la CU y otros ciertos en la DU. Las realizaciones ejemplares también pueden ubicar protocolos centralizados del plano de control (p.ej., PDCP-C y RRC) en una CU diferente con respecto a los protocolos UP centralizados (p.ej., PDCP-U).

Además de los estados RRC_IDLE y RRC_CONNECTED discutidos anteriormente, los UEs de NR también admiten un estado RRC_INACTIVE con propiedades similares a las de la condición suspendida en la Rel-13 de LTE. Aun así, el estado RRC_INACTIVE tiene propiedades ligeramente diferentes en el sentido de que es un estado RRC separado y no parte de RRC_IDLE como en LTE. Además, la conexión CN/RAN (interfaz NG o N₂) se mantiene viva durante RRC_INACTIVE mientras estaba suspendida en LTE.

La Figura 4 muestra los estados y procedimientos de RRC NR mediante los cuales un UE hace transiciones entre los estados de RRC NR. Las propiedades de los estados mostrados en la Figura 4 se resumen de la siguiente manera:

• RRC_IDLE:

- Una operación de recepción discontinua (DRX) específica del UE puede ser configurada por las capas superiores;

- Movilidad controlada del UE en función de la configuración de red (p. ej., re-selección de celda);

- El UE:

° Monitoriza un canal de Paginación para paginación CN utilizando 5G-S-TMSI;

° Realiza medidas de celdas vecinas y (re-)selección de celda; y

° Adquiere información del sistema.

• RRC_INACTIVE:

- Una operación DRX específica del UE puede ser configurada por las capas superiores o por RRC;

- Movilidad controlada del UE en función de la configuración de red;

- El UE almacena el contexto AS;

- El UE:

° Monitoriza un canal de Paginación para paginación CN utilizando 5G-S-TMSI, y para paginación RAN utilizando I-RNTI;

° Realiza medidas de celdas vecinas y (re-)selección de celda;

° Realiza actualizaciones del área de notificación basadas en la RAN periódicamente y cuando se mueve fuera del área de notificación basada en la RAN; y

° Adquiere información del sistema.

• RRC_CONNECTED:

- El UE almacena el contexto AS.

- Transferencia de datos de unidifusión hacia/desde el UE a través de canales de datos compartidos (p. ej., PDSCH y/o PUSCH).

- En las capas inferiores, el UE puede configurarse con una DRX específica del UE;

- Para los UEs que admiten CA, el uso de una o más SCells, agregadas con la SpCell, para un ancho de banda aumentado;

- Para los UEs que admiten DC, el uso de un SCG, agregado con el MCG, para un ancho de banda aumentado; - Movilidad controlada por red, es decir, traspaso dentro de NR y hacia/desde la E-UTRAN.

- El UE:

° Monitoriza un canal de Paginación;

° Monitoriza los canales de control asociados con el canal de datos compartido para determinar si los datos están programados para él;

° Proporciona información de calidad del canal y de retroalimentación;

° Realiza medidas de celdas vecinas y reportes de medida; y

° Adquiere información del sistema.

Como se muestra en la Figura 4, las transiciones entre los estados RRC_INACTIVE y RRC_CONNECTED se realizan mediante dos nuevos procedimientos: "Suspender" (también llamado liberación de la conexión RRC con SuspendConfig) y "Reanudar". Un gNB puede suspender una conexión y mover un UE de RRC_CONECTADO a RRC_INACTIVO enviando al UE un mensaje RRCRelese con indicación (o configuración) de suspensión. Esto puede suceder, por ejemplo, después de que el UE haya estado inactivo durante un período determinado, lo que hace que expire un temporizador de inactividad interno del gNB. Al moverse a RRC_INACTIVE, tanto el UE como el gNB almacenan el contexto del estrato de acceso (AS) del UE y el identificador asociado (denominado I-RNTI).

Del mismo modo, un UE puede intentar reanudar una conexión hacia un gNB en particular (p. ej., la misma o diferente celda desde la que se suspendió la conexión) enviando al gNB un mensaje RRCResuemeRequest que incluye el I-RNTI, un token de seguridad (llamado resumeMAC-I) utilizado para identificar y verificar el UE en la reanudación de la conexión RRC, y una indicación de la causa de la reanudación (p. ej., datos originados en el móvil). El gNB que da servicio a la celda en la que el UE intenta reanudar se suele denominar "gNB objetivo ", mientras que el gNB que da servicio a la celda en la que el UE se suspendió se suele denominar "gNB de origen". Para reanudar la conexión, el gNB objetivo identifica el gNB de origen (p. ej., de una parte del I-RNTI) y solicita que el gNB envíe el contexto del UE. En esta solicitud, el gNB objetivo proporciona, entre otras cosas, un ID de la celda objetivo, un ID del UE, y un token de seguridad recibido del UE. El procedimiento de reanudación de NR es similar en algunos aspectos al procedimiento de reanudación correspondiente en LTE (p. ej., E-UTRAN y EPC) y eLTE (p. ej., E-UTRAN y 5g C).

Como se mencionó anteriormente, un UE RRC_CONNECTED puede ser configurado por la red para realizar medidas y, tras activar los reportes de medida, la red puede enviar un comando de traspaso al UE. En LTE, este comando es un mensaje RRConnection-Reconfiguration con un campo mobilityControlInfo. En NR, este comando es un mensaje RRCReconfiguration con un campo de reconfigurationWithSync.

Estas reconfiguraciones se preparan mediante el modo objetivo del traspaso tras una solicitud del nodo de origen, intercambiado a través de la interfaz X2 o S1 en LTE (ver, p. ej., la Figura 1) o la interfaz NG en caso de NR (ver, p. ej., la Figura 3). Estas reconfiguraciones normalmente tienen en cuenta la configuración RRC existente entre el UE y la celda de origen, que se proporciona en la solicitud entre nodos. En LTE, por ejemplo, esta configuración existente del UE se proporciona en el HandoverPreparationInformation de la solicitud del nodo de origen al nodo objetivo. En respuesta, el nodo objetivo proporciona parámetros de reconfiguración que contienen toda la información que el UE necesita para acceder a la celda objetivo, p. ej., configuración de acceso aleatorio, un nuevo C-RNTI asignado por la celda objetivo, parámetros de seguridad que permiten al UE calcular nuevas claves de seguridad asociadas con la celda objetivo, etc. Las nuevas claves de seguridad permiten que el UE envíe un mensaje completo de traspaso en SRB1, que está encriptado y con protección de integridad, tras acceder a la celda objetivo.

La Figura 5, que se divide en las Figuras 5A y 5B, ilustra el flujo de señalización entre un UE, un nodo de origen (p. ej., gNB de origen), y un nodo objetivo (p. ej., gNB objetivo) durante un procedimiento de traspaso en una red NR. La Figura 5 también ilustra los roles de las funciones 5GC, incluidas la función de gestión del acceso (AMF) y la función del plano de usuario (UPF). Aun así, la siguiente discusión aborda varios principios relacionados con HO (o, de manera más general, la movilidad del UE mientras está en modo RRC_CONNECTED) tanto en redes NR como LTE.

Primero, la movilidad del UE en RRC_CONNECTED se basa en la red, ya que la red tiene la información más reciente y/o más precisa sobre la situación actual, como condiciones de carga, recursos en diferentes nodos, frecuencias disponibles, etc. La red también puede tener en cuenta la situación de muchos UEs en la red, desde una perspectiva de asignación de recursos.

Como se ilustra en la Figura 5, hay tres fases en el procedimiento de traspaso: preparación del traspaso, ejecución del traspaso, y finalización del traspaso. Antes de la preparación del traspaso, el UE puede haber estado enviando, y/o recibiendo, datos de usuario a una UPF en la 5GC a través del gNB de origen. Durante la fase de preparación del traspaso, la red prepara una celda objetivo antes de que el UE acceda a esa celda. La AMF proporciona información de control de la movilidad al gNB de origen (operación 0). Además, el nodo de origen recibe reportes de medida del UE (operación 1), toma una decisión de traspaso en función de estos reportes (p. ej., operación 2) y negocia un traspaso del UE con el nodo objetivo (p. ej., operaciones 3-5).

Durante la ejecución del traspaso, el nodo de origen proporciona al UE diversa información para activar el traspaso a una celda objetivo servida por el nodo objetivo (operación 6), y también proporciona al nodo objetivo el estado actual del UE en el nodo de origen (operación 7). Por ejemplo, el nodo de origen (p. ej., en la operación 6) proporciona al UE la configuración RRC a utilizar en la celda objetivo, incluida la configuración SRB1 (p. ej., parámetros a partir de los cuales derivar claves para el cifrado/protección de la integridad) para enviar el mensaje completo HO (p. ej., RRCConnectionReconfigurationComplete). El nodo de origen proporciona al UE un C-RNTI objetivo, de modo que el nodo objetivo pueda identificar el UE a partir del msg3 de acceso aleatorio en el nivel MAC para el mensaje completo HO. Esta información se recibe del nodo objetivo durante la fase de preparación del traspaso. En consecuencia, a menos que ocurra un fallo, no hay necesidad de que el nodo objetivo obtenga el contexto del UE.

Además, para acelerar el HO, el nodo de origen proporciona al UE la información necesaria sobre cómo acceder al objetivo (p. ej., configuración RACH), de modo que el UE no tiene que adquirir información del sistema del nodo objetivo (SI, p. ej., de la emisión) antes del traspaso. Tanto la reconfiguración completa como la delta son compatibles para que el comando HO pueda minimizarse. El UE puede estar provisto de recursos de acceso aleatorio sin contención (CFRA); en ese caso, el nodo objetivo puede identificar el UE a partir del preámbulo RACH (también denominado msg1). De manera más general, el procedimiento HO normal siempre puede optimizarse con recursos dedicados, como los recursos CFRA.

También durante la fase de ejecución del traspaso, el UE se separa de la celda antigua (p. ej., servida por el nodo de origen) y se sincroniza con la nueva celda servida por el nodo objetivo (p. ej., operación 8). Simultáneamente con estas operaciones, el nodo de origen entrega datos de usuario almacenados temporalmente para el UE al nodo objetivo, que posteriormente puede comunicar estos datos de usuario al UE después de que el UE complete el traspaso.

Durante la fase de finalización del traspaso, el nodo objetivo y el nodo de origen en la NG-RAN se comunican con la 5GC (p. ej., la AMF) para actualizar la información de la ruta asociada con el UE (p. ej., operaciones 9 y 11). Además, los nodos o funciones dentro de la 5GC (p. ej., AMF y UPF) pueden comunicarse para actualizar la ruta del UE en función del traspaso (p. ej., la operación 10). Finalmente, el nodo objetivo puede informar al nodo de origen que puede liberar el contexto del UE (p. ej., la operación 12).

Como se mencionó anteriormente, la "señalización delta" se utiliza para reducir la cantidad de señalización RRC entre la red y el UE. Como también se mencionó anteriormente, la señalización delta normalmente se implementa con características de protocolo, como "códigos de necesidad", listas AddMod, y variables del UE donde se almacenan las configuraciones recibidas.

En NR, puede proporcionarse una configuración de medida al UE en un mensaje RRCResumeo RRCReconfiguration. Por ejemplo, dicha configuración de medida puede proporcionarse como un delta con respecto a una o más configuraciones de medida (p. ej., una configuración de medida completa) proporcionada anteriormente al UE. Por ejemplo, la Figura 6A muestra una estructura de datos ASN.1 que define un mensaje RRCResume ejemplar que incluye un elemento de información de configuración de medida completa (IE measConfig) para un UE.

El IE measConfig en la Figura 6A está etiquetado como "Necesita M" y especifica medidas a realizar por el UE, y cubre la movilidad intra-frecuencia, inter-frecuencia e inter-RAT, así como la configuración de espacios de medida. El código " Necesita M" significa que el UE debe almacenar este campo. Además, el IE measConfig en la Figura 6A referencia a una estructura de datos MeasConfig, que puede definirse mediante la estructura de datos ASN.1 ejemplar mostrada en la Figura 6B. Tenga en cuenta que algunos de los campos en la Figura 6B también están etiquetados como "Necesita M". La Tabla 1 a continuación proporciona una definición adicional de ciertos campos mostrados en la Figura 6B.

Tabla 1.

Una vez el IE measConfig se proporciona al UE en el mensaje RRCResume, el UE almacena lo descrito anteriormente en función de sus códigos "Necesita M" asociados. En particular, el UE almacena la información recibida en measConfig en la variable del UE VarMeasConfig que incluye la configuración acumulada de medidas a realizar por el UE, incluyendo medidas relacionadas con la movilidad intra-frecuencia, inter-frecuencia, e inter-RAT. La Figura 6C muestra una estructura de datos ASN.1 que define un VarMeasConfig ejemplar utilizado por un UE de esta manera.

Suponga que el UE recibe un RRCReconfiguration con una reconfigurationWithSync indicando que el UE realizará un traspaso a una celda objetivo. Tras recibir ese mensaje, el UE aplica el contenido de ese mensaje a su configuración. Si el IE measConfig está presente, el UE actualiza su configuración almacenada con cualquier nuevo valor o sub­ campo incluido en ese IE. Debido a la señalización delta, la red solo incluye los valores o sub-campos que son nuevos o han cambiado. Si no se necesitan cambios de configuración, la red no incluye el IE measConfig, y el UE continúa utilizando su measConfig almacenado actualmente. Para el caso específico de traspaso, si el nodo objetivo se da cuenta de que la configuración de medida almacenada del UE es la configuración deseada para que el UE la utilice en la celda objetivo, el nodo objetivo simplemente no señala nada. O, si se deben cambiar ciertos campos, el nodo objetivo solo incluye aquellos en el IE measConfig enviado al UE.

Por ejemplo, suponga que el UE tiene un measConfig almacenado recibido en RRCResume, y ahora el UE recibe una RRCReconfiguration con un IE measConfig que contiene un measConfig'. Como se muestra en la Figura 6B, los campos s-MeasureConfig, quantityConfig, measGapConfig, y measGapSharíngConfig en este IE están etiquetados como "Necesita M". Esto significa que si alguno de estos campos falta en el IE recibido, el UE deberá continuar utilizando el parámetro almacenado correspondiente de measConfig.

Por ejemplo, si en RRCResume el UE recibió quantityConfig, measGapConfig, s-MeasureConfig, y measGapSharíngConfig, y en RRCReconfiguration el UE recibe un measConfig'con un quantityConfig’ solamente, el UE reemplaza quantityConfig por quantityConfig’y continúa utilizando los otros valores almacenados recibidos en measConfig. Como tal, después de esta señalización delta, la configuración almacenada del UE será quantityConfig’, measGapConfig, s-MeasureConfig, y measGapSharíngConfig.

Para los campos de MeasConfig con código "Necesita N", se utiliza la estructura de lista, pero el principio es similar.

"Necesita N" significa "Sin acción", indicando campos que no están almacenados y cuya presencia provoca una única acción por parte del UE. Ante la ausencia de un campo "Necesita N", el UE no realiza ninguna acción. Dicha estructura de lista es importante para configurar el UE con objetos de medida a medir (p. ej., frecuencia de portadora, celdas, parámetros de derivación de la calidad de la celda en NR, umbrales específicos de frecuencia, etc.), configuraciones de reporte (p. ej., configuración de reporte de medida activado por evento), identificadores de medida, etc. También se utiliza para eliminarlos.

A pesar del hecho de que dichos campos están etiquetados como "Necesita N", su recepción activa al UE para almacenar la información incluida. Por ejemplo, si la red quiere agregar un objeto de medida al UE cuando envía el measConfig inicial del ejemplo anterior, esto activa al UE para realizar el siguiente procedimiento de una sola vez (suponiendo que el objeto no existe):

Dado que el UE almacena esta información de lista, la señalización delta se realiza enviando un puntero o identificador a una configuración específica que se sabe que está almacenada en el UE. Si alguna de estas listas se proporciona en un mensaje posterior con measConfig, el UE conserva lo que tiene almacenado en la VarMeasConfigy continúa realizando medidas en consecuencia. Si la red quiere agregar, explícitamente, un objeto de medida, configuración de reporte, y/o identificador de medida, simplemente incluye el campo y agrega uno nuevo. Eso se agregará en la lista almacenada por el UE en VarMeasConfig. Similar si la red quiere eliminar o modificar un objeto de medida existente o una configuración de reporte, el cual es referido por un identificador proporcionado en las listas AddMod.

Uno de los principales objetivos de NR es proporcionar más capacidad a los operadores para atender demandas de tráfico cada vez mayores y variedad de aplicaciones. Debido a esto, NR debería poder operar en altas frecuencias (por encima de 6 GHz y hasta 100 GHz), donde habrá más espectro disponible. En comparación con las bandas de frecuencia actuales asignadas a LTE, algunas de las nuevas bandas tendrán propiedades de propagación mucho más desafiantes, como una menor difracción y mayores pérdidas de penetración en exterior/interior. Como consecuencia, las señales tienen menos capacidad para propagarse por las esquinas y penetrar paredes. Además, la atenuación atmosférica/de la lluvia y mayores pérdidas corporales hacen aún más irregular la cobertura de las señales NR en las bandas de alta frecuencia. Afortunadamente, el funcionamiento en las frecuencias más altas hace posible el uso de elementos de antena más pequeños, lo que permite conjuntos de antenas con muchos elementos de antena. Dichos conjuntos de antenas facilitan la formación de haces, donde se utilizan múltiples elementos de antena para formar haces estrechos y, de ese modo, compensar las desafiantes propiedades de la propagación.

A pesar de las ganancias en el presupuesto del enlace proporcionadas por las soluciones de formación de haces, la fiabilidad de un sistema que se basa, puramente, en la formación de haces y que opera en frecuencias más altas podría ser un desafío, ya que la cobertura podría ser más sensible a variaciones tanto de tiempo/frecuencia como de espacio. En consecuencia, la SINR de dichos enlaces estrechos puede caer mucho más rápido que en el caso de LTE. Incluso para LTE, se ha observado que la celda de servicio puede no ser capaz de transmitir el comando HO a tiempo. Reducir el Tiempo de Activación (TTT) y la histéresis de medida permitida puede reducir la tasa de fallo de traspasos, pero también puede aumentar la probabilidad de ping-pong (p. ej., de rebote entre celdas). Estos efectos pueden ser aún más pronunciados cuando se opera en las bandas de frecuencia más altas de NR.

La Figura 7, que incluye las Figuras 7A y 7B, ilustra varios problemas de robustez ejemplares que pueden ocurrir durante las operaciones de movilidad del UE, como durante un traspaso. En el escenario mostrado en la Figura 7A, en función de medidas de celdas vecinas, el UE activa un "evento A3" donde la celda vecina es mejor que la celda primaria del UE (PCell). En respuesta, el UE intenta enviar un reporte de medida sobre esta condición al nodo de origen (p. ej., de servicio). Sin embargo, debido a que las condiciones de radio del enlace ascendente se degradan rápidamente, el nodo de origen no recibe el reporte de medida del UE. Las condiciones continúan degradándose en la celda de origen del UE, lo que finalmente lleva al UE a declarar fallo del enlace de radio (RLF) e intentar restablecer una conexión con el nodo de origen (que puede o no tener éxito). En la Figura 7B, el nodo de origen recibe correctamente el reporte de medida del UE, pero debido a la degradación de las condiciones de radio del enlace descendente, el UE no recibe el comando HO del nodo de origen. En última instancia, se produce el mismo resultado en ambos casos mostrados en la Figura 7.

Como tal, existe la necesidad de mejorar la robustez de la movilidad en los sistemas NR, y los elementos de trabajo para mejoras de la movilidad en LTE y NR han comenzado en la Rel-16 del 3GPP. Los principales objetivos de los elementos de trabajo son mejorar la robustez en el traspaso y disminuir el tiempo de interrupción en el traspaso. En LTE y NR, se han discutido en el pasado diferentes soluciones para aumentar la robustez de la movilidad. Una solución se basa en la Conectividad Dual (DC) introducida en la Rel-12 de LTE. En DC, el UE está conectado a dos nodos de red simultáneamente. Esto mejora la robustez de la movilidad al servir el tráfico del plano de control (p. ej., utilizado para reportes de medida y comandos de traspaso) mediante una macro capa robusta a una frecuencia más baja y proporcionar un aumento de la capacidad con frecuencias más altas. Esta característica a menudo se denomina "división UP/CP". Alternativamente, DC puede configurarse de modo que la señalización del plano de control se intercambie a través de ambos nodos conectados. Esto se denomina "diversidad RRC" y puede aumentar la robustez debido a la diversidad en los dominios temporal y espacial.

Como se mencionó brevemente anteriormente, otra solución se llama " traspaso condicional" (o "CHO" para abreviar) o "comando precoz de traspaso". Para evitar la dependencia de las condiciones del enlace de radio de servicio en el momento en que el UE debe ejecutar el traspaso, la señalización RRC para el traspaso puede proporcionarse al UE antes, mientras que las condiciones en el enlace de radio son mejores. Para lograr esto, el comando HO puede asociarse con una condición (p. ej., condiciones de radio similares a las asociadas a un evento A3).

Por ejemplo, una condición de ejecución ejemplar podría ser que la calidad de la celda o haz objetivo llegue a ser X dB más fuerte que la celda de servicio. Un evento de reporte de medida anterior podría utilizar un umbral Y que se selecciona para que sea más bajo que el de la condición de ejecución del traspaso. Esto permite que la celda de servicio prepare el traspaso tras la recepción de un reporte precoz de medida y proporcione la RRCConnectionReconfiguration con mobilityControlInfo (para LTE), o una RRCReconfiguration con una reconfigurationWithSync o una CellGroupConfig (para NR) en un momento en que el enlace de radio entre la celda de origen y el UE todavía es relativamente estable. La ejecución del traspaso se realiza en un momento (y umbral) posterior que es óptimo y/o preferido para la ejecución del traspaso.

La Figura 8 ilustra un flujo de señal ejemplar entre un equipo 810 de usuario (UE), un nodo 820 de origen, y un nodo objetivo 830 para un traspaso condicional (HO), según las realizaciones ejemplares de la presente descripción. Por ejemplo, los nodos de origen y objetivo pueden ser gNBs y/o componentes de gNBs, como CUs y/o DUs.

Este procedimiento involucra dos umbrales de medida diferentes: un umbral bajo y un umbral alto. Los dos umbrales pueden expresarse como diferentes niveles de una métrica en particular, p. ej., intensidad de la señal, calidad de la señal, etc. Por ejemplo, el umbral alto podría ser que la calidad de la movilidad RS (MRS) de la celda o el haz objetivo llegue a ser X dB más fuerte que la MRS de la celda de servicio del UE (p. ej., proporcionada por el nodo de origen), con el umbral bajo siendo menor que el umbral alto (es decir, el objetivo supera a la fuente por una cantidad menor). Como se usa en este contexto, MRS denota una señal de referencia utilizada para cualquier propósito relacionado con la movilidad. Por ejemplo, en NR, MRS puede ser SSB (bloque SS/PBCH) o CSI-RS. Como otro ejemplo, para NR que opera en un espectro sin licencia (denominado NR-U), MRS puede ser una señal de referencia de descubrimiento (DRS) además de cualquiera de las señales mencionadas anteriormente.

El UE puede estar provisto de una configuración de medida que incluye el umbral bajo (no mostrado en la figura). Al realizar medidas que alcanzan el umbral bajo, el UE puede enviar un reporte de medida al nodo de servicio (operación 1). Mientras que realiza las medidas y evalúa el umbral bajo, el UE continúa operando en su configuración RRC actual. En la operación 2, en función de este reporte, el nodo de origen puede decidir solicitar un traspaso precoz del UE al nodo objetivo (p. ej., a una celda indicada en el reporte de medida). Por ejemplo, esta solicitud de traspaso precoz puede incluir un IE HandoverPreparationInformation como se describe anteriormente.

El nodo objetivo realiza el control de admisión para el UE y responde con el acuse de recibo del traspaso (operación 3) que incluye la configuración de RRC, similar al traspaso básico mostrado en la Figura 5. En la operación 4, el nodo de origen envía entonces al UE un "Comando HO Condicional", que puede incluir el umbral alto. Tras recibir este comando, el UE continúa realizando medidas y siempre que se cumpla la condición del umbral alto, puede moverse al nodo objetivo y realizar el traspaso (p. ej., operaciones 5-7). Aun así, el UE puede permanecer en la celda de servicio (es decir, proporcionada por el nodo de origen) durante un período de tiempo prolongado en caso de que no se cumpla la condición del umbral alto.

Esto permite que la celda de servicio prepare el traspaso tras la recepción de un reporte precoz de medida y proporcione el Comando HO Condicional (p. ej., RRCConnectionReconfiguration con mobilityControlInfo para LTE, o una RRCReconfiguration con una reconfigurationWithSync o una CellGroupConfig para NR) en un momento en el que el enlace de radio entre la celda de origen y el UE todavía es relativamente estable. El UE ejecuta el traspaso en un momento (y umbral) posterior que es óptimo y/o preferido.

Aunque la Figura 8 muestra un traspaso condicional ejemplar que involucra una sola celda de servicio y una sola celda objetivo, otros escenarios pueden involucrar muchas celdas o haces que el UE ha reportado como posibles candidatas en función de sus medidas de gestión de recursos de radio (RRM). La red debe tener la libertad de emitir comandos de traspaso condicional para cualquiera de esos candidatos. El Comando HO Condicional para cada uno de esos candidatos puede diferir, en términos de la condición de ejecución HO (p. ej., señal de referencia (RS) para medir, umbral para exceder, etc.) y/o en términos del preámbulo RA que se enviará cuando se cumple una condición.

Cada mensaje RRCConnectionReconfiguration/RRCReconfiguration normalmente es un "delta" con respecto a la configuración actual del UE. Los UEs de LTE aplican los mensajes RRCConnection-Reconfiguration en el orden en el que los reciben. Cuando el UE recibe un "comando HO condicionaf debe interpretar la señalización RRC correspondiente como delta a su configuración actual (a menos que sea un mensaje de configuración completa). En principio, puede determinar la configuración objetivo inmediatamente tras la recepción del comando, pero solo lo aplicará/ejecutará si se cumple la condición asociada. Mientras el UE evalúa la condición, debe continuar operando según su configuración RRC actual sin aplicar el comando HO condicional. Cuando el UE determina que se cumple la condición, se desconecta de la celda de servicio, aplica el comando HO condicional, y se conecta a la celda objetivo.

Dicho de otra manera, un UE está configurado con, al menos, una condición relacionada con la medida asociada con un comando u operación de movilidad (p. ej., un mensaje RRCReconfiguration o RRCConnectionReconfiguration), donde el UE aplicará el comando de movilidad y realizará acciones específicas tras la activación de la condición. Sin embargo, hay varios problemas con este proceso de configuración.

Primero, puede haber inconsistencias entre las medidas que el UE ya está configurado para realizar (p. ej., tras recibir un mensaje anterior que contiene measConfig) y las medidas asociadas con la(s) condición(es) del comando de movilidad condicional. En otras palabras, no está claro si las medidas que deben realizarse para el seguimiento de las condiciones asociadas están configuradas correctamente. Por ejemplo, pueden faltar ciertos parámetros.

En segundo lugar, el comando de movilidad condicional puede necesitar incluir una gran cantidad de información de configuración para el UE, que puede ser necesario transmitir en malas condiciones de radio. La combinación de mensajes grandes y malas condiciones de radio aumenta la probabilidad de que el comando se retrase, ocasionando un RLF para el UE.

La Figura 9, que incluye las Figuras 9A-9C, muestra tres técnicas diferentes para configurar un UE con una condición de activación de movilidad condicional (p. ej., CHO), que abordan, al menos parcialmente, algunos de estos problemas. La Figura 9A muestra la señalización de una técnica en la que el UE recibe, de la red (p. ej., gNB), una configuración de movilidad condicional (p. ej., RRCConditionalReconfiguration) que incluye, al menos, una condición de activación para un procedimiento de movilidad (p. ej., traspaso). La condición de activación puede incluir, al menos, una referencia a, o un identificador de, una configuración de medida (p. ej., etiquetado como "identificador-X*" en la Figura 9A). Después de recibir la condición de activación con el identificador incluido, el UE determina si las medidas asociadas con el identificador necesitan ser iniciadas, o si ya están siendo realizadas por el UE.

La Figura 9B muestra una variación de la técnica mostrada en la Figura 9A. En esta variación, el identificador-X* proporcionado hace referencia a una configuración de medida ya almacenada en el UE, posiblemente recibida en un mensaje procesado antes del mensaje que incluye la configuración de movilidad condicional. Como tal, el mensaje de configuración de movilidad condicional no necesita incluir una configuración de medida detallada, solo el identificador de la configuración recibida anticipadamente. Después de recibir el identificador, el UE puede emparejarlo con la configuración almacenada e iniciar medidas en función de esa configuración coincidente.

La Figura 9C muestra otra variación de la técnica mostrada en la Figura 9A. En esta variación, el identificador proporcionado hace referencia a una configuración de medida que también se proporciona con la configuración de movilidad condicional. En otras palabras, el mensaje puede contener una configuración de medida (etiquetada measConfig) y una referencia a ella (etiquetada identificador-X*). En esta variación, la configuración de medida puede proporcionarse explícitamente a efectos de la movilidad condicional (p. ej., reanudación/restablecimiento/traspaso condicional). Después de recibir el mensaje, el UE puede almacenar la configuración proporcionada y también iniciar medidas basadas en ella.

Aunque las técnicas ilustradas por la Figura 9 abordan medidas para detectar la condición de activación previa a la movilidad, no abordan ninguna medida que deba ocurrir en la ejecución del propio procedimiento de movilidad (p. ej., en el traspaso) después de que se haya detectado la condición de activación. Por ejemplo, para cada celda objetivo candidata para traspaso después de que se cumpla la condición de activación, la configuración CHO puede incluir la siguiente información:

• Configuración de la condición de activación (incluida una configuración de medida); y

• RRCReconfiguration con reconfigurationWithSync (o parámetros/campos/IEs equivalentes a los definidos para estos mensajes, utilizados para traspaso/reconfiguración).

La Figura 10 muestra un flujo de señalización de una técnica de movilidad condicional ejemplar (p. ej., CHO) que involucra tres configuraciones de medida del UE diferentes - measConfig, measConfig, y measConfig*. Cada RRCReconfiguration puede contener su propia configuración de medida (p. ej., una measConfig*), que puede indicarse mediante señalización delta en relación con la configuración de medida del UE actual, p. ej., measConfig utilizada por el UE 1010 (en lo sucesivo denominado "UE") antes de que se configurara la operación de movilidad condicional. En otras palabras, la measConfig* generada por cada nodo objetivo en la RRCReconfiguration es la que ese nodo objetivo espera que el UE utilice en la celda objetivo después de la ejecución de la operación de movilidad.

Como se muestra en la Figura 10, inicialmente el UE está operando en el estado RRC _CONNECTED con una configuración de medida almacenada, measConfig. El nodo de origen 1020 (p. ej., un gNB, posteriormente denominado "nodo de origen") que da servicio a la celda de origen actual del UE también es consciente de measConfig. Posteriormente, el nodo de origen decide configurar un CHO para el UE a una celda objetivo en particular servida por un nodo objetivo 1030 (p. ej., un gNB, posteriormente denominado "nodo objetivo"). Por ejemplo, esta decisión puede basarse en reportes de medida del UE. Similar a la disposición mostrada en la Figura 8, el nodo de origen y el nodo objetivo intercambian mensajes, con el nodo objetivo proporcionando measConfig* para ser utilizado por el UE en la celda objetivo después de la ejecución del CHO.

Por otro lado, como se discutió anteriormente, el nodo de origen puede necesitar reconfigurar la configuración de medida del UE actual measConfig, para la detección de la condición de activación antes de la operación de movilidad. Esto también puede hacerse mediante la señalización delta de la measConfig’, que puede ser diferente de measConfig*. Por ejemplo, measConfig' podría incluir un nuevo evento, un nuevo valor de umbral, una nueva portadora, etc. que es diferente tanto de measConfig como de measConfig*.

Una vez configurado de esta manera, el UE comienza a monitorizar las condiciones de activación del CHO utilizando measConfig'. Si se cumple la condición de CHO, el UE ejecuta el CHO (que, en este punto, es sustancialmente equivalente a un traspaso ordinario) utilizando la measConfig* preparada por la celda objetivo donde el UE está ejecutando el procedimiento. En el caso de la señalización delta, dado que el UE utilizó más recientemente measConfig'para detectar la condición de activación del CHO, el UE aplicaría la señal de delta measConfig* contra measConfig'. Sin embargo, el nodo objetivo previamente determinó measConfig* en función de la measConfig original del UE antes de recibir el comando de CHO. De hecho, el nodo objetivo no es consciente de la measConfig' al preparar measConfig*.

Eso crea una discrepancia de estado donde el UE y la red asumen una configuración diferente para determinar qué tipos de medidas realizará el UE en la celda objetivo. Eso puede conducir a varios problemas, como que el UE realice medidas innecesarias (que consumen la batería del UE), no realice ciertas medidas decididas por un objetivo en particular donde se ejecutó el CHO, reporte medidas utilizando algunos IDs de medida desconocidos para el nodo objetivo, etc.

Las realizaciones ejemplares de la presente descripción abordan estos y otros problemas, desafíos, y/o cuestiones al proporcionar mejoras específicas y/o mejoras a la robustez de la movilidad en redes inalámbricas. En general, las realizaciones incluyen técnicas y/o mecanismos que configuran un UE con varias configuraciones de medida de una manera que evita la confusión sobre qué configuración de medida almacenada debe utilizar un UE después de la ejecución de una operación de movilidad condicional (p. ej., CHO). Utilizando estas realizaciones, tanto el UE como el nodo objetivo para la operación de movilidad tienen una comprensión consistente de qué medidas realizará y/o reportará el UE después de la ejecución de la operación de movilidad hacia el nodo objetivo (p. ej., a una celda objetivo servida por el nodo objetivo).

Según varias realizaciones, un UE puede gestionar correctamente configuraciones de medida relacionadas con la activación del CHO y la ejecución del CHO. En varias realizaciones, el UE puede distinguir entre los siguientes tres tipos de configuraciones de medida:

• Primera configuración de medida utilizada en la celda de origen, p. ej., antes de un comando de CHO;

• Segunda configuración de medida también utilizada en la celda de origen, pero relacionada con la monitorización de las condiciones de activación del CHO; y

• Tercera configuración de medida preparada para cada candidato objetivo de CHO, y que se aplicará solo tras la ejecución del CHO a ese candidato elegido.

Tras la ejecución del CHO, el UE elimina la segunda configuración de medida y aplica la tercera. En el caso de una tercera configuración completa (p. ej., sin señal de delta), el UE también puede eliminar la primera configuración. En el caso de una tercera configuración con señal de delta, el UE aplica la tercera configuración a la segunda configuración. En algunas realizaciones, el UE siempre tiene una única configuración de medida y la red garantiza que el UE esté configurado con las medidas correctas en cualquier momento.

En la siguiente discusión de las realizaciones ejemplares, los términos "traspaso" y "reconfiguración con sincronización" se utilizan como sinónimos. Como tal, un traspaso condicional también puede denominarse reconfiguración con sincronización condicional. En terminología NR, un comando de traspaso es normalmente un mensaje RRCReconfiguration con un campo reconfigurationWithSyncque contiene la configuración necesaria para ejecutar el traspaso. En terminología LTE, un comando de traspaso es normalmente un mensaje RRCConnectionReconfiguration con un campo mobilityControlInfo que contiene la configuración necesaria para ejecutar el traspaso.

Las acciones del UE y de la red se describen principalmente en la presente memoria utilizando terminología NR, p. ej., configuración de CHO recibida en NR para celdas NR, con CHO ejecutado en NR. Sin embargo, las realizaciones ejemplares también son aplicables a escenarios no de NR, como:

• El UE se configura con un HO condicional en NR (para celdas NR y LTE candidatas), luego se activa la condición para una celda NR y el UE ejecuta el HO en NR;

• El UE se configura con un HO condicional en LTE (para celdas NR y LTE candidatas), luego se activa la condición para una celda LTE y el UE ejecuta el HO en LTE;

• El UE se configura con un HO condicional en NR (para celdas NR y LTE candidatas), luego se activa la condición para una celda LTE y el UE ejecuta el HO en LTE;

• El UE se configura con un HO condicional en LTE (para celdas NR y LTE candidatas), luego se activa la condición para una celda NR y el UE ejecuta el HO en NR;

• De manera más general, el UE se configura con un HO condicional en RAT-1 para celdas en RAT-1 o RAT-2, luego se activa la condición, y el UE ejecuta el HO en RAT-2.

En general, las realizaciones ejemplares se describen en términos de traspaso condicional, pero se pretende que sean ejemplares en lugar de limitantes. Las realizaciones también son aplicables para traspasos activados por la recepción de un mensaje RRCReconfiguration con una reconfigurationWithSync sin ninguna condición asociada (o RRCConnection-Reconfiguration con una mobilityControlInfo). En otras palabras, mientras que el UE está monitorizando las condiciones del CHO y ha recibido la segunda configuración de medida, el UE puede recibir una RRCReconfiguration con una reconfigurationWithSync que indica que el UE dejará de monitoriza las condiciones del CHO y realizará un traspaso a la celda objetivo indicada. Luego, tras la ejecución de un traspaso a la celda objetivo indicada, el UE puede haber almacenado la segunda configuración de medida. Por lo tanto, las acciones descritas en la invención, p. ej., eliminar/liberar esta segunda configuración de medida, siguen siendo aplicables.

Las realizaciones ejemplares también son aplicables a las configuraciones almacenadas durante la recuperación, p. ej., debido a un fallo del enlace de radio o de traspaso. En dicho caso, la invención también cubre el caso en el que el UE elimina/libera la segunda configuración de medida. Las realizaciones ejemplares también son aplicables en caso de suspensión o liberación, en las que el UE pasa a RRC_INACTIVE o RRC_IDLE, respectivamente. En ese caso, también se borra/libera la segunda configuración de medida, asociada al CHO.

En general, el término "traspaso condicional" (o CHO) se utiliza en el contexto de las realizaciones descritas para referirse a la movilidad condicional en general, que incluye reanudación condicional, reconfiguración con sincronización condicional, reconfiguración condicional, conmutación/recuperación de haz, así como traspaso condicional. Como tal, CHO debe interpretarse como cualquier procedimiento que es configurado por la red que incluye una condición (p. ej., asociada con un evento de medida) y una operación o procedimiento relacionado con la movilidad realizado tras la activación de esa condición.

Por ejemplo, el procedimiento de reanudación discutido anteriormente en relación con la Figura 4 puede adaptarse a una solución de movilidad condicional llamada "reanudación condicional", que tiene propiedades similares al HO condicional mostrado en la Figura 8. Más específicamente, el UE puede estar provisto con un umbral bajo "Y" para activar el reporte de medida mientras se encuentra en el estado RRC_INACTIVE, y en respuesta a las medidas reportadas, un nodo de servicio puede proporcionar al UE con un comando de "reanudación condicional" que incluye un umbral alto "X" para activar una reanudación hacia una celda objetivo proporcionada por un nodo objetivo. A diferencia del HO condicional, la reanudación condicional se basa en la obtención del contexto por parte del nodo objetivo. Incluso así, las realizaciones de las técnicas de configuración de medida para el HO condicional discutidas en la presente memoria son igualmente aplicables a, y pueden proporcionar ventajas similares para, las operaciones de reanudación condicional.

En general, la siguiente discusión utiliza el término "reanudación condicional" para referirse a una condición asociada con la activación de cualquiera de los siguientes:

• un procedimiento similar a la reanudación (p. ej., donde el UE transmite una RRCResumeRequest como un mensaje que contiene un identificador del contexto AS del UE asignado por el nodo de origen, como un I-RNTI, o un C-NRTI de origen un identificador de celda física de origen y un token de seguridad como un MAC-I abreviado / MAC-I de reanudación); o •

• un procedimiento de restablecimiento (p. ej., un procedimiento de restablecimiento del enlace de radio, donde el UE transmite una RRCReestablishmentRequest similar a un mensaje que contiene un identificador del contexto AS del UE asignado por la fuente, como un I-RNTI, o un C-NRTI de origen un identificador de celda física de origen y un token de seguridad como un MAC-I abreviado / MAC-I de reanudación).

Las realizaciones ejemplares también son aplicables a configuraciones de movilidad condicional asociadas con una sola celda o múltiples celdas. En el caso de una sola celda, puede proporcionarse una única referencia de configuración de medida y vincularla/asociarla con un procedimiento de movilidad, de modo que el UE monitoriza una condición específica y, cuando esa se cumpla, el UE ejecute un procedimiento específico hacia un nodo específico, p. ej., celda objetivo específica. En el caso de múltiples celdas, puede proporcionarse una única referencia de configuración de medida y vincularla a la monitorización de múltiples celdas dentro del mismo objeto de medida/frecuencia/etc. Alternativamente, pueden proporcionarse múltiples referencias de configuración de medida que se refieren o vinculan a diferentes celdas.

Como un ejemplo, para que las celdas sean monitorizadas para un traspaso condicional, el UE puede configurarse con una RRCReconfiguration con reconfigurationWithSync (para NR) o una RRCConnetionReconfiguration con mobilityControlInfo (para LTE), p. ej., asociada a una celda a la que se accede cuando se activa la condición.

Como otro ejemplo, para que las celdas sean monitorizadas para una reanudación condicional, el UE puede configurarse con, al menos, un I-RNTI (para NR) o ID de Reanudación (para LTE) (u otro identificador del UE) para ser incluido en la RRCResumeRequest (para NR) o la RRCConnectionResumeRequest(para LTE) (o un mensaje similar). Alternativamente, podría ser una C-RNTI de origen PCI, como en una solicitud de restablecimiento. Para NR, el nodo de origen puede proporcionar un I-RNTI abreviado o largo dependiendo de cómo cada objetivo potencial acepte un I-RNTI largo o abreviado, según la cobertura. El origen puede proporcionar ambos (abreviado y largo) I-RNTI y condiciones por celda de modo que, dependiendo de qué celda active la condición, el UE incluye el I-RNTI abreviado o largo del mensaje similar a la RRCResumeRequest.

El UE también puede configurarse con una RRCReconfiguration con reconfigurationWithSync (para NR) o una RRCConnectionReconfiguration con mobilityControlInfo (para LTE) que contiene alguna información de las celdas objetivo pero no una configuración completa, así como el identificador de UE, p. ej., I-RNTI o ID de Reanudación. La información de la celda objetivo puede comprender información normalmente transmitida en la información del sistema, p. ej., información RACH para un acceso más rápido en la celda objetivo. Esta información también puede incluirse en una parte del mensaje de reconfiguración distinto de reconfigurationWithSync o mobilityControlInfo. Las realizaciones ejemplares también pueden incluir la monitorización de la condición de activación de movilidad condicional tras la recepción de la configuración y, tras la activación de la condición para una celda-X específica, seleccionar entre traspaso condicional o reanudación condicional hacia la celda-X en función de una segunda condición.

La siguiente discusión de las realizaciones ejemplares se refiere a acciones tras la ejecución de un CHO u HO (no condicional). Por ejemplo, las especificaciones del 3GPP pueden definir un conjunto de operaciones que son las mismas para tanto CHO como HO. La característica distintiva puede ser que el CHO es un HO activado por el cumplimiento de una condición y un HO no condicional es activado por la recepción de una RRCReconfiguration con una reconfigurationWithSync. Por lo tanto, las realizaciones también son aplicables en el caso de que se cree un nuevo procedimiento llamado CHO o en el caso de que se active un procedimiento HO no condicional heredado por el cumplimiento de una condición.

La Figura 11 muestra un flujo de señalización de una técnica mejorada para proporcionar un UE con configuraciones de medida para ser utilizadas durante las fases de monitorización y ejecución de una operación de movilidad condicional (p. ej., CHO), según varias realizaciones ejemplares de la presente descripción. Aunque la técnica ejemplar se ilustra en la Figura 11 mediante operaciones específicas en un orden en particular, las operaciones mostradas pueden realizarse en órdenes diferentes a los mostrados y pueden combinarse y/o dividirse en operaciones que tienen una funcionalidad diferente a la mostrada. Además, la técnica ejemplar mostrada en la Figura 11 puede ser complementaria a otras técnicas, métodos, y/o procedimientos ejemplares descritos en la presente memoria, de modo que pueden utilizarse de manera cooperativa para proporcionar beneficios, ventajas, y/o soluciones a varios problemas, incluidos los descritos en la presente memoria.

La Figura 11 es similar en muchos aspectos al flujo de señalización mostrado en la Figura 10 y descrito anteriormente. Como tal, se utilizan los mismos números de referencia y solo se describirán a continuación las principales diferencias. Inicialmente, el UE se configura con measConfig (p. ej., a través de un RRCResume del nodo de origen), que puede almacenarse (p. ej., en VarMeasConfig) y utilizarse para realizar varias medidas. El UE puede reportar al nodo de origen las medidas hechas en función de measConfig.

Posteriormente, el nodo de origen determina que se necesita una operación de movilidad condicional (p. ej., CHO) para el UE. El nodo de origen envía, a cada uno del uno o más candidatos a nodos objetivo, una solicitud para aceptar la operación de movilidad condicional relacionada con el UE. La solicitud puede incluir la measConfig actual del UE. En la Figura 11 se muestra un solo candidato a nodo objetivo con fines de concisión y claridad. El nodo objetivo responde con una confirmación o acuse de recibo de la operación solicitada por el UE. La respuesta puede incluir la measConfig* que el nodo objetivo ha determinado que se necesita durante la ejecución de la operación de movilidad, es decir, después de que el UE haya detectado la condición que activa la operación de movilidad. La configuración measConfig* puede ser una configuración completa o una configuración delta con respecto a measConfig. Por ejemplo, puede prepararse un delta measConfig* en función de los diversos códigos de necesidad y las reglas y/o procedimientos de la lista AddMod discutidos anteriormente.

El nodo de origen determina entonces la measConfig' necesaria para que el UE pueda detectar y/o monitorizar la condición que activa la operación de movilidad. Por ejemplo, puede prepararse un delta measConfig' en función de los diversos códigos de Necesidad y las reglas y/o procedimientos de la lista AddMod discutidos anteriormente. El nodo de origen también puede almacenar measConfig’. En la realización mostrada en la Figura 11, el nodo de origen determina measConfig'después de recibir measConfig del nodo objetivo. En otras realizaciones, el nodo de origen puede determinar measConfig' (p. ej., como un delta a measConfig) antes de enviar la solicitud al nodo objetivo. En dicho caso, la solicitud al nodo objetivo también puede incluir m easConfigy el nodo objetivo puede determinar measConfig* como un delta a measConfig' y measConfig.

Posteriormente, el nodo de origen envía al UE un comando de movilidad condicional que incluye una primera indicación de la operación de movilidad a realizar, una segunda indicación de la condición de activación, la measConfig' relacionada con la detección de la condición de activación, y la measConfig* relacionada con la ejecución de la operación de movilidad con el nodo objetivo. Tras recibir este comando, el UE almacena measConfig'por separado de measConfig que se recibió anteriormente. En otras palabras, el UE mantiene measConfig en lugar de simplemente actualizarlo con el delta en measConfig’como se realiza convencionalmente. Por ejemplo, measConfig' puede almacenarse en una VarMeasConfig’ diferente o VarMeasConfigCHO. Alternativamente, measConfig' puede almacenarse en la misma VarMeasConfig utilizada pero en diferentes campos que pueden distinguirse como que están asociados con la movilidad condicional (p. ej., CHO). El UE también utiliza measConfig' para comenzar a realizar medidas para detectar la condición de activación indicada.

Puede darse el caso de que measConfig’y measConfig se solapen. Por ejemplo, tanto measConfig’ como measConfig pueden indicar que el UE realizará medidas en una portadora dada, p. ej., f0. En algunas realizaciones, measConfig' puede apuntar a measConfig, es decir, no necesita contener una configuración completamente separada. También, dado que measConfig ya está almacenado, no es necesario almacenarlo dos veces, excepto si hay alguna diferencia en la configuración (p. ej., misma portadora pero diferentes parámetros de derivación de la calidad de la celda, etc.). En algunas realizaciones, measConfig' se marcará con una indicación de si se liberará o no tras la ejecución del CHO. Eso puede estar indicado para toda la configuración o partes de ella. Por ejemplo, cada campo en la configuración puede tener una bandera que indica si debe liberarse o no tras la ejecución del CHO.

El UE también almacena la measConfig* recibida pero no la utiliza durante la detección de la activación, donde se utiliza measConfig' en su lugar. Tenga en cuenta que measConfig1 puede incluir configuraciones de medida para una o más celdas objetivo candidatas servidas por uno o más nodos objetivo (p. ej., celdas vecinas servidas por uno o más nodos de red). Las configuraciones de medida para las respectivas celdas objetivo pueden diferir de varias maneras. Dado que el UE no conoce (antes de activar la detección) la celda objetivo en la que ejecutará la operación de movilidad condicional, debe almacenar cada una de estas configuraciones.

En algunas realizaciones, measConfig1 puede identificarse por el hecho de que se proporciona en un campo/parámetro/IE/etc., diferente, o por el hecho de que se transmite en un mensaje diferente comparado con el mensaje que proporciona measConfig. Por ejemplo, measConfig* puede proporcionarse en un mensaje similar a RRCReconfiguration preparado por una celda vecina que es una candidata objetivo.

El UE también almacena measConfig* por separado de measConfig que se recibió anteriormente. En otras palabras, el UE mantiene measConfig en lugar de simplemente actualizarlo con el delta en measConfig*como se realiza convencionalmente. Por ejemplo, measConfig* puede almacenarse en una VarMeasConfig* diferente o VarMeasConfigCHO. Alternativamente, measConfig*puede almacenarse en la misma VarMeasConfig utilizada pero que tiene campos diferentes para que pueda distinguirse como que está asociada con la movilidad condicional (p. ej., CHO).

Una vez que el UE detecta la condición de activación, ejecuta la operación de movilidad indicada por el comando de movilidad condicional. Al ejecutar la operación de movilidad, el UE deja de realizar medidas en la celda de origen utilizando measConfig’, y actualiza la VarMeasConfig almacenada con measConfig* (ya sea como un delta a measConfig/measConfig' o como una configuración completa). En algunas realizaciones, el UE elimina y/o libera la measConfig'almacenada. En otras realizaciones, donde measConfig* es calculada por el nodo objetivo como un delta a measConfig'y measConfig, el UE retiene measConfig'ya que constituye parte de la nueva configuración de medida. El UE también accede a la celda objetivo (que incluye, p. ej., un mensaje RRCReconfiguration-Complete) y comienza a realizar y reportar medidas en la celda objetivo en función de measConfig*. Dado que el nodo objetivo (es decir, que sirve a la celda objetivo) proporcionó measConfig*, es plenamente consciente de las medidas que son reportadas por el UE durante la ejecución de la operación de movilidad, de modo que se evita un desajuste.

En algunas realizaciones, el nodo objetivo puede enviar un mensaje (p. ej., Liberación del Contexto del UE) al nodo de origen que indica que se ha ejecutado la operación de movilidad condicional. En respuesta a esta indicación, el nodo de origen puede eliminar y/o liberar cualquier configuración de medida almacenada asociada con el UE en la celda de origen, p. ej., measConfig y measConfig'.

La Figura 12 muestra un flujo de señalización de otra técnica mejorada para proporcionar un UE con configuraciones de medida para ser utilizadas durante las fases de monitorización y ejecución de una operación de movilidad condicional (p. ej., CHO), según varias realizaciones ejemplares de la presente descripción. Aunque la técnica ejemplar se ilustra en la Figura 12 mediante operaciones específicas en un orden en particular, las operaciones mostradas pueden realizarse en órdenes diferentes a los mostrados y pueden combinarse y/o dividirse en operaciones que tienen una funcionalidad diferente a la mostrada. Además, la técnica ejemplar mostrada en la Figura 12 puede ser complementaria a otras técnicas, métodos, y/o procedimientos ejemplares descritos en la presente memoria, de modo que pueden utilizarse de manera cooperativa para proporcionar beneficios, ventajas, y/o soluciones a varios problemas, incluidos los descritos en la presente memoria.

La Figura 12 es similar en muchos aspectos a los flujos de señalización mostrados en las Figuras 10-11 y descritos anteriormente. Como tal, se utilizan los mismos números de referencia y solo se describirán a continuación las principales diferencias. Una diferencia notable con la Figura 11 es que el UE solo almacena la configuración de medida actual y la red garantiza que no haya discrepancias entre la configuración de medida almacenada del UE y la configuración de medida almacenada de la red para el UE.

Después de recibir la respuesta del nodo objetivo, que incluye measConfig*, el nodo de origen determina entonces la measConfig'necesaria para que el UE pueda detectar y/o monitorizar la condición que activa la operación de movilidad. El nodo de origen envía al UE un comando de movilidad condicional que incluye una primera indicación de la operación de movilidad a realizar, una segunda indicación de la condición de activación, y la measConfig' relacionada con la detección de la condición de activación. Sin embargo, el nodo de origen no envía al UE la measConfig* (determinada por el nodo objetivo) relacionada con la ejecución de la operación de movilidad con el nodo objetivo.

En algunas realizaciones, el comando de movilidad condicional puede incluir una measConfig vacía para ser utilizada al realizar medidas en la celda objetivo después de la detección de la condición de activación. En dicho caso, el UE puede inferir de esta configuración vacía que measConfig' debe utilizarse para realizar medidas en la celda objetivo después de la detección de la condición de activación. En dicho caso, el nodo de origen también puede informar a todos los nodos objetivo candidatos de la measConfig' que el nodo de origen ha configurado para dichas medidas del UE.

Tras recibir este comando, el UE almacena measConfig'por separado de measConfig que se recibió anteriormente. En otras palabras, el UE mantiene measConfig en lugar de simplemente actualizarlo con el delta en measConfig'como se realiza convencionalmente. Por ejemplo, measConfig'puede almacenarse en una VarMeasConfig' diferente o VarMeasConfigCHO. Alternativamente, measConfig'puede almacenarse en la misma VarMeasConfig utilizada pero que tiene campos diferentes para que pueda distinguirse como que está asociada con la movilidad condicional (p. ej., CHO). El UE también utiliza measConfig' para comenzar a realizar medidas para detectar la condición de activación indicada.

Una vez que el UE detecta la condición de activación, ejecuta la operación de movilidad indicada por el comando de movilidad condicional. Al ejecutar la operación de movilidad, el UE deja de realizar medidas en la celda de origen utilizando measConfig', accede a la celda objetivo (que incluye, p. ej., un mensaje RRCReconfiguration-Complete), y comienza a realizar y reportar medidas en la celda objetivo en función de measConfig'. Dado que el nodo objetivo (es decir, que sirve a la celda objetivo) recibió measConfig', es plenamente consciente de las medidas que son reportadas por el UE durante la ejecución de la operación de movilidad, de modo que se evita un desajuste. Sin embargo, el nodo objetivo también puede determinar que se necesita una reconfiguración para las medidas del UE en la celda objetivo. En dicho caso, el nodo objetivo puede enviar un mensaje de reconfiguración al UE que incluye measConfig * . Alternativamente, el nodo objetivo puede enviar una configuración diferente a measConfig * (p.ej., measConfig**), en función de la determinación de que dicha configuración diferente sería deseable y/o beneficiosa de alguna manera.

En las realizaciones ilustradas por la Figura 12, las configuraciones measConfig, measConfig', measConfig*, y measConfig* pueden comunicarse como configuraciones delta o completas de las mismas varias formas descritas anteriormente con respecto a la Figura 11.

Las realizaciones descritas anteriormente pueden ilustrarse más con referencia a las Figuras 13-15, que representan métodos ejemplares (p. ej., procedimientos) realizados por un UE, un nodo RAN de origen, y un nodo RAN objetivo, respectivamente. En otras palabras, varias características de las operaciones descritas a continuación, con referencia a las Figuras 13 a 15, corresponden a varias realizaciones descritas anteriormente.

En particular, la Figura 13 ilustra un método ejemplar (p. ej., procedimiento) para movilidad condicional en una RAN, según varias realizaciones ejemplares de la presente descripción. El método ejemplar puede ser realizado por un equipo de usuario (UE, p.ej., dispositivo inalámbrico, dispositivo MTC, dispositivo NB-IoT, módem, etc. o componente del mismo) en comunicación con un nodo de red (p.ej., estación base, eNB, gNB, etc., o componentes del mismo) que da servicio a una celda en la RAN (p. ej., E-UTRAN, NG-RAN). Por ejemplo, el método ejemplar mostrado en la Figura 13 puede implementarse en un UE o dispositivo configurado según otras figuras descritas en la presente memoria.

Aunque el método ejemplar se ilustra en la Figura 13 mediante bloques específicos en un orden en particular, las operaciones correspondientes a los bloques pueden realizarse en órdenes diferentes a los mostrados y pueden combinarse y/o dividirse en bloques que tienen una funcionalidad diferente a la mostrada. Además, el método ejemplar mostrado en la Figura 13 puede ser complementario a otros métodos ejemplares descritos en la presente memoria (p. ej., Figuras 14-15), de modo que pueden utilizarse de manera cooperativa para proporcionar beneficios, ventajas, y/o soluciones a varios problemas, incluidos los descritos en la presente memoria. Los bloques y/u operaciones opcionales se indican mediante líneas discontinuas.

En algunas realizaciones, el método ejemplar puede incluir las operaciones del bloque 1310-1330. En el bloque 1310, el UE puede recibir, de un nodo RAN de origen que da servicio a la celda de origen del UE, una primera configuración de medida (p. ej., measConfig). En el bloque 1320, el UE puede almacenar la primera configuración de medida recibida (p. ej., en varMeasConfig). En el bloque 1330, el UE puede realizar y reportar primeras medidas en la celda de origen del UE en función de la primera configuración de medida. Estas operaciones pueden realizarse, por ejemplo, antes de las operaciones del bloque 1340, discutidas a continuación.

El método ejemplar también puede incluir las operaciones del bloque 1340, donde el UE puede recibir, de uno o más nodos RAN, uno o más mensajes relacionados con la movilidad que comprenden: una primera indicación de una operación de movilidad (p. ej., cualquiera de las operaciones de movilidad discutidas anteriormente); una segunda indicación de una condición de activación para la operación de movilidad; una segunda configuración de medida relacionada con una celda de origen; y una tercera configuración de medida relacionada con una o más celdas objetivo. Por ejemplo, la segunda configuración de medida (p. ej., measConfig') puede utilizarse para detectar el cumplimiento de la condición de activación en la celda de origen, y la tercera configuración de medida (p. ej., measConfig*) puede utilizarse en una de las celdas objetivo después de ejecutar la operación de movilidad.

En algunas realizaciones, las operaciones del bloque 1340 pueden incluir las operaciones del sub-bloque 1341, donde el UE puede almacenar, al menos, una parte de la segunda configuración de medida y de la tercera configuración de medida por separado de la primera configuración de medida (p. ej., en varMeasConfig, varMeasConfig’, varMeasConfig*, y/o varMeasConfigCHO).

En algunas realizaciones, uno o más mensajes relacionados con la movilidad pueden incluir un comando de movilidad condicional recibido de un nodo RAN de origen. El comando de movilidad condicional puede incluir las indicaciones primera y segunda y las configuraciones de medida segunda y tercera. Además, las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para la operación de movilidad indicada. En otras palabras, cada una de la segunda configuración de medida y de la tercera configuración de medida pueden incluir múltiples configuraciones de medida, es decir, una para cada una de las celdas objetivo candidatas.

En otras realizaciones, uno o más mensajes relacionados con la movilidad pueden incluir dos mensajes: un comando de movilidad condicional, recibido del nodo RAN de origen, que incluye las indicaciones primera y segunda y la segunda configuración de medida; y un mensaje de reconfiguración, recibido de un nodo RAN objetivo que da servicio a una celda objetivo, que incluye la tercera configuración de medida.

El método ejemplar también puede incluir las operaciones de los bloques 1350-1360, donde el UE puede, en función de la segunda configuración de medida, detectar el cumplimiento de la condición de activación con respecto a una en particular de las celdas objetivo y ejecutar la operación de movilidad hacia la celda objetivo en particular.

En algunas realizaciones, detectar el cumplimiento de la condición de activación en el bloque 1350 puede incluir las operaciones del sub-bloque 1351, donde el UE puede realizar segundas medidas en la celda de origen en función de la segunda configuración de medida. En algunas realizaciones, ejecutar la operación de movilidad en el bloque 1360 puede incluir operaciones de uno o más de los sub-bloques 1361-1363. En el sub-bloque 1361, el UE puede dejar de realizar segundas medidas en función de la segunda configuración de medida. En el sub-bloque 1362, el UE puede eliminar o liberar, al menos, una parte de una segunda configuración de medida almacenada. En el sub-bloque 1363, el UE puede almacenar la tercera configuración de medida.

En algunas realizaciones, la tercera configuración de medida puede recibirse como una configuración de medida completa. En dichas realizaciones, ejecutar la operación de movilidad en el bloque 1360 puede incluir las operaciones del sub-bloque 1364, donde el UE puede reemplazar una primera configuración de medida almacenada con la tercera configuración de medida.

En otras realizaciones, la tercera configuración de medida puede recibirse como un delta con respecto a una o más de la primera configuración de medida y de la segunda configuración de medida. En dichas realizaciones, ejecutar la operación de movilidad en el bloque 1360 puede incluir las operaciones del sub-bloque 1365, donde el UE puede determinar una configuración de medida, para las terceras medidas, en función de la tercera configuración de medida y una o más de la primera configuración de medida y de la segunda configuración de medida.

En algunas realizaciones, como cuando uno o más mensajes relacionados con la movilidad incluyen un comando de movilidad condicional y un mensaje de reconfiguración (discutidos anteriormente), ejecutar la operación de movilidad en el bloque 1360 puede incluir las operaciones de los sub-bloques 1366-1367. En el sub-bloque 1366, el UE puede realizar y reportar terceras medidas en la celda objetivo en particular en función de la segunda configuración de medida (p. ej., recibida en el comando de movilidad condicional). En el sub-bloque 1367, el UE puede recibir posteriormente el mensaje de reconfiguración que comprende la tercera configuración de medida.

El método ejemplar también puede incluir las operaciones del bloque 1370, donde el UE puede posteriormente realizar y reportar terceras medidas en la celda objetivo en particular en función de la tercera configuración de medida.

Además, la Figura 14 ilustra otro método ejemplar (p. ej., procedimiento) para la movilidad condicional de un equipo de usuario (UE) en una red de acceso por radio (RAN), según varias realizaciones ejemplares de la presente descripción. El método ejemplar puede ser realizado por un nodo RAN de origen (p.ej., estación base, eNB, gNB, etc., o componente del mismo) que da servicio a uno o más equipos de usuario (UEs, p. ej., dispositivos inalámbricos, dispositivos MTC, dispositivos NB-IoT, módems, etc. o componentes de los mismos) en una celda de la RAN (p. ej., E-UTRAN, NG-RAN). Por ejemplo, el método ejemplar mostrado en la Figura 14 puede implementarse mediante un nodo de red configurado según otras figuras descritas en la presente memoria.

Aunque el método ejemplar se ilustra en la Figura 14 mediante bloques específicos en un orden en particular, las operaciones correspondientes a los bloques pueden realizarse en órdenes diferentes a los mostrados y pueden combinarse y/o dividirse en bloques que tienen una funcionalidad diferente a la mostrada. Además, el método ejemplar mostrado en la Figura 14 puede ser complementario a otros métodos ejemplares descritos en la presente memoria (p. ej., Figuras 13 y 15), de modo que pueden utilizarse de manera cooperativa para proporcionar varios beneficios, ventajas, y/o soluciones a problemas, incluidos los descritos en la presente memoria. Los bloques y/u operaciones opcionales se indican mediante líneas discontinuas.

En algunas realizaciones, el método ejemplar puede incluir las operaciones del bloque 1410-1430. En el bloque 1410, el nodo RAN de origen puede enviar, al UE, una primera configuración de medida (p. ej., measConfig) relacionada con una celda de origen, para el UE, que es servida por el nodo RAN de origen. En algunas realizaciones, las operaciones del bloque 1410 pueden incluir las operaciones del sub-bloque 1412, donde el nodo RAN de origen puede almacenar la primera configuración de medida (p. ej., en varMeasConfig). En el bloque 1420, el nodo RAN de origen puede recibir primeras medidas realizadas por el UE en la celda de origen en función de la primera configuración de medida. En el bloque 1430, el nodo RAN de origen puede determinar que se requiere una operación de movilidad para el UE, en función de las primeras medidas.

El método ejemplar también puede incluir las operaciones del bloque 1440, donde el nodo RAN de origen puede enviar, a un nodo RAN objetivo, una solicitud para aceptar una operación de movilidad (p. ej., CHO) relacionada con el UE. En algunas realizaciones, la solicitud puede incluir la primera configuración de medida para el UE (p. ej., measConfig). La operación de movilidad puede ser la operación de movilidad determinada como requerida en el bloque 1430. El método ejemplar también puede incluir las operaciones del bloque 1450, donde el nodo RAN de origen puede recibir, del nodo RAN objetivo, una confirmación de la operación de movilidad, incluyendo la confirmación una tercera configuración de medida para el UE (p. ej., measConfig*) relacionado con una o más celdas objetivo servidas por el nodo RAN objetivo.

El método ejemplar también puede incluir las operaciones del bloque 1460, donde el nodo RAN de origen puede determinar una segunda configuración de medida (p. ejemplo, measConfig) relacionada con una condición de activación para la operación de movilidad. Por ejemplo, la segunda configuración de medida puede utilizarse para detectar el cumplimiento de la condición de activación en la celda de origen. En algunas realizaciones, las operaciones del bloque 1460 pueden incluir las operaciones del sub-bloque 1462, donde el nodo RAN de origen puede almacenar la segunda configuración de medida (p. ej., en varMeasConfig’ o varMeasConfigCHO). En algunas realizaciones, las operaciones del bloque 1460 pueden incluir las operaciones del sub-bloque 1464, donde el nodo RAN de origen puede enviar la segunda configuración de medida al nodo RAN objetivo.

El método ejemplar también puede incluir las operaciones del bloque 1470, donde el nodo RAN de origen puede enviar, al UE, un mensaje relacionado con la movilidad que comprende: una primera indicación de una operación de movilidad (p. ej., cualquiera de las operaciones de movilidad discutidas anteriormente); una segunda indicación de una condición de activación para la operación de movilidad; y la segunda configuración de medida (p. ej., measConfig). En algunas realizaciones, el mensaje relacionado con la movilidad también puede incluir la tercera configuración de medida (p. ej., measConfig*). Además, las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para la operación de movilidad indicada. En otras palabras, cada una de la segunda configuración de medida y de la tercera configuración de medida pueden incluir múltiples configuraciones de medida, es decir, una para cada una de las celdas objetivo candidatas.

En algunas realizaciones, el método ejemplar también puede incluir las operaciones de los bloques 1480-1490. En el bloque 1480, el nodo RAN de origen puede recibir, del nodo RAN objetivo, una tercera indicación de que se ha completado la operación de movilidad. En el bloque 1490, el nodo RAN de origen puede, en respuesta a la tercera indicación, eliminar o liberar, al menos, una parte de las configuraciones de medida primera y segunda almacenadas.

En algunas realizaciones, al menos, una de las siguientes condiciones aplica: la segunda configuración de medida se determina como un delta con respecto a la primera configuración de medida; la tercera configuración de medida se recibe como un delta con respecto a la primera configuración de medida; y la tercera configuración de medida se recibe como un delta con respecto a la primera y a la segunda configuración de medida.

Además, la Figura 15 ilustra otro método ejemplar (p. ej., procedimiento) para la movilidad condicional de un equipo de usuario (UE) en una red de acceso por radio (RAN), según varias realizaciones ejemplares de la presente descripción. El método ejemplar puede ser realizado por un nodo RAN objetivo (p.ej., estación base, eNB, gNB, etc., o componente del mismo) (UEs, p. ej., dispositivos inalámbricos, dispositivos MTC, dispositivos NB-IoT, módems, etc. o componentes de los mismos) que da servicio a una celda objetivo en la RAN (p. ej., E-UTRAN, NG-RAN). Por ejemplo, el método ejemplar mostrado en la Figura 15 puede implementarse mediante un nodo de red configurado según otras figuras descritas en la presente memoria.

Aunque el método ejemplar se ilustra en la Figura 15 mediante bloques específicos en un orden en particular, las operaciones correspondientes a los bloques pueden realizarse en órdenes diferentes a los mostrados y pueden combinarse y/o dividirse en bloques que tienen una funcionalidad diferente a la mostrada. Además, el método ejemplar mostrado en la Figura 15 puede ser complementario a otros métodos ejemplares descritos en la presente memoria (p. ej., Figuras 13-14), de modo que pueden utilizarse de manera cooperativa para proporcionar varios beneficios, ventajas, y/o soluciones a problemas, incluidos los descritos en la presente memoria. Los bloques y/u operaciones opcionales se indican mediante líneas discontinuas.

El método ejemplar puede incluir las operaciones del bloque 1510, donde el nodo RAN objetivo puede recibir, de un nodo RAN de origen, una solicitud para aceptar una operación de movilidad (p. ej., CHO) relacionada con el UE. La solicitud puede incluir una primera configuración de medida para el UE (p. ej., measConfig). El método ejemplar también puede incluir las operaciones del bloque 1520, donde el nodo RAN objetivo puede determinar una tercera configuración de medida (p. ej., measConfig*) para el UE en relación con una o más celdas objetivo servidas por el nodo RAN objetivo. La tercera configuración de medida puede basarse en (p. ej., un delta con respecto a) la primera configuración de medida.

El método ejemplar también puede incluir las operaciones del bloque 1530, donde el nodo RAN objetivo puede enviar, al nodo RAN de origen, una confirmación de la operación de movilidad, incluyendo la confirmación la tercera configuración de medida. En varias realizaciones, la tercera configuración de medida puede enviarse como una configuración de medida completa, o como un delta con respecto a la primera configuración de medida y/o a la segunda configuración de medida. El método ejemplar también puede incluir las operaciones del bloque 1570, donde el nodo RAN objetivo puede recibir, del UE, medidas hechas en una en particular de las celdas objetivo en función de la tercera configuración de medida.

En algunas realizaciones, el método ejemplar también puede incluir las operaciones del bloque 1550-1560. En el bloque 1550, el nodo RAN objetivo puede recibir medidas hechas por el UE para la celda objetivo en particular, en función de la segunda configuración de medida. En el bloque 1560, el nodo RAN objetivo puede enviar posteriormente, al UE, un mensaje de reconfiguración que incluye la tercera configuración de medida.

En estas realizaciones, el método ejemplar también puede incluir las operaciones del bloque 1540, donde el nodo RAN objetivo puede recibir, del nodo RAN de origen, una segunda configuración de medida para el UE. La segunda configuración de medida (p. ej., measConfig) puede recibirse como un delta con respecto a la primera configuración de medida (p. ej., measConfig). En dichas realizaciones, la tercera configuración de medida, incluida en el mensaje de reconfiguración, es un delta con respecto a la primera configuración de medida y a la segunda configuración de medida.

En algunas realizaciones, el método ejemplar también puede incluir las operaciones del bloque 1580, donde el nodo RAN objetivo puede enviar, al nodo RAN de origen, una indicación de que se ha completado la operación de movilidad.

Aunque el tema en cuestión descrito en la presente memoria puede implementarse en cualquier tipo apropiado de sistema utilizando cualquier componente adecuado, las realizaciones descritas en la presente memoria se describen en relación con una red inalámbrica, como la red inalámbrica de ejemplo ilustrada en la Figura 16. Por simplicidad, la red inalámbrica de la Figura 16 solo representa la red 1606, los nodos 1660 y 1660b de red, y los WDs 1610, 1610b, y 1610c. En la práctica, una red inalámbrica puede incluir además cualquier elemento adicional adecuado para admitir la comunicación entre dispositivos inalámbricos o entre un dispositivo inalámbrico y otro dispositivo de comunicación, como un teléfono fijo, un proveedor de servicios, o cualquier otro nodo de red o dispositivo final. De los componentes ilustrados, el nodo 1660 de red y el dispositivo inalámbrico (WD) 1610 se representan con detalles adicionales. La red inalámbrica puede proporcionar comunicación y otros tipos de servicios a uno o más dispositivos inalámbricos para facilitar el acceso de los dispositivos inalámbricos y/o el uso de los servicios proporcionados por, o a través de, la red inalámbrica.

La red inalámbrica puede comprender y/o interactuar con cualquier tipo de red de comunicación, telecomunicación, datos, celular, y/o de radio u otro tipo similar de sistema. En algunas realizaciones, la red inalámbrica puede configurarse para operar según estándares específicos u otros tipos de reglas o procedimientos predefinidos. De este modo, las realizaciones particulares de la red inalámbrica pueden implementar estándares de comunicación, como el Sistema Global para Comunicaciones Móviles (GSM), el Sistema Universal de Telecomunicaciones Móviles (UMTS), la Evolución a Largo Plazo (LTE), y/u otros estándares 2G, 3G, 4G, o 5G adecuados; estándares de red de área local inalámbrica (WLAN), como los estándares del IEEE 802.11; y/o cualquier otro estándar de comunicación inalámbrica apropiado, como los estándares de Interoperabilidad Mundial para Acceso por Microondas (WiMax), Bluetooth, Z-Wave y/o ZigBee.

La red 1606 puede comprender una o más redes de retorno, redes centrales, redes IP, redes telefónicas públicas conmutadas (PSTN), redes de datos por paquetes, redes ópticas, redes de área amplia (WANs), redes de área local (LANs), redes de área local inalámbrica (WLANs), redes cableadas, redes inalámbricas, redes de área metropolitana, y otras redes que permitan la comunicación entre dispositivos.

El nodo 1660 de red y el WD 1610 comprenden varios componentes descritos con más detalle a continuación. Estos componentes trabajan juntos para proporcionar funcionalidad del nodo de red y/o del dispositivo inalámbrico, como proporcionar conexiones inalámbricas en una red inalámbrica. En diferentes realizaciones, la red inalámbrica puede comprender cualquier número de redes cableadas o inalámbricas, nodos de red, estaciones base, controladores, dispositivos inalámbricos, estaciones repetidoras, y/o cualquier otro componente o sistema que pueda facilitar o participar en la comunicación de datos y /o señales ya sea a través de conexiones cableadas o inalámbricas.

Los ejemplos de nodos de red incluyen, pero no se limitan a, puntos de acceso (APs) (p.ej., puntos de acceso por radio), estaciones base (BSs) (p.ej., estaciones base de radio, Nodos B, Nodos B evolucionados (eNBs) y Nodos B de NR (gNBs)). Las estaciones base pueden categorizarse en función de la cantidad de cobertura que proporcionan (o, dicho de otra manera, su nivel de potencia de transmisión) y también entonces pueden denominarse femto estaciones base, pico estaciones base, micro estaciones base, o macro estaciones base. Una estación base puede ser un nodo de retransmisión o un nodo donante de retransmisión que controla una retransmisión. Un nodo de red también puede incluir una o más (o todas) partes de una estación base de radio distribuida, como unidades digitales centralizadas y/o unidades de radio remotas (RRUs), a veces denominadas Cabezas de Radio Remotas (RRHs). Dichas unidades de radio remotas pueden o no estar integradas con una antena como una antena de radio integrada. Las partes de una estación base de radio distribuida también pueden denominarse nodos en un sistema de antena distribuida (DAS).

Ejemplos adicionales de nodos de red incluyen equipos de radio multi-estándar (MSR) como BSs MSR, controladores de red como controladores de red de radio (RNCs) o controladores de estación base (BSCs), estaciones transceptoras base (BTSs), puntos de transmisión, nodos de transmisión, entidades de coordinación de celda múltiple/multidifusión (MCEs), nodos de red central (p.ej., MSCs, MMEs), nodos O&M, nodos OSS, nodos SON, nodos de posicionamiento (p.ej., E-SMLCs), y/o MDTs. Como otro ejemplo, un nodo de red puede ser un nodo de red virtual como se describe con más detalle a continuación. Sin embargo, de manera más general, los nodos de red pueden representar cualquier dispositivo (o grupo de dispositivos) adecuado capaz, configurado, dispuesto, y/u operable para habilitar y/o proporcionar un dispositivo inalámbrico con acceso a la red inalámbrica o para proporcionar algún servicio a un dispositivo inalámbrico que ha accedido a la red inalámbrica.

En la Figura 16, el nodo 1660 de red incluye el circuito 1670 de procesamiento, el medio 1680 legible por dispositivo, la interfaz 1690, el equipo auxiliar 1684, la fuente 1686 de alimentación, el circuito 1687 de alimentación, y la antena 1662. Aunque el nodo 1660 de red ilustrado en la red inalámbrica de ejemplo de la Figura 16 puede representan un dispositivo que incluye la combinación ilustrada de componentes hardware, otras realizaciones pueden comprender nodos de red con diferentes combinaciones de componentes. Debe entenderse que un nodo de red comprende cualquier combinación adecuada de hardware y/o software necesaria para realizar las tareas, características, funciones y métodos y/o procedimientos descritos en la presente memoria. Además, mientras que los componentes del nodo 1660 de red se representan como cajas individuales ubicadas dentro de una caja más grande, o anidadas dentro de múltiples cajas, en la práctica, un nodo de red puede comprender múltiples componentes físicos diferentes que conforman un solo componente ilustrado (p.ej., el medio 1680 legible por dispositivo puede comprender múltiples discos duros separados, así como múltiples módulos de RAM).

De manera similar, el nodo 1660 de red puede estar compuesto de múltiples componentes físicamente separados (p.ej., un componente NodoB y un componente RNC, o un componente BTS y un componente BSC, etc.), que pueden tener cada uno sus propios componentes respectivos. En ciertos escenarios en los que el nodo 1660 de red comprende múltiples componentes separados (p.ej., componentes BTS y BSC), uno o más de los componentes separados pueden compartirse entre varios nodos de red. Por ejemplo, un único RNC puede controlar múltiples Nodos B. En dicho escenario, cada par único de NodoB y RNC puede, en ciertas ocasiones, considerarse un único nodo de red separado. En algunas realizaciones, el nodo 1660 de red puede configurarse para admitir múltiples tecnologías de acceso por radio (RATs). En dichas realizaciones, algunos componentes pueden duplicarse (p.ej., el medio 1680 legible por dispositivo separado para las diferentes RATs) y algunos componentes pueden reutilizarse (p.ej., la misma antena 1662 puede ser compartida por las RATs). El nodo 1660 de red también puede incluir múltiples conjuntos de los diversos componentes ilustrados para diferentes tecnologías inalámbricas integradas en el nodo 1660 de red, como, por ejemplo, tecnologías inalámbricas GSM, WCDMA, LTE, NR, WiFi, o Bluetooth. Estas tecnologías inalámbricas pueden integrarse en el mismo o diferente chip o conjunto de chips y otros componentes dentro del nodo 1660 de red.

El circuito 1670 de procesamiento puede configurarse para realizar cualquier operación de determinación, cálculo, o similar (p. ej., ciertas operaciones de obtención) descritas en la presente memoria como proporcionadas por un nodo de red. Estas operaciones realizadas por el circuito 1670 de procesamiento pueden incluir el procesamiento de la información obtenida mediante el circuito 1670 de procesamiento, por ejemplo, convirtiendo la información obtenida en otra información, comparando la información obtenida o información convertida con información almacenada en el nodo de red, y/o realizando una o más operaciones en función de la información obtenida o información convertida, y como resultado de dicho procesamiento, tomar una determinación.

El circuito 1670 de procesamiento puede comprender una combinación de uno o más de un microprocesador, controlador, microcontrolador, unidad central de procesamiento, procesador de señales digitales, circuito integrado de aplicación específica, matriz de puertas lógicas programable en campo, o cualquier otro dispositivo informático adecuado, recurso, o combinación de hardware, software, y/o lógica codificada operable para proporcionar varias funcionalidades del nodo 1660 de red, ya sea solo o junto con otros componentes del nodo 1660 de red (p. ej., medio 1680 legible por dispositivo). Dicha funcionalidad puede incluir cualquiera de las diversas características, funciones, o beneficios inalámbricos discutidos en la presente memoria.

Por ejemplo, el circuito 1670 de procesamiento puede ejecutar instrucciones almacenadas en el medio 1680 legible del dispositivo o en la memoria dentro del circuito 1670 de procesamiento. En algunas realizaciones, el circuito 1670 de procesamiento puede incluir un sistema en un chip (SOC). Como un ejemplo más específico, las instrucciones (también denominadas producto de programa informático) almacenadas en el medio 1680 pueden incluir instrucciones que, cuando son ejecutadas por el circuito 1670 de procesamiento, pueden configurar el nodo 1660 de red para realizar operaciones correspondientes a varios métodos ejemplares (p. ej., procedimientos) descritos en la presente memoria.

En algunas realizaciones, el circuito 1670 de procesamiento puede incluir uno o más de un circuito 1672 transceptor de radio frecuencia (RF) y de un circuito 1674 de procesamiento de banda base. En algunas realizaciones, el circuito 1672 transceptor de radiofrecuencia (RF) y el circuito 1674 de procesamiento de banda base pueden estar en chips (o conjuntos de chips) separados, tableros, o unidades, como unidades de radio y unidades digitales. En realizaciones alternativas, parte o la totalidad del circuito 1672 transceptor de RF y del circuito 1674 de procesamiento de banda base pueden estar en el mismo chip o conjunto de chips, tableros, o unidades.

En ciertas realizaciones, parte o toda la funcionalidad descrita en la presente memoria como proporcionada por un nodo de red, estación base, eNB u otro dispositivo de red similar puede ser realizada por el circuito 1670 de procesamiento, que ejecuta las instrucciones almacenadas en el medio 1680 legible por dispositivo o en la memoria dentro del circuito 1670 de procesamiento. En realizaciones alternativas, parte o toda la funcionalidad puede ser proporcionada por el circuito 1670 de procesamiento sin ejecutar las instrucciones almacenadas en un medio legible por dispositivo separado o discreto, como de manera cableada. En cualquiera de esas realizaciones, ya sea ejecutando instrucciones almacenadas en un medio de almacenamiento legible por dispositivo o no, el circuito 1670 de procesamiento puede configurarse para realizar la funcionalidad descrita. Los beneficios proporcionados por dicha funcionalidad no se limitan al circuito 1670 de procesamiento solo o a otros componentes del nodo 1660 de red, sino que los disfruta el nodo 1660 de red en su conjunto, y/o los usuarios finales y la red inalámbrica en general.

El medio 1680 legible por dispositivo puede comprender cualquier forma de memoria legible por ordenador volátil o no volátil que incluye, sin limitaciones, almacenamiento persistente, memoria de estado sólido, memoria montada de forma remota, medios magnéticos, medios ópticos, memoria de acceso aleatorio (RAM), memoria de solo lectura (ROM), medios de almacenamiento masivos (por ejemplo, un disco duro), medios de almacenamiento extraíbles (por ejemplo, una unidad flash, 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 transitoria, legible por dispositivo y/o ejecutable por ordenador que almacena información, datos, y/o instrucciones que pueden ser utilizadas por el circuito 1670 de procesamiento. El medio 1680 legible por dispositivo puede almacenar cualquier instrucción, dato o información adecuada, incluido un programa informático, software, una aplicación que incluye uno o más de lógica, reglas, código, tablas, etc. y/u otras instrucciones capaces de ser ejecutadas por el circuito 1670 de procesamiento y, utilizadas por el nodo 1660 de red. El medio 1680 legible por dispositivo puede utilizarse para almacenar cualquier cálculo hecho por el circuito 1670 de procesamiento y/o cualquier dato recibido a través de la interfaz 1690. En algunas realizaciones, el circuito 1670 de procesamiento y el medio 1680 legible por dispositivo pueden considerarse integrados.

La interfaz 1690 se utiliza en la comunicación por cable o inalámbrica de señalización y/o datos entre el nodo 1660 de red, la red 1606, y/o los WDs 1610. Como se ilustra, la interfaz 1690 comprende puerto(s)/terminal(es) 1694 para enviar y recibir datos, por ejemplo hacia y desde la red 1606 a través de una conexión por cable. La interfaz 1690 también incluye un circuito 1692 de la interfaz radio que puede acoplarse a, o en ciertas realizaciones ser una parte de, la antena 1662. El circuito 1692 de la interfaz radio comprende filtros 1698 y amplificadores 1696. El circuito 1692 de la interfaz radio puede conectarse a la antena 1662 y al circuito 1670 de procesamiento. El circuito de la interfaz radio puede configurarse para acondicionar las señales comunicadas entre la antena 1662 y el circuito 1670 de procesamiento. El circuito 1692 de la interfaz radio puede recibir datos digitales que se enviarán a otros nodos de red o WDs a través de una conexión inalámbrica. El circuito 1692 de la interfaz radio puede convertir los datos digitales en una señal de radio que tenga los parámetros de canal y ancho de banda apropiados utilizando una combinación de filtros 1698 y/o amplificadores 1696. La señal de radio puede entonces transmitirse a través de la antena 1662. De manera similar, al recibir datos, la antena 1662 puede recopilar señales de radio que luego son convertidas en datos digitales por el circuito 1692 de la interfaz radio. Los datos digitales pueden pasarse al circuito 1670 de procesamiento. En otras realizaciones, la interfaz puede comprender diferentes componentes y/o diferentes combinaciones de componentes.

En ciertas realizaciones alternativas, el nodo 1660 de red puede no incluir un circuito 1692 de la interfaz radio separado, en su lugar, el circuito 1670 de procesamiento puede comprender un circuito de la interfaz radio y puede conectarse a la antena 1662 sin un circuito 1692 de la interfaz radio separado. De manera similar, en algunas realizaciones, todo o parte del circuito 1672 transceptor de RF pueden considerarse parte de la interfaz 1690. En otras realizaciones, la interfaz 1690 puede incluir uno o más puertos o terminales 1694, circuitos 1692 de la interfaz radio, y circuitos 1672 transceptores de RF, como parte de una unidad de radio (no mostrada), y la interfaz 1690 puede comunicarse con el circuito 1674 de procesamiento de banda base, que es parte de una unidad digital (no mostrada).

La antena 1662 puede incluir una o más antenas, o conjuntos de antenas, configuradas para enviar y/o recibir señales inalámbricas. La antena 1662 puede acoplarse a un circuito 1690 de la interfaz radio y puede ser cualquier tipo de antena capaz de transmitir y recibir datos y/o señales de forma inalámbrica. En algunas realizaciones, la antena 1662 puede comprender una o más antenas omnidireccionales, sectoriales o de panel operables para transmitir/recibir señales de radio entre, por ejemplo, 2 GHz y 66 GHz. Una antena omnidireccional puede utilizarse para transmitir/recibir señales de radio en cualquier dirección, una antena sectorial puede utilizarse para transmitir/recibir señales de radio de dispositivos dentro de un área en particular, y una antena de panel puede ser una antena de línea de visión utilizada para transmitir/recibir señales de radio en una línea relativamente recta. En ciertas ocasiones, el uso de más de una antena puede denominarse MIMO. En ciertas realizaciones, la antena 1662 puede estar separada del nodo 1660 de red y puede conectarse al nodo 1660 de red a través de una interfaz o puerto.

La antena 1662, la interfaz 1690, y/o el circuito 1670 de procesamiento pueden configurarse para realizar cualquier operación de recepción y/o ciertas operaciones de obtención descritas en la presente memoria, como realizadas por un nodo de red. Cualquier información, dato y/o señal puede recibirse de un dispositivo inalámbrico, de otro nodo de red y/o de cualquier otro equipo de red. De manera similar, la antena 1662, la interfaz 1690, y/o el circuito 1670 de procesamiento pueden configurarse para realizar cualquier operación de transmisión descrita en la presente memoria como realizada por un nodo de red. Cualquier información, dato y/o señal puede transmitirse a un dispositivo inalámbrico, a otro nodo de red y/o a cualquier otro equipo de red.

El circuito 1687 de alimentación puede comprender, o estar acoplado a, un circuito de gestión de potencia y puede configurarse para suministrar potencia a los componentes del nodo 1660 de red para realizar la funcionalidad descrita en la presente memoria. El circuito 1687 de alimentación puede recibir potencia de la fuente 1686 de alimentación. La fuente 1686 de alimentación y/o el circuito 1687 de alimentación pueden configurarse para proporcionar potencia a los diversos componentes del nodo 1660 de red en una forma adecuada para los respectivos componentes (p.ej., a un nivel de voltaje y corriente necesarios para cada componente respectivo). La fuente 1686 de alimentación puede estar incluida en, o ser externa a, el circuito 1687 de alimentación y/o al nodo 1660 de red. Por ejemplo, el nodo 1660 de red puede conectarse a una fuente de alimentación externa (p.ej., una toma de corriente) a través de un circuito de entrada o interfaz como un cable eléctrico, por lo que la fuente de alimentación externa suministra potencia al circuito 1687 de alimentación. Como un ejemplo adicional, la fuente 1686 de alimentación puede comprender una fuente de alimentación en la forma de una batería o paquete de baterías que está conectado a, o integrado en, el circuito 1687 de alimentación. La batería puede proporcionar potencia de respaldo en caso de que falle la fuente de alimentación externa. También pueden utilizarse otros tipos de fuentes de alimentación, como dispositivos fotovoltaicos.

Realizaciones alternativas del nodo 1660 de red pueden incluir componentes adicionales más allá de los mostrados en la Figura 16 que pueden ser responsables de proporcionar ciertos aspectos de la funcionalidad del nodo de red, incluida cualquiera de las funciones descritas en la presente memoria y/o cualquier funcionalidad necesaria para respaldar el tema en cuestión descrito en la presente memoria. Por ejemplo, el nodo 1660 de red puede incluir un equipo de interfaz de usuario para permitir y/o facilitar la entrada de información en el nodo 1660 de red y para permitir y/o facilitar la salida de información desde el nodo 1660 de red. Esto puede permitir y/o facilitar que un usuario realice diagnóstico, mantenimiento, reparación, y otras funciones administrativas para el nodo 1660 de red.

En algunas realizaciones, un dispositivo inalámbrico (WD, p.ej., WD 1610) puede configurarse para transmitir y/o recibir información sin interacción humana directa. Por ejemplo, un WD puede diseñarse para transmitir información a una red en un horario predeterminado, cuando se activa por un evento interno o externo, o en respuesta a solicitudes de la red. Ejemplos de WD incluyen, pero no se limitan a, teléfonos inteligentes, teléfonos móviles, teléfonos celulares, teléfonos de voz sobre IP (VoIP), teléfonos inalámbricos de bucle local, ordenadores de escritorio, asistentes digitales personales (PDAs), cámaras inalámbricas, consolas o dispositivos de juego, dispositivos de almacenamiento de música, aparatos de reproducción, dispositivos portátiles, puntos finales inalámbricos, estaciones móviles, tabletas, ordenadores portátiles, equipos integrados en ordenadores portátiles (LEE), equipos montados en ordenadores portátiles (LME), dispositivos inteligentes, equipos inalámbricos en las instalaciones del cliente (CPE), dispositivos de comunicación de tipo móvil (MTC), dispositivos del Internet de las Cosas (IoT), dispositivos terminales inalámbricos montados en vehículos, etc.

Un WD puede admitir comunicación de dispositivo a dispositivo (D2D), por ejemplo, implementando un estándar del 3GPP para comunicación de enlace lateral, vehículo a vehículo (V2V), vehículo a infraestructura (V2I), vehículo a todo (V2X) y en este caso puede denominarse dispositivo de comunicación D2D. Como otro ejemplo específico, en un escenario del Internet de las Cosas (IoT), un WD puede representar una máquina u otro dispositivo que realiza monitorización y/o medidas y transmite los resultados de dicho monitorización y/o medidas a otro WD y/o a un nodo de red. En este caso, el WD puede ser un dispositivo de máquina a máquina (M2M), que en un contexto del 3GPP puede denominarse dispositivo MTC. Como un ejemplo particular, el WD puede ser un UE que implementa el estándar del internet de las cosas de banda estrecha (NB-IoT) del 3GPP. Ejemplos particulares de dichas máquinas o dispositivos son sensores, dispositivos de medida como medidores de potencia, maquinaria industrial, o electrodomésticos o aparatos personales (p. ej., frigoríficos, televisores, etc.) accesorios personales (p.ej., relojes, rastreadores de actividad física, etc.). En otros escenarios, un WD puede representar un vehículo u otro equipo que es capaz de monitorizar y/o reportar sobre su estado operativo u otras funciones asociadas con su funcionamiento. Un WD como se describe anteriormente puede representar el extremo de una conexión inalámbrica, en cuyo caso el dispositivo puede denominarse terminal inalámbrico. Además, un WD como se describe anteriormente puede ser móvil, en cuyo caso también puede denominarse dispositivo móvil o terminal móvil.

Como se ilustra, un dispositivo inalámbrico 1610 incluye una antena 1611, una interfaz 1614, un circuito 1620 de procesamiento, un medio 1630 legible por dispositivo, un equipo 1632 de interfaz de usuario, un equipo auxiliar 1634, una fuente 1636 de alimentación y un circuito 1637 de alimentación. El WD 1610 puede incluir múltiples conjuntos de uno o más de los componentes ilustrados para diferentes tecnologías inalámbricas compatibles con el WD 1610, como, por ejemplo, tecnologías inalámbricas GSM, WCDMA, LTE, NR, WiFi, WiMAX, o Bluetooth, solo por mencionar algunas. Estas tecnologías inalámbricas pueden integrarse en los mismos o diferentes chips o conjuntos de chips que otros componentes dentro del WD 1610.

La antena 1611 puede incluir una o más antenas, o conjuntos de antenas, configuradas para enviar y/o recibir señales inalámbricas, y está conectada a la interfaz 1614. En ciertas realizaciones alternativas, la antena 1611 puede estar separada del WD 1610 y conectarse al WD 1610 a través de un interfaz o puerto. La antena 1611, la interfaz 1614, y/o el circuito 1620 de procesamiento pueden configurarse para realizar cualquier operación de recepción o transmisión descrita en la presente memoria como realizada por un WD. Cualquier información, dato y/o señal puede recibirse de un nodo de red y/o de otro WD. En algunas realizaciones, el circuito de la interfaz radio y/o la antena 1611 pueden considerarse una interfaz.

Como se ilustra, la interfaz 1614 comprende un circuito 1612 de la interfaz radio y una antena 1611. El circuito 1612 de la interfaz radio comprende uno o más filtros 1618 y amplificadores 1616. El circuito 1614 de la interfaz radio está conectado a la antena 1611 y al circuito 1620 de procesamiento y puede configurarse para acondicionar señales comunicadas entre la antena 1611 y el circuito 1620 de procesamiento. El circuito 1612 de la interfaz radio puede acoplarse a, o ser una parte de, la antena 1611. En algunas realizaciones, el WD 1610 puede no incluir un circuito 1612 de la interfaz radio separado; más bien, el circuito 1620 de procesamiento puede comprender un circuito de la interfaz radio y puede conectarse a la antena 1611. De manera similar, en algunas realizaciones, parte o todo el circuito 1622 transceptor de RF puede considerarse una parte de la interfaz 1614. El circuito 1612 de la interfaz radio puede recibir datos digitales que se enviarán a otros nodos de red o WDs a través de una conexión inalámbrica. El circuito 1612 de la interfaz radio puede convertir los datos digitales en una señal de radio que tenga los parámetros de canal y ancho de banda apropiados, utilizando una combinación de filtros 1618 y/o amplificadores 1616. La señal de radio puede entonces transmitirse a través de la antena 1611. De manera similar, al recibir datos, la antena 1611 puede recopilar señales de radio que luego son convertidas en datos digitales por el circuito 1612 de la interfaz radio. Los datos digitales pueden pasarse al circuito 1620 de procesamiento. En otras realizaciones, la interfaz puede comprender diferentes componentes y/o diferentes combinaciones de componentes.

El circuito 1620 de procesamiento puede comprender una combinación de uno o más de un microprocesador, controlador, microcontrolador, unidad central de procesamiento, procesador de señales digitales, circuito integrado de aplicación específica, matriz de puertas lógicas programable en campo, o cualquier otro dispositivo informático adecuado, recurso, o combinación de hardware, software, y/o lógica codificada operable para proporcionar la funcionalidad del WD 1610 solo o en combinación con otros componentes del WD 1610, como el medio 1630 legible por dispositivo. Dicha funcionalidad puede incluir cualquiera de las diversas características o beneficios inalámbricos discutidos en la presente memoria.

Por ejemplo, el circuito 1620 de procesamiento puede ejecutar instrucciones almacenadas en el medio 1630 legible por dispositivo o en la memoria dentro del circuito 1620 de procesamiento para proporcionar la funcionalidad descrita en la presente memoria. Más específicamente, las instrucciones (también denominadas producto de programa informático) almacenadas en el medio 1630 pueden incluir instrucciones que, cuando son ejecutadas por el procesador 1620, pueden configurar el dispositivo inalámbrico 1610 para realizar operaciones correspondientes a varios métodos ejemplares (p. ej., procedimientos) descritos en la presente memoria.

Como se ilustra, el circuito 1620 de procesamiento incluye uno o más de un circuito 1622 transceptor de RF, un circuito 1624 de procesamiento de banda base, y un circuito 1626 de procesamiento de aplicaciones. En otras realizaciones, el circuito de procesamiento puede comprender diferentes componentes y/o diferentes combinaciones de componentes. En ciertas realizaciones, el circuito 1620 de procesamiento del WD 1610 puede comprender un SOC. En algunas realizaciones, el circuito 1622 transceptor de RF, el circuito 1624 de procesamiento de banda base, y el circuito 1626 de procesamiento de aplicaciones pueden estar en chips o conjuntos de chips separados. En realizaciones alternativas, parte o todo el circuito 1624 de procesamiento de banda base y el circuito 1626 de procesamiento de aplicaciones pueden combinarse en un chip o conjunto de chips, y el circuito 1622 transceptor de RF puede estar en un chip o conjunto de chips separado. En aún realizaciones alternativas, parte o todo el circuito 1622 transceptor de RF y el circuito 1624 de procesamiento de banda base pueden estar en el mismo chip o conjunto de chips, y el circuito 1626 de procesamiento de aplicaciones puede estar en un chip o conjunto de chips separado. En aún otras realizaciones alternativas, parte o todo el circuito 1622 transceptora de RF, el circuito 1624 de procesamiento de banda base, y el circuito 1626 de procesamiento de aplicaciones pueden combinarse en el mismo chip o conjunto de chips. En algunas realizaciones, el circuito 1622 transceptor de RF puede ser una parte de la interfaz 1614. El circuito 1622 transceptor de RF puede acondicionar señales de RF para el circuito 1620 de procesamiento.

En ciertas realizaciones, parte o toda la funcionalidad descrita en la presente memoria como realizada por un WD puede ser proporcionada por el circuito 1620 de procesamiento que ejecuta instrucciones almacenadas en el medio 1630 legible por dispositivo, que en ciertas realizaciones puede ser un medio de almacenamiento legible por ordenador. En realizaciones alternativas, parte o toda la funcionalidad puede ser proporcionada por el circuito 1620 de procesamiento sin ejecutar instrucciones almacenadas en un medio de almacenamiento legible por dispositivo separado o discreto, como de manera cableada. En cualquiera de esas realizaciones en particular, ya sea ejecutando instrucciones almacenadas en un medio de almacenamiento legible por dispositivo o no, el circuito 1620 de procesamiento puede configurarse para realizar la funcionalidad descrita. Los beneficios proporcionados por dicha funcionalidad no se limitan al circuito 1620 procesamiento solo o a otros componentes del WD 1610, sino que los disfruta el WD 1610 en su conjunto, y/o los usuarios finales y la red inalámbrica en general.

El circuito 1620 de procesamiento puede configurarse para realizar cualquier operación de determinación, cálculo, o similar (p. ej., ciertas operaciones de obtención) descritas en la presente memoria como realizadas por un WD. Estas operaciones, tal como las realiza el circuito 1620 de procesamiento, pueden incluir el procesamiento de información obtenida por el circuito 1620 de procesamiento, por ejemplo, convirtiendo la información obtenida en otra información, comparando la información obtenida o información convertida con información almacenada en el nodo de red, y/o realizando una o más operaciones en función de la información obtenida o información convertida, y como resultado de dicho procesamiento, tomar una determinación.

El medio 1630 legible por dispositivo puede operarse para almacenar un programa informático, software, una aplicación que incluye uno o más de lógica, reglas, código, tablas, etc. y/u otras instrucciones capaces de ser ejecutadas por el circuito 1620 de procesamiento. El medio 1630 legible por dispositivo puede incluir una memoria de ordenador (p.ej., Memoria de Acceso Aleatorio (RAM) o Memoria de Solo Lectura (ROM)), un medio de almacenamiento masivo (p.ej., un disco duro), un medio de almacenamiento extraíble (p.ej., 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 dispositivo y/o ejecutable por ordenador que almacena información, datos, y/o instrucciones que pueden ser utilizadas por el circuito 1620 de procesamiento. En algunas realizaciones, el circuito 1620 de procesamiento y el medio 1630 legible por dispositivo pueden considerarse integrados.

El equipo 1632 de interfaz de usuario puede incluir componentes que permiten y/o facilitan que un usuario humano interactúe con el WD 1610. Dicha interacción puede ser de muchas formas, como visual, auditiva, táctil, etc. El equipo 1632 de interfaz de usuario puede operarse para generar una salida para el usuario y permitir y/o facilitar que el usuario proporcione una entrada al WD 1610. El tipo de interacción puede variar dependiendo del tipo de equipo 1632 de interfaz de usuario instalado en el WD 1610. Para ejemplo, si WD 1610 es un teléfono inteligente, la interacción puede ser a través de una pantalla táctil; si WD 1610 es un medidor inteligente, la interacción puede ser a través de una pantalla que proporciona el uso (p.ej., la cantidad de galones utilizados) o un altavoz que proporciona una alerta audible (p.ej., si se detecta humo). El equipo 1632 de interfaz de usuario puede incluir interfaces, dispositivos y circuitos de entrada, e interfaces, dispositivos y circuitos de salida. El equipo 1632 de interfaz de usuario puede configurarse para permitir y/o facilitar la entrada de información en el WD 1610 y está conectado al circuito 1620 de procesamiento para permitir y/o facilitar que el circuito 1620 de procesamiento procese la información de entrada. El equipo 1632 de interfaz de usuario puede incluir, por ejemplo, un micrófono, un sensor de proximidad u otro, teclas/botones, una pantalla táctil, una o más cámaras, un puerto USB, u otro circuito de entrada. El equipo 1632 de interfaz de usuario también está configurado para permitir y/o facilitar la salida de información desde WD 1610, y para permitir y/o facilitar que el circuito 1620 de procesamiento envíe información desde el WD 1610. El equipo 1632 de interfaz de usuario puede incluir, por ejemplo, un altavoz, una pantalla, un circuito vibratorio, un puerto USB, una interfaz de auriculares, u otro circuito de salida. Utilizando una o más interfaces, dispositivos y circuitos de entrada y salida, del equipo 1632 de interfaz de usuario, el WD 1610 puede comunicarse con los usuarios finales y/o la red inalámbrica y permitirles y/o facilitarles el beneficio de la funcionalidad descrita en la presente memoria.

El equipo auxiliar 1634 es operable para proporcionar una funcionalidad más específica que generalmente no pueden realizar los WDs. Esto puede comprender sensores especializados para realizar medidas para diversos fines, interfaces para tipos adicionales de comunicación, como comunicaciones por cable, etc. La inclusión y el tipo de componentes del equipo auxiliar 1634 pueden variar dependiendo de la realización y/o el escenario.

La fuente 1636 de alimentación puede, en algunas realizaciones, tener la forma de una batería o paquete de baterías. También pueden utilizarse otros tipos de fuentes de alimentación, como una fuente de alimentación externa (p. ej., una toma de corriente), dispositivos fotovoltaicos o celdas de potencia. El WD 1610 puede comprender además un circuito 1637 de alimentación para suministrar potencia desde la fuente 1636 de alimentación a las distintas partes del WD 1610 que necesitan potencia de la fuente 1636 de alimentación para llevar a cabo cualquier funcionalidad descrita o indicada en la presente memoria. El circuito 1637 de alimentación puede comprender en ciertas realizaciones un circuito de gestión de potencia. El circuito 1637 de alimentación puede operarse, adicional o alternativamente, para recibir potencia de una fuente de alimentación externa; en cuyo caso, el WD 1610 puede conectarse a una fuente de alimentación externa (como una toma de corriente) a través de un circuito de entrada o una interfaz como un cable de alimentación eléctrica. El circuito 1637 de alimentación también puede, en ciertas realizaciones, operarse para entregar potencia desde una fuente de alimentación externa a la fuente 1636 de alimentación. Esto puede ser, por ejemplo, para la carga de la fuente 1636 de alimentación. El circuito 1637 de alimentación puede realizar cualquier conversión u otra modificación a la potencia de la fuente 1636 de alimentación para que sea adecuada para el suministro a los componentes respectivos del WD 1610.

La Figura 17 ilustra una realización de un UE de acuerdo con varios aspectos descritos en la presente memoria. Como se utiliza en la presente memoria, un equipo de usuario o UE puede no tener, necesariamente, un usuario en el sentido de un usuario humano que posee y/u opera el dispositivo relevante. En cambio, un UE puede representar un dispositivo que está destinado para la venta a, o la operación por parte de, un usuario humano, pero que no puede, o que inicialmente no puede, estar asociado con un usuario humano específico (p.ej., un controlador de riego inteligente). Alternativamente, un UE puede representar un dispositivo que no está destinado para la venta a, ni para la operación por parte de, un usuario final, pero que puede asociarse u operarse en beneficio de un usuario (p.ej., un medidor de potencia inteligente). El UE 17200 puede ser cualquier UE identificado por el Proyecto de Asociación de 3a Generación (3GPP), que incluye un UE NB-IoT, un UE de comunicación de tipo máquina (MTC), y/o un UE MTC mejorado (eMTC). El UE 1700, como se ilustra en la Figura 17, es un ejemplo de un WD configurado para la comunicación de acuerdo con uno o más estándares de comunicación promulgados por el Proyecto de Asociación de 3a Generación (3GPP), como los estándares GSM, UMTS, LTE, y/o 5G del 3GPP. Como se mencionó anteriormente, los términos WD y UE pueden utilizarse de forma intercambiable. En consecuencia, aunque la Figura 17 es un UE, los componentes discutidos en la presente memoria son igualmente aplicables a un WD, y viceversa.

En la Figura 17, el UE 1700 incluye un circuito 1701 de procesamiento que está acoplado operativamente a la interfaz 1705 de entrada/salida, la interfaz 1709 de radiofrecuencia (RF), la interfaz 1711 de conexión de red, la memoria 1715 que incluye la memoria 1717 de acceso aleatorio (RAM), la memoria 1719 de solo lectura (ROM), y el medio 1721 de almacenamiento o similar, el subsistema 1731 de comunicación, la fuente 1733 de alimentación, y/o cualquier otro componente, o cualquier combinación de los mismos. El medio 1721 de almacenamiento incluye el sistema operativo 1723, el programa 1725 de aplicación, y los datos 1727. En otras realizaciones, el medio 1721 de almacenamiento puede incluir otros tipos similares de información. Ciertos UEs pueden utilizar todos los componentes mostrados en la Figura 17, o solo un subconjunto de los componentes. El nivel de integración entre los componentes puede variar de un UE a otro UE. Además, ciertos UEs pueden contener múltiples instancias de un componente, como múltiples procesadores, memorias, transceptores, transmisores, receptores, etc.

En la Figura 17, el circuito 1701 de procesamiento puede configurarse para procesar instrucciones y datos informáticos. El circuito 1701 de procesamiento puede configurarse para implementar cualquier máquina de estados secuencial operativa para ejecutar instrucciones de máquina almacenadas como programas informáticos legibles por máquina en la memoria, como una o más máquinas de estado implementadas en hardware (p. ej., en lógica discreta, FPGA, ASIC, etc.); lógica programable junto con el firmware apropiado; uno o más programas almacenados, procesadores de propósito general, como un microprocesador o un Procesador de Señales Digitales (DSP), junto con el software apropiado; o cualquier combinación de los anteriores. Por ejemplo, el circuito 1701 de procesamiento puede incluir dos unidades centrales de procesamiento (CPUs). Los datos pueden ser información en una forma adecuada para su uso por parte de un ordenador.

En la realización representada, la interfaz 1705 de entrada/salida puede configurarse para proporcionar una interfaz de comunicación a un dispositivo de entrada, un dispositivo de salida, o un dispositivo de entrada y salida. El UE 1700 puede configurarse para utilizar un dispositivo de salida a través de la interfaz 1705 de entrada/salida. Un dispositivo de salida puede utilizar el mismo tipo de puerto de interfaz que un dispositivo de entrada. Por ejemplo, puede utilizarse un puerto USB para proporcionar entrada a y salida desde el UE 1700. El dispositivo de salida puede ser un altavoz, una tarjeta de sonido, una tarjeta de video, una pantalla, un monitor, una impresora, un actuador, un emisor, una tarjeta inteligente, otro dispositivo de salida, o cualquier combinación de los mismos. El UE 1700 puede configurarse para utilizar un dispositivo de entrada a través de la interfaz 1705 de entrada/salida para permitir y/o facilitar que un usuario capture información en el UE 1700. El dispositivo de entrada puede incluir una pantalla sensible al tacto o sensible a la presencia, una cámara (p.ej., una cámara digital, una cámara de vídeo digital, una cámara web, etc.), un micrófono, un sensor, un ratón, una bola de seguimiento, un control direccional, una pista de contacto, una rueda de desplazamiento, una tarjeta inteligente y similares. La pantalla sensible a la presencia puede incluir un sensor táctil capacitivo o resistivo para detectar la entrada de un usuario. Un sensor puede ser, por ejemplo, un acelerómetro, un giroscopio, un sensor de inclinación, un sensor de fuerza, un magnetómetro, un sensor óptico, un sensor de proximidad, otro sensor similar, o cualquier combinación de los mismos. Por ejemplo, el dispositivo de entrada puede ser un acelerómetro, un magnetómetro, una cámara digital, un micrófono, y un sensor óptico.

En la Figura 17, la interfaz 1709 de RF puede configurarse para proporcionar una interfaz de comunicación a los componentes de RF, como un transmisor, un receptor, y una antena. La interfaz 1711 de conexión de red puede configurarse para proporcionar una interfaz de comunicación a la red 1743a. La red 1743a puede abarcar redes por cable y/o inalámbricas, como una red de área local (LAN), una red de área amplia (WAN), una red informática, una red inalámbrica, una red de telecomunicaciones, otra red similar o cualquier combinación de las mismas. Por ejemplo, la red 1743a puede comprender una red Wi-Fi. La interfaz 1711 de conexión de red puede configurarse para incluir una interfaz de un receptor y un transmisor utilizada para comunicarse con uno o más dispositivos a través de una red de comunicación según uno o más protocolos de comunicación, como Ethernet, TCP/IP, SONET, ATM, o similares. La interfaz 1711 de conexión de red puede implementar una funcionalidad de receptor y transmisor apropiada para los enlaces de la red de comunicación (p.ej., ópticos, eléctricos, y similares). Las funciones del transmisor y del receptor pueden compartir componentes de circuito, software o firmware, o alternativamente pueden implementarse por separado.

La RAM 1717 puede configurarse para interactuar a través del bus 1702 con el circuito 1701 de procesamiento para proporcionar almacenamiento o almacenamiento en caché de datos o instrucciones informáticas durante la ejecución de programas software como el sistema operativo, programas de aplicación, y controladores de dispositivos. La ROM 1719 puede configurarse para proporcionar instrucciones o datos informáticos al circuito 1701 de procesamiento. Por ejemplo, la ROM 1719 puede configurarse para almacenar código del sistema de bajo nivel invariable o datos para funciones básicas del sistema, como entrada y salida (E/S) básica, inicio, o recepción de pulsaciones de teclas de un teclado que se almacenan en una memoria no volátil. El medio 1721 de almacenamiento puede configurarse para incluir memoria como RAM, ROM, memoria de solo lectura programable (PROM), memoria de solo lectura programable y borrable (EPROM), memoria de solo lectura programable y borrable eléctricamente (EEPROM), discos magnéticos, discos ópticos, disquetes, discos duros, cartuchos extraíbles, o unidades flash.

En un ejemplo, el medio 1721 de almacenamiento puede configurarse para incluir el sistema operativo 1723; el programa 1725 de aplicación, como una aplicación del navegador web, un widget o motor de gadget u otra aplicación; y el archivo 1727 de datos. El medio 1721 de almacenamiento puede almacenar, para uso del UE 1700, cualquiera de una variedad de diversos sistemas operativos o combinaciones de sistemas operativos. Por ejemplo, el programa 1725 de aplicación puede incluir instrucciones del programa ejecutables (también denominadas producto de programas informático) que, cuando las ejecuta el procesador 1701, pueden configurar el UE 1700 para realizar operaciones correspondientes a varios métodos ejemplares (p. ej., procedimientos) descritos en la presente memoria.

El medio 1721 de almacenamiento puede configurarse para incluir varias unidades de disco físico, como una matriz redundante de discos independientes (RAID), unidad de disquete, memoria flash, unidad flash USB, unidad de disco duro externa, memoria USB, pendrive, llave, unidad de disco óptico de disco versátil digital de alta densidad (HD-DVD), unidad de disco duro interna, unidad de disco óptico Blu-Ray, unidad de disco óptico de almacenamiento de datos digitales holográficos (HDDS), módulo de memoria en línea mini-dual externo (DIMM), memoria de acceso aleatorio dinámica síncrona (SDRAM), SDRAM micro-DIMM externa, memoria de tarjeta inteligente como un módulo de identidad del abonado o un módulo de identidad del usuario extraíble (SIM/RUIM), otra memoria, o cualquier combinación de las mismas. El medio 1721 de almacenamiento puede permitir y/o facilitar que el UE 1700 acceda a instrucciones ejecutables por ordenador, programas de aplicación o similares, almacenados en medios de memoria transitoria o no transitoria, para descargar datos, o para cargar datos. Un artículo de fabricación, como uno que utiliza un sistema de comunicación, puede incorporarse de manera tangible en el medio 1721 de almacenamiento, que puede comprender un medio legible por dispositivo.

En la Figura 17, el circuito 1701 de procesamiento puede configurarse para comunicarse con la red 1743b utilizando el subsistema 1731 de comunicación. La red 1743a y la red 1743b pueden ser la misma red o redes o diferente red o redes. El subsistema 1731 de comunicación puede configurarse para incluir uno o más transceptores utilizados para comunicarse con la red 1743b. Por ejemplo, el subsistema 1731 de comunicación puede configurarse para incluir uno o más transceptores utilizados para comunicarse con uno o más transceptores remotos de otro dispositivo con capacidad de comunicación inalámbrica, como otro WD, UE, o estación base de una red de acceso por radio (RAN) según a uno o más protocolos de comunicación, como ⁱE^e E 802.17, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, o similares. Cada transceptor puede incluir un transmisor 1733 y/o un receptor 1735 para implementar la funcionalidad del transmisor o receptor, respectivamente, apropiada para los enlaces RAN (p. ej., asignaciones de frecuencia y similares). Además, el transmisor 1733 y el receptor 1735 de cada transceptor pueden compartir componentes de circuito, software o firmware, o alternativamente pueden implementarse por separado.

En la realización ilustrada, las funciones de comunicación del subsistema 1731 de comunicación pueden incluir comunicación de datos, comunicación de voz, comunicación multimedia, comunicaciones de corto alcance como Bluetooth, comunicación de campo cercano, comunicación basada en la ubicación como el uso del sistema de posicionamiento global (GPS) para determinar una ubicación, otra función de comunicación similar, o cualquier combinación de las mismas. Por ejemplo, el subsistema 1731 de comunicación puede incluir comunicación celular, comunicación Wi-Fi, comunicación Bluetooth, y comunicación GPS. La red 1743b puede abarcar redes por cable y/o inalámbricas, como una red de área local (LAN), una red de área amplia (WAN), una red informática, una red inalámbrica, una red de telecomunicaciones, otra red similar o cualquier combinación de las mismas. Por ejemplo, la red 1743b puede ser una red celular, una red Wi-Fi, y/o una red de campo cercano. La fuente 1713 de alimentación puede configurarse para proporcionar potencia de corriente alterna (CA) o corriente continua (CC) a los componentes del UE 1700.

Las características, beneficios y/o funciones descritas en la presente memoria pueden implementarse en uno de los componentes del UE 1700 o dividirse en múltiples componentes del UE 1700. Además, las características, beneficios, y/o funciones descritas en la presente memoria pueden implementarse en cualquier combinación de hardware, software o firmware. En un ejemplo, el subsistema 1731 de comunicación puede configurarse para incluir cualquiera de los componentes descritos en la presente memoria. Además, el circuito 1701 de procesamiento puede configurarse para comunicarse con cualquiera de dichos componentes a través del bus 1702. En otro ejemplo, cualquiera de dichos componentes puede representarse mediante instrucciones de programa almacenadas en memoria que, cuando son ejecutadas por el circuito 1701 de procesamiento, realizan las funciones correspondientes descritas en la presente memoria. En otro ejemplo, la funcionalidad de cualquiera de dichos componentes puede dividirse entre el circuito 1701 de procesamiento y el subsistema 1731 de comunicación. En otro ejemplo, las funciones computacionalmente no intensivas de cualquiera de dichos componentes pueden implementarse en software o firmware y las funciones computacionalmente intensivas pueden implementarse en hardware.

La Figura 18 es un diagrama de bloques esquemático que ilustra un entorno 1800 de virtualización en el que pueden virtualizarse las funciones implementadas por algunas realizaciones. En el presente contexto, virtualizar significa crear versiones virtuales de aparatos o dispositivos que pueden incluir la virtualización de plataformas hardware, dispositivos de almacenamiento y recursos de red. Como se utiliza en la presente memoria, la virtualización puede aplicarse a un nodo (p.ej., una estación base virtualizada o un nodo de acceso por radio virtualizado) o a un dispositivo (p.ej., un UE, un dispositivo inalámbrico o cualquier otro tipo de dispositivo de comunicación) o a componentes de los mismos, 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 (p.ej., 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 la presente memoria pueden implementarse como componentes virtuales ejecutados por una o más máquinas virtuales implementadas en uno o más entornos virtuales 1800 alojados por uno o más nodos 1830 de hardware. Además, en realizaciones en las que el nodo virtual no es un nodo de acceso por radio o no requiere conectividad de radio (p.ej., 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 1820 (que alternativamente pueden denominarse instancias de software, dispositivos virtuales, funciones de red, nodos virtuales, funciones de red virtual, etc.) operativas para implementar algunas de las características, funciones, y/o beneficios de algunas de las realizaciones descritas en la presente memoria. Las aplicaciones 1820 se ejecutan en el entorno 1800 de virtualización que proporciona el hardware 1830 que comprende el circuito 1860 de procesamiento y la memoria 1890. La memoria 1890 contiene las instrucciones 1895 ejecutables por el circuito 1860 de procesamiento, mediante el cual la aplicación 1820 está operativa para proporcionar una o más de las características, beneficios, y/o funciones descritas en la presente memoria.

El entorno 1800 de virtualización puede incluir dispositivos (o nodos) 1830 de hardware de red de propósito general o de propósito especial que comprenden un conjunto de uno o más procesadores o circuitos 1860 de procesamiento, que pueden ser procesadores disponibles comercialmente (COTS), Circuitos Integrados de Aplicación Específica (ASICs) dedicados, o cualquier otro tipo de circuito de procesamiento, que incluye componentes hardware digitales o analógicos o procesadores de propósito especial. Cada dispositivo de hardware puede comprender una memoria 1890-1 que puede ser una memoria no persistente para almacenar temporalmente las instrucciones 1895 o el software ejecutado por el circuito 1860 de procesamiento. Por ejemplo, las instrucciones 1895 pueden incluir instrucciones de programa (también conocidas como producto de programa informático) que, cuando son ejecutadas por el circuito 1860 de procesamiento, puede configurar el nodo 1820 de hardware para realizar operaciones correspondientes a varios métodos ejemplares (p. ej., procedimientos) descritos en la presente memoria. Dichas operaciones también pueden atribuirse a el(los) nodo(s) virtual(es) 1820 que está(n) alojado(s) por parte del nodo 1830 de hardware.

Cada dispositivo de hardware puede comprender uno o más controladores 1870 de interfaz de red (NICs), también conocidos como tarjetas de interfaz de red, que incluyen una interfaz 1880 de red física. Cada dispositivo de hardware también puede incluir un medio 1890-2 de almacenamiento no transitorio, persistente y legible por máquina que tiene almacenado en él el software 1895 y/o las instrucciones ejecutables por el circuito 1860 de procesamiento. El software 1895 puede incluir cualquier tipo de software, incluido software para instanciar una o más capas 1850 de virtualización (también denominadas hipervisores), software para ejecutar máquinas virtuales 1840 así como software que le permita ejecutar funciones, características y/o beneficios descritos en relación con algunas realizaciones descritas en la presente memoria.

Las máquinas virtuales 1840 comprenden procesamiento virtual, memoria virtual, red o interfaz virtual y almacenamiento virtual, y pueden ser ejecutadas por una capa 1850 de virtualización o hipervisor correspondiente. Pueden implementarse diferentes realizaciones de la instancia del dispositivo virtual 1820 en una o más máquinas virtuales 1840, y las implementaciones pueden realizarse de diferentes maneras.

Durante la operación, el circuito 1860 de procesamiento ejecuta el software 1895 para instanciar el hipervisor o capa 1850 de virtualización, que a veces puede denominarse como monitor de máquina virtual (VMM). La capa 1850 de virtualización puede presentar una plataforma operativa virtual que aparece como hardware de red para la máquina virtual 1840.

Como se muestra en la Figura 18, el hardware 1830 puede ser un nodo de red independiente con componentes genéricos o específicos. El hardware 1830 puede comprender una antena 18225 y puede implementar algunas funciones a través de la virtualización. Alternativamente, el hardware 1830 puede ser parte de un grupo más grande de hardware (p.ej., como en un centro de datos o equipo en las instalaciones del cliente (CPE)) donde muchos nodos de hardware trabajan juntos y se gestionan a través de gestión y orquestación (MANO) 18100, que, entre otros, supervisa la gestión del ciclo de vida de las aplicaciones 1820.

La virtualización del hardware se denomina en algunos contextos virtualización de funciones de red (NFV). NFV puede utilizarse 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 pueden ubicarse en centros de datos, y equipos en las instalaciones del cliente.

En el contexto de NFV, la máquina virtual 1840 puede ser una implementación 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 1840, y esa parte de hardware 1830 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 1840, forma un elemento de red virtual separado (V.N.E.).

Todavía 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 1840 sobre la infraestructura 1830 de red de hardware y corresponde a la aplicación 1820 en la Figura 18.

En algunas realizaciones, una o más unidades 18200 de radio que incluyen uno o más transmisores 18220 y uno o más receptores 18210 pueden acoplarse a una o más antenas 18225. Las unidades 18200 de radio pueden comunicarse, directamente, con los nodos 1830 de hardware a través de una o más interfaces de red apropiadas y puede utilizarse en combinación con los componentes virtuales para proporcionar un nodo virtual con capacidades de radio, como un nodo de acceso por radio o una estación base. Los nodos dispuestos de esta manera también pueden comunicarse con uno o más UEs, como se describe en otra parte en la presente memoria.

En algunas realizaciones, alguna señalización puede realizarse a través del sistema 18230 de control, que alternativamente puede utilizarse para la comunicación entre los nodos 1830 de hardware y las unidades 18200 de radio.

Con referencia a la Figura 19, de acuerdo con una realización, un sistema de comunicación incluye una red 1910 de telecomunicación, como una red celular tipo del 3GPP, que comprende una red 1911 de acceso, como una red de acceso por radio, y una red central 1914. La red de 1911 acceso comprende una pluralidad de estaciones base 1912a, 1912b, 1912c, como NBs, eNBs, gNBs u otros tipos de puntos de acceso inalámbricos, cada uno definiendo un área 1913a, 1913b, 1913c de cobertura correspondiente. Cada estación base 1912a, 1912b, 1912c puede conectarse a la red central 1914 a través de una conexión 1915 por cable o inalámbrica. Un primer UE 1991 ubicado en el área 1913c de cobertura puede configurarse para conectarse de forma inalámbrica a, o ser buscado por, la correspondiente estación base 1912c. Un segundo UE 1992 en el área 1913a de cobertura puede conectarse de forma inalámbrica a la correspondiente estación base 1912a. Si bien en este ejemplo se ilustran una pluralidad de UEs 1991, 1992, las realizaciones descritas son igualmente aplicables a una situación en la que un único UE se encuentra en el área de cobertura o en la que un único UE está conectado.

La propia red 1910 de telecomunicación se conecta al ordenador central 1930, que puede incorporarse en el hardware y/o software de un servidor independiente, un servidor implementado en la nube, un servidor distribuido o como recursos de procesamiento en una granja de servidores. El ordenador central 1930 puede estar bajo la propiedad o el control de un proveedor de servicios o puede ser operado por el proveedor de servicios o en nombre del proveedor de servicios. Las conexiones 1921 y 1922 entre la red 1910 de telecomunicación y el ordenador central 1930 pueden extenderse directamente desde la red central 1914 al ordenador central 1930 o pueden ir a través de una red intermedia 1920 opcional. La red intermedia 1920 puede ser una de, o una combinación de más de una de, una red pública, privada o alojada; la red intermedia 1920, si la hay, puede ser una red troncal o Internet; en particular, la red intermedia 1920 puede comprender dos o más subredes (no mostradas).

El sistema de comunicación de la Figura 19 como un todo permite la conectividad entre los UEs 1991,1992 conectados y el ordenador central 1930. La conectividad puede describirse como una conexión over-the-top (OTT) 1950. El ordenador central 1930 y los UEs 1991,1992 conectados se configuran para comunicar datos y/o señalización a través de la conexión OTT 1950, utilizando la red 1911 de acceso, la red central 1914, cualquier red intermedia 1920 y posible infraestructura adicional (no mostrada) como intermediarios. La conexión OTT 1950 puede ser transparente en el sentido de que los dispositivos de comunicación participantes a través de los cuales pasa la conexión OTT 1950 no son conscientes del enrutamiento de las comunicaciones del enlace ascendente y del enlace descendente. Por ejemplo, la estación base 1912 puede no, o no necesita, ser informada sobre el enrutamiento pasado de una comunicación del enlace descendente entrante con datos que se originan en el ordenador central 1930 para ser reenviados (p. ej., entregados) a un UE 1991 conectado. De manera similar, la estación base 1912 no necesita ser consciente del enrutamiento futuro de una comunicación del enlace ascendente saliente que se origina en el UE 1991 hacia el ordenador central 1930.

Las implementaciones de ejemplo, de acuerdo con una realización, del UE, la estación base y el ordenador central discutidas en los párrafos anteriores se describirán ahora con referencia a la Figura 20. En el sistema 2000 de comunicación, el ordenador central 2010 comprende un hardware 2015 que incluye una interfaz 2016 de comunicación configurada para establecer y mantener una conexión por cable o inalámbrica con una interfaz de un dispositivo de comunicación diferente del sistema 2000 de comunicación. El ordenador central 2010 comprende además un circuito 2018 de procesamiento, que puede tener capacidades de almacenamiento y/o procesamiento. En particular, el circuito 2018 de procesamiento puede comprender uno o más procesadores programables, circuitos integrados de aplicación específica, matrices de puertas lógicas programables en campo o combinaciones de estos (no mostrados) adaptados para ejecutar instrucciones. El ordenador central 2010 comprende además un software 2011, que se almacena en, o es accesible por, el ordenador central 2010 y puede ser ejecutado por el circuito 2018 de procesamiento. El software 2011 incluye una aplicación central 2012. La aplicación central 2012 puede operarse para proporcionar un servicio a un usuario remoto, como el UE 2030 que se conecta a través de la conexión OTT 2050 que termina en el UE 2030 y el ordenador central 2010. Al proporcionar el servicio al usuario remoto, la aplicación central 2012 puede proporcionar datos del usuario que se transmiten utilizando la conexión OTT 2050.

El sistema 2000 de comunicación también puede incluir una estación base 2020 proporcionada en un sistema de telecomunicación y que comprende un hardware 2025 que le permite comunicarse con el ordenador central 2010 y con el UE 2030. El hardware 2025 puede incluir una interfaz 2026 de comunicación para establecer y mantener una conexión por cable o inalámbrica con una interfaz de un dispositivo de comunicación diferente del sistema 2000 de comunicación, así como una interfaz 2027 de radio para establecer y mantener, al menos, una conexión inalámbrica 2070 con el UE 2030 ubicado en un área de cobertura (no mostrada en la Figura 20) servida por la estación base 2020. La interfaz 2026 de comunicación puede configurarse para facilitar una conexión 2060 al ordenador central 2010. La conexión 2060 puede ser directa, o puede pasar a través de una red central (no mostrada en la Figura 20) del sistema de telecomunicación y/o a través de una o más redes intermedias fuera del sistema de telecomunicación. En la realización mostrada, el hardware 2025 de la estación base 2020 también puede incluir un circuito 2028 de procesamiento, que puede comprender uno o más procesadores programables, circuitos integrados de aplicación específica, matrices de puertas lógicas programables en campo o combinaciones de estos (no mostrados) adaptados para ejecutar instrucciones.

La estación base 2020 también incluye un software 2021 almacenado internamente o accesible a través de una conexión externa. Por ejemplo, el software 2021 puede incluir instrucciones de programa (también denominadas producto de programa informático) que, cuando son ejecutadas por el circuito 2028 de procesamiento, pueden configurar la estación base 2020 para realizar operaciones correspondientes a varios métodos ejemplares (p. ej., procedimientos) descritos en la presente memoria.

El sistema 2000 de comunicación también puede incluir el UE 2030 ya mencionado, cuyo hardware 2035 puede incluir una interfaz 2037 de radio configurada para establecer y mantener una conexión inalámbrica 2070 con una estación base que da servicio a un área de cobertura en la que el UE 2030 se encuentra actualmente. El hardware 2035 del UE 2030 también puede incluir un circuito 2038 de procesamiento, que puede comprender uno o más procesadores programables, circuitos integrados de aplicación específica, matrices de puertas lógicas programables en campo o combinaciones de estos (no mostrados) adaptados para ejecutar instrucciones.

El UE 2030 también incluye un software 2031, que está almacenado en, o es accesible por, el UE 2030 y puede ser ejecutado por el circuito 2038 de procesamiento. El software 2031 incluye una aplicación 2032 de cliente. La aplicación 2032 de cliente puede operarse para proporcionar un servicio a un usuario humano o no humano a través del UE 2030, con el apoyo del ordenador central 2010. En el ordenador central 2010, una aplicación central 2012 en ejecución puede comunicarse con la aplicación 2032 de cliente en ejecución a través de la conexión OTT 2050 que termina en el UE 2030 y el ordenador central 2010. Al proporcionar el servicio al usuario, la aplicación 2032 de cliente puede recibir datos de la solicitud de la aplicación central 2012 y proporcionar datos de usuario en respuesta a los datos de la solicitud. La conexión OTT 2050 puede transferir tanto los datos de la solicitud como los datos de usuario. La aplicación 2032 de cliente puede interactuar con el usuario para generar los datos de usuario que proporciona. El software 2031 también puede incluir instrucciones de programa (también denominadas producto de programa informático) que, cuando son ejecutadas por el circuito 2038 de procesamiento, pueden configurar el UE 2030 para realizar operaciones correspondientes a varios métodos ejemplares (p. ej., procedimientos) descritos en la presente memoria.

Se observa que el ordenador central 2010, la estación base 2020 y el UE 2030 ilustrados en la Figura 20 pueden ser similares o idénticos al ordenador central 1230, a una de las estaciones base 1612a, 1612b, 1612c y a uno de los UEs 1691, 1692 de la Figura 16, respectivamente. Es decir, el funcionamiento interno de estas entidades puede ser como se muestra en la Figura 20 e, independientemente, la topología de la red circundante puede ser la de la Figura 16.

En la Figura 20, la conexión OTT 2050 se ha dibujado de manera abstracta para ilustrar la comunicación entre el ordenador central 2010 y el UE 2030 a través de la estación base 2020, sin referencia explícita a ningún dispositivo intermediario y al enrutamiento preciso de mensajes a través de estos dispositivos. La infraestructura de red puede determinar el enrutamiento, que puede configurarse para ocultarse del UE 2030 o del proveedor de servicios que opera el ordenador central 2010, o de ambos. Mientras que la conexión OTT 2050 está activa, la infraestructura de red puede además tomar decisiones mediante las cuales cambia dinámicamente el enrutamiento (p.ej., sobre la base de la consideración del equilibrio de carga o de la reconfiguración de la red).

La conexión inalámbrica 2070 entre el UE 2030 y la estación base 2020 está de acuerdo con las enseñanzas de las realizaciones descritas a lo largo de esta descripción. Una o más de las diversas realizaciones mejoran el rendimiento de los servicios OTT proporcionados al UE 2030 utilizando la conexión OTT 2050, en la que la conexión inalámbrica 2070 forma el último segmento. Más precisamente, las realizaciones ejemplares descritas en la presente memoria pueden mejorar la flexibilidad de la red para monitorizar la calidad de servicio (QoS) de extremo a extremo de los flujos de datos, incluidos sus portadores de radio correspondientes, asociados con sesiones de datos entre un equipo de usuario (UE) y otra entidad, como una aplicación de datos OTT o un servicio externo a la red 5G. Estas y otras ventajas pueden facilitar un diseño, una implementación, y un despliegue más oportunos de las soluciones 5G/NR. Además, dichas realizaciones pueden facilitar el control flexible y oportuno de la QoS de la sesión de datos, lo que puede conducir a mejoras en capacidad, rendimiento, latencia, etc. que están previstas por 5G/NR e importantes para el crecimiento de los servicios OTT.

Puede proporcionarse un procedimiento de medida con el fin de controlar la tasa de datos, la latencia y otros aspectos operativos de la red en los que mejoran una o más realizaciones. Además, puede haber una funcionalidad de red opcional para reconfigurar la conexión OTT 2050 entre el ordenador central 2010 y el UE 2030, en respuesta a variaciones en los resultados de medida. El procedimiento de medida y/o la funcionalidad de red para reconfigurar la conexión OTT 2050 pueden implementarse en el software 2011 y en el hardware 2015 del ordenador central 2010 o en el software 2031 y en el hardware 2035 del UE 2030, o en ambos. En las realizaciones, los sensores (no mostrados) pueden implementarse en, o en asociación con, dispositivos de comunicación a través de los cuales pasa la conexión OTT 2050; los sensores pueden participar en el procedimiento de medida suministrando valores de las cantidades monitorizadas ejemplificadas anteriormente, o suministrando valores de otras cantidades físicas a partir de los cuales el software 2011,2031 puede calcular o estimar las cantidades monitorizadas. La reconfiguración de la conexión OTT 2050 puede incluir formato del mensaje, configuración de la retransmisión, enrutamiento preferido etc.; la reconfiguración no necesita afectar a la estación base 2020, y puede ser desconocida o imperceptible para la estación base 2020. Dichos procedimientos y funcionalidades pueden ser conocidos y practicados en la técnica. En ciertas realizaciones, las medidas pueden implicar señalización propietaria del UE que facilita las medidas de rendimiento, los tiempos de propagación, la latencia y similares del ordenador central 2010. Las medidas pueden implementarse en ese software 2011 y 2031 que hace que los mensajes se transmitan, en particular mensajes vacíos o 'ficticios', utilizando la conexión OTT 2050 mientras monitoriza tiempos de propagación, errores, etc.

La Figura 21 es un diagrama de flujo que ilustra un método y/o procedimiento ejemplar implementado en un sistema de comunicación, de acuerdo con una realización. El sistema de comunicación incluye un ordenador central, una estación base y un UE que, en algunas realizaciones ejemplares, pueden ser los descritos con referencia a otras figuras en la presente memoria. Por simplicidad de la presente descripción, en esta sección solo se incluirán referencias de dibujo a la Figura 21. En el paso 2110, el ordenador central proporciona datos de usuario. En el sub­ paso 2111 (que puede ser opcional) del paso 2110, el ordenador central proporciona los datos de usuario ejecutando una aplicación central. En el paso 2120, el ordenador central inicia una transmisión que transporta los datos de usuario al UE. En el paso 2130 (que puede ser opcional), la estación base transmite al UE los datos de usuario que se transportaron en la transmisión que inició el ordenador central, de acuerdo con las enseñanzas de las realizaciones descritas a lo largo de esta descripción. En el paso 2140 (que también puede ser opcional), el UE ejecuta una aplicación de cliente asociada con la aplicación central ejecutada por el ordenador central.

La Figura 22 es un diagrama de flujo que ilustra un método y/o procedimiento ejemplar implementado en un sistema de comunicación, de acuerdo con una realización. El sistema de comunicación incluye un ordenador central, una estación base y un UE que pueden ser los descritos con referencia a otras figuras en la presente memoria. Por simplicidad de la presente descripción, en esta sección solo se incluirán referencias de dibujo a la Figura 22. En el paso 2210 del método, el ordenador central proporciona datos de usuario. En un sub-paso opcional (no mostrado), el ordenador central proporciona los datos de usuario ejecutando una aplicación central. En el paso 2220, el ordenador central inicia una transmisión que transporta los datos de usuario al UE. La transmisión puede pasar a través de la estación base, de acuerdo con las enseñanzas de las realizaciones descritas a lo largo de esta descripción. En el paso 2230 (que puede ser opcional), el UE recibe los datos de usuario transportados en la transmisión.

La Figura 23 es un diagrama de flujo que ilustra un método y/o procedimiento ejemplar implementado en un sistema de comunicación, de acuerdo con una realización. El sistema de comunicación incluye un ordenador central, una estación base y un UE que pueden ser los descritos con referencia a otras figuras en la presente memoria. Por simplicidad de la presente descripción, en esta sección solo se incluirán referencias de dibujo a la Figura 23. En el paso 2310 (que puede ser opcional), el UE recibe datos de entrada proporcionados por el ordenador central. Adicional o alternativamente, en el paso 2320, el UE proporciona datos de usuario. En el sub-paso 2321 (que puede ser opcional) del paso 2320, el UE proporciona los datos de usuario ejecutando una aplicación de cliente. En el sub-paso 2311 (que puede ser opcional) del paso 2310, el UE ejecuta una aplicación de cliente que proporciona los datos de usuario en reacción a los datos de entrada recibidos proporcionados por el ordenador central. Al proporcionar los datos de usuario, la aplicación de cliente ejecutada puede además considerar la entrada del usuario recibida del usuario. Independientemente de la manera específica en la que se proporcionaron los datos de usuario, el UE inicia, en el sub­ paso 2330 (que puede ser opcional), la transmisión de los datos de usuario al ordenador central. En el paso 2340 del método, el ordenador central recibe los datos de usuario transmitidos desde el UE, de acuerdo con las enseñanzas de las realizaciones descritas a lo largo de esta descripción.

La Figura 24 es un diagrama de flujo que ilustra un método y/o procedimiento ejemplar implementado en un sistema de comunicación, de acuerdo con una realización. El sistema de comunicación incluye un ordenador central, una estación base y un UE que pueden ser los descritos con referencia a otras figuras en la presente memoria. Por simplicidad de la presente descripción, en esta sección solo se incluirán referencias de dibujo a la Figura 24. En el paso 2410 (que puede ser opcional), de acuerdo con las enseñanzas de las realizaciones descritas a lo largo de esta descripción, la estación base recibe datos de usuario del UE. En el paso 2420 (que puede ser opcional), la estación base inicia la transmisión de los datos de usuario recibidos al ordenador central. En el paso 2430 (que puede ser opcional), el ordenador central recibe los datos de usuario transportados en la transmisión iniciada por la estación base.

Como se describe en la presente memoria, el dispositivo y/o aparato pueden representarse mediante un chip semiconductor, un conjunto de chips, o un módulo (hardware) que comprende dicho chip o conjunto de chips; esto, sin embargo, no excluye la posibilidad de que una funcionalidad de un dispositivo o aparato, en lugar de implementarse en hardware, se implemente como un módulo software, como un programa informático o un producto de programa informático que comprende porciones de código software ejecutable para su ejecución o ser ejecutado en un procesador. Además, la funcionalidad de un dispositivo o aparato puede implementarse mediante cualquier combinación de hardware y software. Un dispositivo o aparato también puede considerarse como un conjunto de múltiples dispositivos y/o aparatos, ya sea funcionalmente en cooperación, o independientemente unos de otros. Además, los dispositivos y aparatos pueden implementarse de forma distribuida en todo un sistema, siempre que se conserve la funcionalidad del dispositivo o aparato. Dichos, y similares, principios se consideran conocidos por un experto en la técnica.

Además, las funciones descritas en la presente memoria como realizadas por un dispositivo inalámbrico o un nodo de red pueden distribuirse sobre una pluralidad de dispositivos inalámbricos y/o nodos de red. En otras palabras, se contempla que las funciones del nodo de red y del dispositivo inalámbrico descritas en la presente memoria no se limitan al rendimiento de un solo dispositivo físico y, de hecho, pueden distribuirse entre varios dispositivos físicos.

A menos que se defina de otro modo, todos los términos (incluidos los términos técnicos y científicos) utilizados en la presente memoria tienen el mismo significado que comúnmente entiende una persona de conocimiento ordinario en la técnica a la que pertenece esta descripción. Se entenderá además que los términos utilizados en la presente memoria deben interpretarse con un significado que sea consistente con su significado en el contexto de esta especificación y la técnica relevante y no se interpretarán en un sentido idealizado o demasiado formal a menos que así se defina expresamente en la presente memoria.

Además, ciertos términos utilizados en la presente descripción, incluida la especificación, los dibujos y las realizaciones ejemplares de la misma, pueden utilizarse como sinónimos en ciertos casos, incluidos, pero no limitados a, p. ej., datos e información. Debe entenderse que, si bien estas palabras y/u otras palabras que pueden ser sinónimas entre sí, pueden utilizarse como sinónimos en la presente memoria, puede haber casos en los que puede pretenderse que dichas palabras no se utilicen como sinónimos.

Como se utiliza en la presente memoria, a menos que se indique expresamente lo contrario, las frases "al menos uno de" y "uno o más de", seguidas de una lista conjunta de elementos enumerados (p. ej., "A y B", "A, B y C "), pretenden significar "al menos un elemento, con cada elemento seleccionado de la lista que consta de" los elementos enumerados. Por ejemplo, "al menos uno de A y B" pretende significar cualquiera de los siguientes: A; B; A y B. Asimismo, "uno o más de A, B y C" pretende significar cualquiera de los siguientes: A; B; C; A y B; B y C; A y C; A, B y C.

Como se utiliza en la presente memoria, a menos que se indique expresamente lo contrario, la frase "una pluralidad de" seguida de una lista conjunta de elementos enumerados (por ejemplo, "A y B", "A, B y C") pretende significar "múltiples elementos, con cada elemento seleccionado de la lista que consta de" los elementos enumerados. Por ejemplo, "una pluralidad de A y B" pretende significar cualquiera de los siguientes: más de una A; más de una B; o al menos una A y al menos una B.

Lo anterior simplemente ilustra los principios de la descripción. Varias modificaciones y alteraciones a las realizaciones descritas serán evidentes para los expertos en la técnica en vista de las enseñanzas de la presente memoria. Por lo tanto, se apreciará que los expertos en la técnica podrán idear numerosos sistemas, disposiciones, y procedimientos que, aunque no se muestran o describen explícitamente en la presente memoria, incorporan los principios de la descripción y por lo tanto, pueden estar dentro del alcance de la descripción. Varias realizaciones ejemplares pueden utilizarse juntas entre sí, así como indistintamente, como deben entender los que tienen un conocimiento ordinario en la técnica.

Claims (30)

REIVINDICACIONES

1. Un método para un traspaso condicional en una red de acceso por radio, RAN, en donde el método es realizado por un equipo de usuario, UE, y caracterizado por:

recibir (1340), de un nodo RAN de origen, un comando de traspaso condicional que comprende:

una primera indicación de un traspaso condicional,

una segunda indicación de una condición de activación para el traspaso condicional,

una segunda configuración de medida relacionada con la condición de activación, y

una tercera configuración de medida relacionada con una o más celdas objetivo servidas por un nodo RAN objetivo, para ser aplicada tras la ejecución del traspaso condicional hacia una en particular de las celdas objetivo; en donde las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para el traspaso condicional indicado;

en función de la segunda configuración de medida, detectar (1350) el cumplimiento de la condición de activación con respecto a una en particular de las celdas objetivo y ejecutar (1360) el traspaso condicional hacia la celda objetivo en particular; tras la ejecución del traspaso condicional por parte del UE hacia la celda objetivo en particular, aplicar la tercera información de configuración a la celda objetivo en particular; y posteriormente realizar (1370) terceras medidas en la celda objetivo en particular en función de la tercera configuración de medida y reportar, al nodo RAN objetivo (1370), las terceras medidas realizadas.

2. El método de la reivindicación 1, en donde detectar (1350) el cumplimiento de la condición de activación comprende realizar (1351) segundas medidas en la celda de origen del UE y una o más celdas objetivo en función de la segunda configuración de medida.

3. El método de cualquiera de las reivindicaciones 1-2, en donde ejecutar (1360) el traspaso condicional comprende una o más de las siguientes operaciones:

dejar de realizar (1361) segundas medidas en función de la segunda configuración de medida;

eliminar o liberar (1362), al menos, una parte de una segunda configuración de medida almacenada; y almacenar (1363) la tercera configuración de medida.

4. El método de cualquiera de las reivindicaciones 1-3, que comprende además:

recibir (1310), de un nodo RAN de origen que da servicio a la celda de origen del UE, una primera configuración de medida relacionada con la celda de origen del UE;

almacenar (1320) la primera configuración de medida; y.

en función de la primera configuración de medida, realizar y reportar (1330) primeras medidas en la celda de origen del UE antes de recibir (1340) uno o más comandos de traspaso condicional.

5. El método de la reivindicación 4, en donde recibir (1340) el comando de traspaso condicional comprende almacenar (1342), al menos, una parte de la segunda configuración de medida y de la tercera configuración de medida por separado de la primera configuración de medida.

6. El método de cualquiera de las reivindicaciones 4-5, en donde:

la tercera configuración de medida se recibe como una configuración de medida completa; y

ejecutar (1360) el traspaso condicional comprende además reemplazar (1364) una primera configuración de medida almacenada con la tercera configuración de medida.

7. El método de cualquiera de las reivindicaciones 4-5, en donde:

la tercera configuración de medida se recibe como un delta con respecto a una o más de la primera configuración de medida y de la segunda configuración de medida; y

ejecutar (1360) el traspaso condicional hacia la celda objetivo en particular comprende determinar (1365) una configuración de medida, para las terceras medidas, en función de la tercera configuración de medida y una o más de la primera configuración de medida y de la segunda configuración de medida.

8. El método de cualquiera de las reivindicaciones 1-7, en donde:

las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para el traspaso condicional indicado.

9. El método de cualquiera de las reivindicaciones 1 -8, en donde ejecutar (1360) el traspaso condicional en función de la segunda configuración comprende:

realizar y reportar (1366) terceras medidas en la celda objetivo en particular en función de la segunda configuración de medida; y

posteriormente recibir (1367) el mensaje de reconfiguración que comprende la tercera configuración de medida.

10. Un método para un traspaso condicional de un equipo de usuario, UE, en una red de acceso por radio, RAN, en donde el método es realizado por un nodo RAN de origen y comprende:

enviar (1440), a un nodo RAN objetivo, una solicitud para aceptar un traspaso condicional relacionado con el UE; en donde el método se caracteriza por:

recibir (1450), del nodo RAN objetivo, una confirmación del traspaso condicional, incluyendo la confirmación una tercera configuración de medida relacionada con una o más celdas objetivo servidas por el nodo RAN objetivo; determinar (1460) una segunda configuración de medida relacionada con una condición de activación para el traspaso condicional; y

enviar (1470), al UE, un comando de traspaso condicional que comprende:

una primera indicación del traspaso condicional;

una segunda indicación de la condición de activación;

la segunda configuración de medida; y

la tercera configuración de medida, y en donde las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para el traspaso condicional indicado, en donde la tercera configuración de medida se aplicará tras la ejecución del traspaso condicional por parte del UE hacia una en particular de las celdas objetivo.

11. El método de la reivindicación 10, en donde determinar (1460) la segunda configuración de medida comprende además enviar (1464) la segunda configuración de medida al nodo RAN objetivo.

12. El método de cualquiera de las reivindicaciones 10-11, que comprende además:

enviar (1410), al UE, una primera configuración de medida relacionada con una celda de origen, para el UE, que es servida por el nodo RAN de origen; y

recibir (1420) primeras medidas hechas por el UE en la celda de origen en función de la primera configuración de medida; y

en función de las primeras medidas, determinar (1430) que se requiere el traspaso condicional relacionado con el UE.

13. El método de la reivindicación 12, en donde la solicitud enviada al nodo RAN objetivo también incluye la primera configuración de medida.

14. El método de cualquiera de las reivindicaciones 12-13, en donde:

enviar (1410) la primera configuración de medida comprende almacenar (1412) la primera configuración de medida; y

determinar (1460) la segunda configuración de medida comprende almacenar (1462) la segunda configuración de medida por separado de la primera configuración de medida.

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

recibir (1480), del nodo RAN objetivo, una tercera indicación de que el traspaso condicional ha sido completado; y en respuesta a la tercera indicación, eliminar o liberar (1490), al menos, una parte de las configuraciones de medida primera y segunda almacenadas.

16. El método de cualquiera de las reivindicaciones 10-15, en donde aplica, al menos, una de las siguientes condiciones:

la segunda configuración de medida se determina como un delta con respecto a la primera configuración de medida; la tercera configuración de medida se recibe como un delta con respecto a la primera configuración de medida; y la tercera configuración de medida se recibe como un delta con respecto a la primera y a la segunda configuraciones de medida.

17. Un método para un traspaso condicional de un equipo de usuario, UE, en una red de acceso por radio, RAN, en donde el método es realizado por un nodo RAN objetivo y comprende:

recibir (1510), de un nodo RAN de origen, una solicitud para aceptar un traspaso condicional relacionado con el UE, incluyendo la solicitud una primera configuración de medida para el UE; en donde el método se caracteriza por:

en función de la primera configuración de medida, determinar (1520) una tercera configuración de medida para el UE en relación con una o más celdas objetivo servidas por el nodo RAN objetivo, en donde la tercera configuración de medida se aplicará tras la ejecución del traspaso condicional por parte del UE hacia una en particular de las celdas objetivo;

enviar (1530), al nodo RAN de origen, una confirmación del traspaso condicional, incluyendo la confirmación la tercera configuración de medida; y

recibir (1570), del UE, medidas realizadas en una en particular de las celdas objetivo en función de la tercera configuración de medida.

18. El método de la reivindicación 17, que comprende además enviar (1580), al nodo RAN de origen, una indicación de que el traspaso condicional ha sido completado.

19. El método de cualquiera de las reivindicaciones 17-18, en donde la tercera configuración de medida, incluida con la confirmación, es una de las siguientes:

un delta con respecto a una o más de la primera configuración de medida y de la segunda configuración de medida; o

una configuración de medida completa.

20. El método de cualquiera de las reivindicaciones 17-19, que comprende además:

recibir (1550) medidas hechas por el UE para la celda objetivo en particular en función de la segunda configuración de medida; y

posteriormente enviar (1560), al UE, un mensaje de reconfiguración que incluye la tercera configuración de medida.

21. El método de la reivindicación 20, en donde:

el método comprende además recibir (1540), del nodo RAN de origen, una segunda configuración de medida para el UE;

la segunda configuración de medida se recibe como un delta con respecto a la primera configuración de medida; y la tercera configuración de medida, incluida en el mensaje de reconfiguración, es un delta con respecto a la primera configuración de medida y a la segunda configuración de medida.

22. Un equipo de usuario, UE (120, 810, 1010, 1610, 1700, 1991, 1992, 2030) configurado para un traspaso condicional en una red de acceso por radio, RAN (100, 399, 1911), estando caracterizado además el UE por:

recibir, de un nodo RAN de origen, un comando de traspaso condicional que comprende:

una primera indicación de un traspaso condicional,

una segunda indicación de una condición de activación para el traspaso condicional,

una segunda configuración de medida relacionada con la condición de activación, y

una tercera configuración de medida relacionada con una o más celdas objetivo servidas por un nodo RAN objetivo, para ser aplicada tras la ejecución del traspaso condicional hacia una en particular de las celdas objetivo; en donde las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para el traspaso condicional indicado;

en función de la segunda configuración de medida, detectar el cumplimiento de la condición de activación con respecto a una en particular de las celdas objetivo y ejecutar el traspaso condicional hacia la celda objetivo en particular; tras la ejecución del traspaso condicional por parte del UE hacia la celda objetivo en particular, aplicar la tercera información de configuración a la celda objetivo en particular; y

posteriormente realizar terceras medidas en la celda objetivo en particular en función de la tercera configuración de medida y reportar, al nodo RAN objetivo, las terceras medidas realizadas.

23. El equipo de usuario, UE (120, 810, 1010, 1610, 1700, 1991, 1992, 2030) según la reivindicación 22 configurado para un traspaso condicional en una red de acceso por radio, RAN (100, 399, 1911), estando el UE dispuesto además para realizar los pasos correspondientes a cualquiera de los métodos de las reivindicaciones 2-9.

24. Un producto de programa informático que comprende instrucciones (1725, 2031) de programa que, cuando son ejecutadas por un circuito (1620, 1701,2038) de procesamiento de un equipo de usuario, UE (120, 810, 1010, 1610, 1700, 1991, 1992, 2030), realizan los pasos de:

recibir, de un nodo RAN de origen, un comando de traspaso condicional que comprende:

una primera indicación de un traspaso condicional,

una segunda indicación de una condición de activación para el traspaso condicional,

una segunda configuración de medida relacionada con la condición de activación, y

una tercera configuración de medida relacionada con una o más celdas objetivo servidas por un nodo RAN objetivo, para ser aplicada tras la ejecución del traspaso condicional hacia una en particular de las celdas objetivo; en donde las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para el traspaso condicional indicado;

en función de la segunda configuración de medida, detectar el cumplimiento de la condición de activación con respecto a una en particular de las celdas objetivo y ejecutar el traspaso condicional hacia la celda objetivo en particular; tras la ejecución del traspaso condicional por parte del UE hacia la celda objetivo en particular, aplicar la tercera información de configuración a la celda objetivo en particular; y

posteriormente realizar terceras medidas en la celda objetivo en particular en función de la tercera configuración de medida y reportar, al nodo RAN objetivo, las terceras medidas realizadas.

25. Un nodo (105-115, 300, 350, 820, 1020, 1660, 1830, 1912, 2020) de la red de acceso por radio, RAN, de origen, en una red de acceso por radio, RAN (100, 399, 1911), configurado para facilitar un traspaso condicional para un equipo de usuario, UE (120, 810, 1010, 1610, 1700, 1991, 1992, 2030) en la RAN, estando el nodo RAN de origen dispuesto además para:

enviar, a un nodo RAN objetivo, una solicitud para aceptar un traspaso condicional relacionado con el UE; y en donde el nodo RAN de origen se caracteriza por:

recibir, del nodo RAN objetivo, una confirmación del traspaso condicional, incluyendo la confirmación una tercera configuración de medida relacionada con una o más celdas objetivo servidas por el nodo RAN objetivo; determinar una segunda configuración de medida relacionada con una condición de activación para el traspaso condicional; y

enviar, al UE, un comando de traspaso condicional que comprende:

una primera indicación del traspaso condicional;

una segunda indicación de la condición de activación;

la segunda configuración de medida; y

la tercera configuración de medida, y en donde las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para el traspaso condicional indicado, en donde la tercera configuración de medida se aplicará tras la ejecución del traspaso condicional por parte del UE hacia una en particular de las celdas objetivo.

26. El nodo RAN de origen según la reivindicación 25, en donde el nodo RAN de origen está dispuesto además para realizar los pasos correspondientes a cualquiera de los métodos de las reivindicaciones 11-16.

27. Un producto de programa informático que comprende instrucciones (1695, 1821) de programa que, cuando son ejecutadas por un circuito (1670, 1860, 2028) de procesamiento de un nodo (105-115, 300, 350, 820, 1020, 1660, 1830, 1912, 2020) de la red de acceso por radio, RAN, de origen en una red de acceso por radio, ^rAⁿ (100, 399, 1911), realizan los pasos:

enviar, a un nodo RAN objetivo, una solicitud para aceptar un traspaso condicional relacionado con un equipo de usuario, UE;

recibir, del nodo RAN objetivo, una confirmación del traspaso condicional, incluyendo la confirmación una tercera configuración de medida relacionada con una o más celdas objetivo servidas por el nodo RAN objetivo; determinar una segunda configuración de medida relacionada con una condición de activación para el traspaso condicional; y

enviar, al UE, un comando de traspaso condicional que comprende:

una primera indicación del traspaso condicional;

una segunda indicación de la condición de activación;

la segunda configuración de medida; y

la tercera configuración de medida, y en donde las configuraciones de medida segunda y tercera incluyen configuraciones de medida respectivas para cada celda objetivo que es una candidata para el traspaso condicional indicado, en donde la tercera configuración de medida se aplicará tras la ejecución del traspaso condicional por parte del UE hacia una en particular de las celdas objetivo.

28. Un nodo (105-115, 300, 350, 830, 1030, 1660, 1830, 1912, 2020) de la red de acceso por radio, RAN, objetivo, en una red de acceso por radio, RAN (100, 399, 1911), configurado para facilitar un traspaso condicional para un equipo de usuario, UE (120, 810, 1010, 1610 , 1700, 1991, 1992, 2030) en la RAN, estando el nodo RAN objetivo dispuesto además para:

recibir, de un nodo RAN de origen, una solicitud para aceptar un traspaso condicional relacionado con el UE, incluyendo la solicitud una primera configuración de medida para el UE; en donde el nodo de red se caracteriza por:

en función de la primera configuración de medida, determinar una tercera configuración de medida para el UE en relación con una o más celdas objetivo servidas por el nodo RAN objetivo, en donde la tercera configuración de medida se aplicará tras la ejecución del traspaso condicional por parte del UE hacia una en particular de las celdas objetivo;

enviar, al nodo RAN de origen, una confirmación del traspaso condicional, incluyendo la confirmación la tercera configuración de medida; y

recibir, del UE, medidas realizadas en una en particular de las celdas objetivo en función de la tercera configuración de medida.

29. El nodo de red según la reivindicación 28, en donde el nodo RAN objetivo está dispuesto además para realizar los pasos correspondientes a cualquiera de los métodos de las reivindicaciones 18-21.

30. Un producto de programa informático que comprende instrucciones (1895, 2021) de programa que, cuando son ejecutadas por un circuito (1670, 1860, 2028) de procesamiento de un nodo (105-115, 300, 350, 830, 1030, 1660, 1830, 1912, 2020 ) de la red de acceso por radio, rAn , objetivo en una red de acceso por radio, Ra N (100 , 399, 1911), realizan los pasos:

recibir, de un nodo RAN de origen, una solicitud para aceptar un traspaso condicional relacionado con el UE, incluyendo la solicitud una primera configuración de medida para el UE;

en función de la primera configuración de medida, determinar una tercera configuración de medida para el UE en relación con una o más celdas objetivo servidas por el nodo RAN objetivo, en donde la tercera configuración de medida se aplicará tras la ejecución del traspaso condicional por parte del UE hacia una en particular de las celdas objetivo;

enviar, al nodo RAN de origen, una confirmación del traspaso condicional, incluyendo la confirmación la tercera configuración de medida; y

recibir, del UE, medidas realizadas en una en particular de las celdas objetivo en función de la tercera configuración de medida.