ES2966758T3 - Método y aparato para manejar la configuración de la actualización del área de notificación de la red de acceso por radio (RNA) tras un rechazo - Google Patents
Método y aparato para manejar la configuración de la actualización del área de notificación de la red de acceso por radio (RNA) tras un rechazo Download PDFInfo
- Publication number
- ES2966758T3 ES2966758T3 ES19724956T ES19724956T ES2966758T3 ES 2966758 T3 ES2966758 T3 ES 2966758T3 ES 19724956 T ES19724956 T ES 19724956T ES 19724956 T ES19724956 T ES 19724956T ES 2966758 T3 ES2966758 T3 ES 2966758T3
- Authority
- ES
- Spain
- Prior art keywords
- rnau
- timer
- wireless device
- message
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 135
- 230000004044 response Effects 0.000 claims abstract description 60
- 230000000737 periodic effect Effects 0.000 claims abstract description 41
- 230000000977 initiatory effect Effects 0.000 claims description 14
- 238000012545 processing Methods 0.000 description 42
- 238000004891 communication Methods 0.000 description 40
- 238000010586 diagram Methods 0.000 description 21
- 238000013459 approach Methods 0.000 description 20
- 230000005540 biological transmission Effects 0.000 description 19
- 230000006870 function Effects 0.000 description 13
- 238000005259 measurement Methods 0.000 description 13
- 230000015654 memory Effects 0.000 description 13
- 230000004807 localization Effects 0.000 description 11
- 230000009471 action Effects 0.000 description 10
- 230000011664 signaling Effects 0.000 description 10
- 230000001960 triggered effect Effects 0.000 description 10
- 230000008569 process Effects 0.000 description 8
- 230000010267 cellular communication Effects 0.000 description 7
- 238000004590 computer program Methods 0.000 description 7
- 230000006399 behavior Effects 0.000 description 6
- 230000007704 transition Effects 0.000 description 6
- 238000007726 management method Methods 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 241000700159 Rattus Species 0.000 description 3
- 238000003491 array Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000007774 longterm Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 108091005487 SCARB1 Proteins 0.000 description 2
- 102100037118 Scavenger receptor class B member 1 Human genes 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 239000000969 carrier Substances 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 125000004122 cyclic group Chemical group 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000005055 memory storage Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000001228 spectrum Methods 0.000 description 2
- 230000008093 supporting effect Effects 0.000 description 2
- 239000000725 suspension Substances 0.000 description 2
- CSRZQMIRAZTJOY-UHFFFAOYSA-N trimethylsilyl iodide Substances C[Si](C)(C)I CSRZQMIRAZTJOY-UHFFFAOYSA-N 0.000 description 2
- 101150084062 RAN gene Proteins 0.000 description 1
- 101150069124 RAN1 gene Proteins 0.000 description 1
- 101150014328 RAN2 gene Proteins 0.000 description 1
- 101100355633 Salmo salar ran gene Proteins 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000001976 improved effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000003595 spectral effect Effects 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/08—Mobility data transfer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
- H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/27—Transitions between radio resource control [RRC] states
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/02—Access restriction performed under specific conditions
- H04W48/06—Access restriction performed under specific conditions based on traffic conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un dispositivo inalámbrico maneja los informes de actualización del área. El dispositivo inalámbrico inicia (1502) una actualización del área de la red de radio, RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a un área de la red de radio, RNA, configurada para el dispositivo inalámbrico. El dispositivo inalámbrico recibe (1504), desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado. El mensaje incluye o va acompañado de una indicación de que es aplicable un valor de tiempo de espera. En respuesta al mensaje, el dispositivo inalámbrico configura (1506) un temporizador de espera de rechazo al valor del tiempo de espera y realiza (1508) la RNAU al expirar el temporizador de espera de rechazo. En algunas realizaciones, el dispositivo inalámbrico establece un temporizador RNAU periódico en el valor del tiempo de espera, en respuesta al mensaje, y realiza el RNAU al expirar el temporizador de espera de rechazo y el temporizador RNAU periódico. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Método y aparato para manejar la configuración de la actualización del área de notificación de la red de acceso por radio (RNA) tras un rechazo
Sector técnico
La invención se refiere a un método y a un dispositivo inalámbrico para manejar una actualización de área de red de radio, RNAU (Radio Network Area Update), rechazada.
Antecedentes
Evolución a Largo Plazo (Long Term Evolution, LTE) es un término general para las denominadas tecnologías de acceso por radio de cuarta generación (4G) desarrolladas dentro del Proyecto de Asociación de Tercera Generación (Third Generation Partnership Project, 3GPP) e inicialmente estandarizadas en las Versiones 8 y 9, también conocidas como UTRAN evolucionada (Evolved-UTRAN, E-UTRAN). LTE está dirigido a diversas bandas de frecuencia con licencia, y va acompañado de mejoras en aspectos no relacionados con la radio comúnmente conocidos como Evolución de la arquitectura del sistema (System Architecture Evolution, SAE), que incluye la red central en paquetes evolucionada (Evolved Packet Core, EPC). LTE continúa evolucionando por medio de versiones posteriores que se desarrollan según procesos de establecimiento de estándares con 3GPP y sus grupos de trabajo (Working Groups, WG), incluido el WG de la red de acceso por radio (Radio Access Network, RAN), y subgrupos de trabajo (por ejemplo, RAN1, RAN2, etc).
La Versión 10 (Release 10) de LTE soporta anchos de banda superiores a 20 MHz. Un requisito importante de la Versión 10 es garantizar la compatibilidad con lo anterior, con la Versión 8 de LTE. Esto también debe incluir la compatibilidad de espectro. De este modo, una portadora de LTE Versión 10 de banda ancha (por ejemplo, más ancha de 20 MHz) debería aparecer como un número de portadoras para un terminal de LTE Versión 8 (“heredado”). Cada una de estas portadoras se puede denominar portadora componente (Componente Carrier, CC). Para una utilización eficiente de una portadora amplia también para terminales heredados, se pueden programar terminales heredados en todas las partes de la portadora de LTE Versión 10 de banda ancha. Una manera a modo de ejemplo de conseguir esto es mediante la agregación de portadoras (Carrier Aggregation, CA), mediante la cual un terminal de Versión 10 puede recibir múltiples CC, cada una de los cuales tiene preferentemente la misma estructura que una portadora de Versión 8. De manera similar, una de las mejoras en LTE Versión 11 es un canal físico de control de enlace descendente mejorado (Enhanced Physical Downlink Control CHannel, ePDCCH), que tiene como objetivo aumentar la capacidad y mejorar la reutilización espacial de los recursos del canal de control, mejorar la coordinación de interferencias entre celdas (Inter-Cell Interference Coordination, ICIC) y soportar formación de haces de antena y/o diversidad de transmisión para el canal de control.
En la figura 1 se muestra una arquitectura general a modo de ejemplo de una red que comprende LTE y SAE. Una E-UTRAN 100 comprende uno o más Nodos B evolucionados (eNB), tales como los eNB 105, 110 y 115, y uno o más equipos de usuario (User Equipment, UE), tal como el UE 120. Tal como se utiliza dentro de los estándares del 3GPP, “equipo de usuario” o “UE” significa cualquier dispositivo de comunicación inalámbrica (por ejemplo, teléfono inteligente o dispositivo informático) que sea capaz de comunicarse con un equipo de red compatible con el estándar 3GPP, incluida E-UTRAN, así como como UTRAN y/o GERAN, tal como se conocen comúnmente las redes de acceso por radio 3GPP de tercera (“3G”) y segunda (“2G”) generación del 3GPP.
Tal como se especifica en el 3GPP, E-UTRAN 100 es responsable de todas las funciones relacionadas con la radio en la red de acceso, incluido el control de portador de radio, control de admisión de radio, control de movilidad de radio, programación y asignación dinámica de recursos a un UE en enlace ascendente y enlace descendente, así como la seguridad de las comunicaciones con el UE. Estas funciones residen en los eNB, tal como los eNB 105, 110 y 115. Los eNB en la E-UTRAN se comunican entre sí a través de la interfaz X1, tal como se muestra en la figura 1. Los eNB también son responsables de la interfaz de E-UTRAN al EPC, específicamente la interfaz S1 a la entidad de gestión de la movilidad (Mobility Management Entity, MME) y la pasarela de servicio (Serving GateWay, SGW), mostradas conjuntamente 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 entre el UE y la EPC, que se conocen como protocolos de estrato de no acceso (Non-Access Stratum, NAS). El S-GW maneja todos los paquetes de datos del Protocolo de Internet (Internet Protocol, IP) entre el UE y la EPC, y sirve como ancla de movilidad local para los portadores de datos cuando el UE se desplaza entre varios eNB, tales como los eNB 105, 110 y 115.
La figura 2A muestra un diagrama de bloques de alto nivel de una arquitectura de LTE a modo de ejemplo 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 (Access Stratum, AS) y el estrato de no acceso (NAS). La figura 1 también ilustra dos puntos de interfaz concretos, a saber, Uu (interfaz de radio UE/E-UTRAN) y S1 (interfaz E-UTRAN/EPC), cada uno de los cuales utiliza un conjunto específico de protocolos, es decir, protocolos de radio y protocolos de S1. Cada uno de los dos protocolos se puede segmentar además en funcionalidad de protocolo del plano de usuario (o “plano U”) y del plano de control (o “plano C”). En la interfaz Uu, el plano U transporta información del usuario (por ejemplo, paquetes de datos), mientras que el plano C transporta información de control entre UE y E-UTRAN.
La figura 2B ilustra un diagrama de bloques de una pila de protocolos del plano C, a modo de ejemplo, en la interfaz Uu que comprende las capas Física (PHYsical, PHY), de control de acceso al medio (Medium Access Control, MAC), de control del enlace de radio (Radio Link Control, RLC), de protocolo de convergencia de datos en paquetes (Packet Data Convergence Protocol, PDCP), y de control de los recursos de radio (Radio Resource control, Rr C). 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 de LTE. La capa de MAC proporciona servicios de transferencia de datos en canales lógicos, asigna canales lógicos a canales de transporte de<p>H<y>y reasigna recursos de PHY para soportar estos servicios. La capa de RLC proporciona detección y/o corrección de errores, concatenación, segmentación y reensamblaje, reordenación de datos transferidos hacia o desde las capas superiores. Las capas PHY, de MAC y de RLC realizan funciones idénticas tanto para el plano U como para el plano C. La capa de 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, tal como la compresión de cabecera.
La figura 2C muestra un diagrama de bloques de una arquitectura de protocolo de interfaz de radio de LTE a modo de ejemplo desde la perspectiva de la PHY. Las interfaces entre las diversas capas son proporcionadas por los puntos de acceso a servicio (Service Access Points, SAP), indicados por los óvalos en la figura 2C. La capa PHY interactúa con las capas de protocolo de MAC y RRC descritas anteriormente. El MAC proporciona diferentes canales lógicos a la capa de protocolo de RLC (también descrita 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 diversas funciones, incluida la detección y corrección de errores; igualación de velocidades y asignación 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, procesamiento de antenas de múltiples entradas y múltiples salidas (Multiple Input Multiple Output, MIMO) con formación de haces; y proporcionar mediciones de radio a capas superiores, tal como RRC.
Los canales físicos de enlace descendente (es decir, eNB a UE) proporcionados por PHY de LTE incluyen canal físico compartido de enlace descendente (Physical Downlink Shared CHannel, PDSCH), canal físico de multidifusión (Physical Multicast Channel, PMCH), canal físico de control de enlace descendente (Physical Downlink Control CHannel, PDCCH), canal físico de control de enlace descendente de retransmisión (Relay, PDCCH, R-PDCCH), canal físico de transmisión (Physical Broadcast CHannel, PBCH), Canal físico de indicación de formato de control (Physical Control Format Indicator CHannel, PCFICH) y canal físico indicador de ARQ híbrida (Physical Hybrid-arq Indicator CHannel, PHICH). Además, el enlace descendente de PHY de LTE incluye diversas señales de referencia, señales de sincronización y señales de descubrimiento.
Los canales físicos de enlace ascendente (es decir, UE a eNB) proporcionados por la PHY de LTE incluyen el canal físico compartido de enlace ascendente (Physical Uplink Shared CHannel, PUSCH), el Canal físico de control del enlace ascendente (Physical Uplink Control CHannel, PUCCH) y el Canal físico de acceso aleatorio (Physical Random Access CHannel, PRACH). Además, el enlace ascendente de PHY de LTE incluye diversas señales de referencia que incluyen señales de referencia de demodulación (DeModulation Reference Signal, DM-RS), que son transmitidas para ayudar al eNB en la recepción de un PUCCH o PUSCH asociado; y señales de referencia de sondeo (Sounding Reference Signal, SRS), que no están asociadas a ningún canal de enlace ascendente.
El esquema de acceso múltiple para la PHY de LTE se basa en multiplexación por división ortogonal de la frecuencia (Orthogonal Frequency Division Multiplexing, OFDM) con un prefijo cíclico (Cyclic Prefix, CP) en el enlace descendente, y en acceso múltiple por división de frecuencia de portadora única (Single-Carrier Frequency Division Multiple Access, SC-FDMA) con un prefijo cíclico en el enlace ascendente. Para soportar la transmisión en espectro emparejado y no emparejado, PHY de LTE soporta dúplex por división de la frecuencia (Frequency Division Duplex, FDD) (incluida la operación dúplex completa y semi-dúplex) y dúplex por división del tiempo (Time Division Duplex, TDD). La figura 3A muestra una estructura de trama de radio a modo de ejemplo (“tipo 1”) utilizada para la operación de enlace descendente (DownLink, DL) de FDD de LTE. La trama de radio de DL tiene una duración fija de 10 ms, y consta de 20 intervalos, etiquetados del 0 al 19, cada una 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 de DL de FDD a modo de ejemplo consta de N<DLsímb>símbolos de OFDM, cada uno de los cuales está compuesto por N<s c>subportadoras de OFDM. Valores a modo de ejemplo de N<DLsímb>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<s c>es configurable basándose en el ancho de banda disponible del canal. Puesto que los expertos en la materia están familiarizados con los principios de la OFDM, se omiten más detalles en esta descripción.
Tal como se muestra en la figura 3A, una combinación de una subportadora concreta en un símbolo se conoce como elemento de recurso (Resource Element, RE). Cada RE se utiliza para transmitir un número concreto de bits, dependiendo del tipo de modulación y/o constelación de asignación de bits utilizada para ese RE. Por ejemplo, algunos RE pueden transportar dos bits utilizando modulación de QPSK, mientras que otros RE pueden transportar cuatro o seis bits utilizando 16 o 64 QAM, respectivamente. Los recursos de radio de PHY de LTE también se definen en términos de bloques de recursos físicos (Physical Resource Block, PRB). Un PRB abarca N<r b s c>, subportadoras durante la duración de un intervalo (es decir, N<DLsímb>símbolos), donde N<r b s c>es habitualmente 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<r b s c>subportadoras durante una subtrama completa (es decir, símbolos 2N<DLsímb>) se conoce como par de PRB. Por consiguiente, los recursos disponibles en una subtrama de DL de PHY de LTE comprenden pares N<d l r b>PRB, cada uno de los cuales comprende 2N<DLsímb>• N<r b s c>RE. Para un CP normal y un ancho de banda de subportadora de 15 KHz, un par de PRB comprende 168 RE.
La figura 3B muestra una trama de radio de enlace ascendente (UpLink, UL) de FDD de LTE a modo de ejemplo configurada de manera similar a la trama de radio de DL de FDD a modo de ejemplo que se muestra en la figura 3A. Utilizando terminología consistente con la descripción de DL anterior, cada intervalo de UL consta de N<ULsímb>símbolos de OFDM, cada uno de los cuales está compuesto por N<s c>subportadoras de OFDM.
Tal como se explicó anteriormente, la PHY de LTE asigna los diversos canales físicos de DL y UL a los recursos que se muestran en las figuras 3A y 3B, respectivamente. Por ejemplo, el PHICH transporta retroalimentación de HARq (por ejemplo, ACK/NAK) para transmisiones de UL por parte de los UE. De manera similar, el PDCCH transporta asignaciones de programación, retroalimentación de calidad del canal (por ejemplo, CSI) para el canal de UL y otra información de control. Asimismo, un PUCCH transporta información de control de enlace ascendente tal como solicitudes de programación, CSI para el canal de enlace descendente, retroalimentación de HARQ para transmisiones de DL de eNB y otra información de control. Tanto el PDCCH como el PUCCH pueden ser transmitidos en agregaciones de uno o varios elementos de canal de control (Control Channel Elements, CCE) consecutivos, y un CCE se asigna al recurso físico basándose en los grupos de elementos de recurso (Resource Element Groups, REG), cada uno de los cuales se compone de una pluralidad de RE. Por ejemplo, un CCE puede comprender nueve (9) REG, cada uno de los cuales puede comprender cuatro (4) RE.
Si bien LTE se diseñó principalmente para comunicaciones de usuario a usuario, se prevé que las redes celulares 5G (también denominadas “NR”) soporten tanto altas velocidades de datos de un solo usuario (por ejemplo, 1 Gb/s) como comunicación a gran escala, de máquina a máquina, que implica transmisiones cortas, en ráfagas, desde muchos dispositivos diferentes que comparten el ancho de banda de frecuencia. Los estándares de radio 5G (también conocidos como “Nueva Radio” o “NR”) están dirigidos actualmente a una amplia gama de servicios de datos, incluidos eMBB (banda ancha móvil mejorada, enhanced Mobile BroadBand) y URLLC (comunicación ultrafiable de baja latencia, Ultra-Reliable Low Latency Communication). Estos servicios pueden tener diferentes requisitos y objetivos. Por ejemplo, URLLC está destinada a proporcionar un servicio de datos con requisitos de latencia y error extremadamente estrictos, por ejemplo, probabilidades de error tan bajas como 10<-5>o menos, y latencia de extremo a extremo de 1 ms o menos. Para eMBB, los requisitos de latencia y probabilidad de error pueden ser menos estrictos, mientras que la velocidad máxima soportada requerida y/o la eficiencia espectral pueden ser mayores.
La figura 4 ilustra una vista de alto nivel de la arquitectura de red 5G, que consta de una RAN de próxima generación (Next Generation-RAN, NG-RAN) y un núcleo 5<g>(5GC). La NG-RAN puede comprender un conjunto de gNodoB (gNB) conectados al 5GC a través de una o más interfaces de NG, mientras que los gNB se pueden conectar entre sí a través de una o más interfaces de Xn. Cada uno de los gNB puede soportar dúplex por división de la frecuencia (FDD), dúplex por división del tiempo (TDD) o una combinación de los mismos.
Los nodos lógicos RAN de NG mostrados en la figura 4 (y descritos en el documento 3GPP TR 38.801 v1.2.0) incluyen una unidad central (Central Unit, CU o gNB-CU) y una o más unidades distribuidas (Distributed Unit, DU o gNB-DU). CU es un nodo lógico que es una unidad centralizada que aloja protocolos de capa alta e incluye una serie de funciones de gNB, incluido el control del funcionamiento de las DU. Una DU es un nodo lógico descentralizado que aloja protocolos de capa inferior y puede incluir, según la opción de división funcional, diversos subconjuntos de funciones de gNB. (Tal como se utilizan en el presente documento, los términos “unidad central” y “unidad centralizada” se utilizan indistintamente, y los términos “unidad distribuida” y “unidad descentralizada” se utilizan de manera intercambiable).
Los elementos NG, Xn-C y F1 mostrados en la figura 4 son interfaces lógicas. Para NG-RAN, las interfaces NG y Xn-C para un gNB dividido (por ejemplo, que consta de una gNB-CU y una gNB-DU) terminan en la gNB-CU. Del mismo modo, para EN-DC, las interfaces S1-U y X2-C para un gNB dividido terminan en la gNB-CU. La gNB-CU se conecta a las gNB-DU a través de las respectivas interfaces lógicas F1. La gNB-CU y las gNB-DU conectados solo son visibles para otros gNB y la 5GC como gNB; por ejemplo, la interfaz F1 no es visible más allá de gNB-CU.
Además, una CU puede alojar protocolos tales como RRC y PDCP, mientras que una DU puede alojar protocolos tales como RLC, MAC y PHY. Existen otras variantes de distribuciones de protocolo entre CU y DU, tal como alojar el RRC, el PDCP y parte del protocolo de RLC en la CU (por ejemplo, la función de solicitud de retransmisión automática (Automatic Retransmission reQuest, ARQ)), mientras que se alojan las partes restantes del protocolo de RLC en la DU, junto con MAC y PHY. En algunas realizaciones a modo de ejemplo, se supone que la CU aloja el RRC y el PDCP, donde se supone que el PDCP maneja tanto el tráfico de UP como el tráfico de CP. No obstante, otras realizaciones a modo de ejemplo pueden utilizar otras divisiones de protocolos alojando ciertos protocolos en la CU y otros en la DU. Las realizaciones a modo de ejemplo también pueden ubicar protocolos del plano de control centralizado (por ejemplo, PDCP-C y RRC) en una CU diferente con respecto a los protocolos del plano de usuario centralizado (por ejemplo, PDCP-U).
En LTE Versión 13 se introdujo un mecanismo para que la red suspenda al UE en un estado suspendido similar a RRC_EN REPOSO pero con la diferencia de que el UE almacena el contexto del estrato de acceso (AS) o el contexto del RRC. Esto hace posible reducir la señalización cuando el UE vuelve a estar activo reanudando la conexión de RRC, eliminando de este modo la necesidad de establecer la conexión de RRC desde cero. Reducir la señalización puede tener varias ventajas, incluida la reducción de la latencia del UE (por ejemplo, para teléfonos inteligentes que acceden a Internet) y la reducción de la señalización del UE, lo que conduce, además, a una reducción del consumo de energía del UE, especialmente para dispositivos de comunicación de tipo máquina (Machine Type Communication, MTC) que envían muy pocos datos (es decir, siendo la señalización un consumidor principal de energía).
La solución de LTE Versión 13 se basa en que el UE envía un mensaje RRCConnectionResume-Request (Solicitud de reanudación de conexión de RRC) a la red y, en respuesta, recibe un mensaje RRCConnectionResume (Reanudación de conexión de RRC) desde la red. El RRCConnectionResume no está cifrado, pero su integridad está protegida.
Como parte del trabajo estandarizado del 3GPP en 5G, se ha decidido que NR debería soportar un estado RRC_INACTIVO con propiedades similares al estado suspendido en LTE Versión 13. El estado RRC_INACTIVO tiene propiedades ligeramente diferentes en el sentido de que es un estado de RRC separado y no parte del RRC_EN REPOSO, como en LTE. Adicionalmente, la conexión CN/RAN (interfaz NG o N2) se mantiene activa durante RRC_INACTIVO mientras que en LTE estaba suspendida.
La figura 5A es un diagrama de transición de estado a modo de ejemplo que muestra posibles transiciones entre estados de RRC en NR. Las propiedades de los estados mostrados en la figura 5A se resumen a continuación: RRC_EN REPOSO:
- Una DRX específica del UE puede ser configurada mediante las capas superiores;
- movilidad controlada por el UE basada en la configuración de la red;
- El UE:
- monitoriza un canal de localización para localización de CN utilizando 5G-S-TMSI;
- realiza mediciones de celdas vecinas y (re)selección de celdas;
- obtiene información del sistema.
RRC_INACTIVO:
- Una DRX específica del UE puede ser configurada mediante capas superiores o mediante la capa de RRC; - movilidad controlada por el UE basada en la configuración de la red;
- el UE almacena el contexto de AS;
- el UE:
- monitoriza un canal de localización para localización de CN utilizando 5G-S-TMSI, y localización de RAN utilizando I-RNTI;
- realiza mediciones de celdas vecinas y (re)selección de celdas;
- realiza actualizaciones del área de notificación basada en RAN periódicamente y, cuando se desplaza fuera del área de notificación basada en RAN;
- obtiene información del sistema.
RRC_CONECTADO:
- El UE almacena el contexto de AS.
- Transferencia de datos de unidifusión hacia/desde el UE.
- En capas inferiores, el UE puede ser configurado con una DRX específica del UE;
- para los UE que soportan CA, el uso de una o más SCell, agregadas con la SpCell, para un mayor ancho de banda;
- para los UE que soportan DC, utilización de un SCG, agregado con el MCG, para un mayor ancho de banda; - movilidad controlada por la red, es decir, traspaso dentro de NR y hacia/desde la E-UTRAN.
- El UE:
- monitoriza un canal de localización;
- monitoriza los canales de control asociados con el canal de datos compartidos para determinar si los datos están programados para él;
- proporciona información sobre la calidad y la retroalimentación del canal;
- realiza mediciones de celdas vecinas e informes de mediciones;
- obtiene información del sistema.
La figura 5B muestra un diagrama de flujo a modo de ejemplo, entre un equipo de usuario (UE) y un gNB de NR, de diversas operaciones durante un procedimiento de transición de RRC_CONECTADO a RRC_INACTIVO. En la estandarización de NR del 3GPP se ha acordado que la transición de RRC_CONECTADO a RRC_INACTIVO se realiza en una sola etapa, y puede contener un temporizador para actualizaciones periódicas del área de notificación de la RAN (RNA). Se supone que el UE iniciará el temporizador (denominado T380) tras la recepción del mensaje RRCSuspend (o equivalente) mostrado en la figura 5B. También se supone que el UE activará una actualización periódica de RNA tras la expiración de T380. Actualmente, esto se especifica de la siguiente manera en las secciones 5.3.14.3-4 del documento 3GPP TS 38.331:
5.3.14.3 Recepción del RRCSuspend (Suspender RRC) por parte del UE
El UE deberá:
1> retrasar las siguientes acciones definidas en este subapartado X ms desde el momento en que se recibió el mensaje RRCSuspend u, opcionalmente, cuando las capas inferiores indican que la recepción del mensaje RRCSuspend ha sido confirmada con éxito, lo que ocurra antes;
Nota del editor: Cómo establecer el valor de X (ya sea configurable, o fijado en 60 ms, como en LTE, etc.).
1> si el mensaje RRCSuspend incluye idleModeMobilityControlInfo (Información de control de la movilidad en modo de reposo):
2> almacenar la información de prioridad de reselección de celda proporcionada por el idleModeMobilityControlInfo;
2> si el T320 está incluido:
3> iniciar el temporizador T320, con el valor del temporizador ajustado al valor de T320;
1> si no:
2> aplicar la información de prioridad de reselección de celda difundida en la información del sistema; 1> almacenar la siguiente información proporcionada por la red: resumeldentity (Identidad de reanudación), nextHopChainingCount (Recuento de encadenamiento de salto siguiente), ran-PagingCycle (Ciclo de localizaci'n de RAN) y ran-NotificationAreainfo (Información de área de notificación de RAN);
1> restablecer entidades de RLC para todos los SRB y DRB;
1> reiniciar MAC;
1> excepto si el mensaje RRCSuspend se recibió en respuesta a un RRCResumeRequest (Solicitud de reanudación de RRC):
2> almacenar el contexto de AS del UE, incluida la configuración de RRC actual, el contexto de seguridad actual, el estado del PDCP, incluido el estado de ROHC, C-RNTI utilizado en la PCell de origen, el cellIdentity (Identidad de celda) y la identidad de la celda física de la PCell de origen;
1> suspender todos los SRB y DRB, excepto el SRB0;
1> iniciar el temporizador T380, siendo ajustado el valor del temporizador en periodic-RNAU-timer (temporizador de RNAU períodica);
1> indicar la suspensión de la conexión de RRC a capas superiores;
1> configurar las capas inferiores para suspender la protección de integridad y el cifrado;
1> introducir RRC_INACTIVO y realizar los procedimientos tal como se especifica en el documento TS 38.304 5.3.14.4 Expiración de T380 o entrada del UE en una celda que no pertenece a la RNA
El UE deberá:
1> si T380 expira:
2> iniciar el procedimiento de reanudación de la conexión de RRC en 5.3.13 con el valor de causa ajustado a 'ffs';
1> Si el UE entra en una celda que no pertenece a la RNA:
2> iniciar el procedimiento de reanudación de la conexión de RRC en 5.3.13 con el valor de causa ajustado a 'ffs';
Puesto que se ha acordado que las actualizaciones de RNA (RNAU) se realizan utilizando el procedimiento de reanudación de RRC, los procedimientos explicados a continuación se realizan cuando un UE entra en una nueva RNA. Más concretamente, las figuras 6A-6E muestran diagramas de flujo a modo de ejemplo de procedimientos de reanudación de la conexión de RRC que implican que el UE envíe un mensaje RRCResumeRequest a la red, con varias respuestas de red. La figura 6A muestra una reanudación con éxito de la conexión de RRC. La figura 6B muestra un RRCResumeRequest con regreso al establecimiento de la conexión de RRC, que tiene éxito. La figura 6C muestra un RRCResumeRequest seguido de la liberación de la red, que tiene éxito. La figura 6D muestra un RRCResumeRequest seguido de suspensión de red, que tiene éxito. La figura 6E muestra un RRCResumeRequest seguido de un rechazo de la red. Cada una de las respuestas de la red mostradas en las figuras 6B-6E, pueden ser consideradas diferentes modos de rechazar la RRCResumeRequest, utilizando diferentes mensajes.
El UE inicia el procedimiento de reanudación de la conexión de RRC tras la solicitud de las capas superiores, cuando responde a la localización de NG-RAN, o tras activar actualizaciones de RNA mientras el UE está en estado RRC_INACTIVO. Esto se especifica actualmente en la sección 5.3.13.2 del documento 3GPP TS 38.331, de la siguiente manera:
5.3.13.2 Iniciación
El UE inicia el procedimiento cuando las capas superiores solicitan la reanudación de una conexión de RRC, cuando responde a la localización de NG-RAN o tras activar las actualizaciones de RNA mientras el UE está en RRC_INACTIVO.
Tras la iniciación del procedimiento, el UE deberá:
1> aplicar la configuración del canal físico por defecto, tal como se especifica en 9.2.4;
1> aplicar la configuración de programación semipersistente predeterminada, tal como se especifica en 9.2.3;
1> aplicar la configuración principal de MAC predeterminada, tal como se especifica en 9.2.2;
1> aplicar la configuración del CCCH, tal como se especifica en 9.1.1.2;
1 > iniciar el temporizador T300X;
1 > detener el temporizador T380;
1> iniciar la transmisión del mensaje RRCResumeRequest según 5.3.13.2 ....
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------Para el planteamiento de actualizaciones de RNA activadas mientras el UE está en el estado RRC_INACTIVO, el UE envía un mensaje RRCResumeRequest con el valor de causa 'rna-update' (actualización de RNA) (o equivalente). En respuesta, si la red está sobrecargada, se ha acordado que la red puede enviar un mensaje RRCReject (Rechazo de RRC) que contiene un temporizador de espera, que corresponde al diagrama de flujo que se muestra en la figura 6E. La entrega del mensaje RRCReject por parte del UE se especifica actualmente como:
5.3.13.8 Recepción del RRCReject por parte del UE
El UE deberá:
1> detener el temporizador T314;
1> reiniciar el MAC y liberar la configuración del MAC;
1 > iniciar el temporizador T302, con el valor del temporizador ajustado al tiempo de espera;
1> si RRCReject se envía en respuesta a un RRCResumeRequest activado por las capas superiores;
2> informar a las capas superiores sobre el fallo al reanudar la conexión de RRC y acceder a la información relacionada con el control de acceso, tras lo cual el procedimiento finaliza;
El BORRADOR del 3GPP, R2-1804946 da a conocer consideraciones sobre la actualización del procedimiento de actualización de área basada en RAN. El BORRADOR del 3GPP, R2-1806233 da a conocer una introducción de la característica de estado RRC_INACTIVO de la E-UTRAN para una E-UTRAN conectada a 5GC. El BORRADOR del 3GPP, R2-1805357 da a conocer actualizaciones del área de seguimiento desde el estado RRC_INACTIVO.
Actualmente no existe ninguna especificación de las acciones que debe tomar el UE tras recibir un RRCReject, tal como se muestra en la figura 6E en respuesta a un RRCResumeRequest activado debido, por ejemplo, a una RNA periódica. El inicio del procedimiento de reanudación podrá ser por diferentes motivos, por ejemplo:
- después de que el UE entra en una celda que no pertenece a su RNA configurada, el UE realizará una actualización de RNA, es decir, activará un procedimiento de reanudación de RRC enviando un mensaje de solicitud de reanudación de RRC con el valor de causa 'rna-update' (o equivalente);
- tras la llegada de datos de enlace ascendente, el UE realizará un procedimiento de reanudación de RRC enviando un mensaje de solicitud de reanudación de RRC con el valor de causa “mo-data” (Datos móviles) (o equivalente); o
- después de que el UE recibe un mensaje de localización de RAN que contiene el I-RNTI que ha sido asignado al UE, el UE realizará un procedimiento de reanudación de RRC enviando un mensaje de solicitud de reanudación de RRC con el valor de causa 'ran-paging' (Localización de RAN) (o equivalente).
Tras recibir un recibir un Rechazo de RRC en respuesta a una Solicitud de Reanudación activada por la capa de RRC tal como RNA de movilidad (es decir, el UE entra en una celda que no pertenece a su RNA configurada), datos de UL, localización de RAN, no hay descripción de una acción posterior. Según los enfoques convencionales, no hay certeza sobre qué acción tomaría el UE y qué sucede con la funcionalidad de la capa de RRC (actualización de RNA, datos de UL, respuesta de localización de RAN) en este caso. Además de eso, la única acción descrita dice que el UE informa a las capas superiores sobre el fallo en reanudar la conexión de RRC y la información relacionada con control de acceso, tras lo cual el procedimiento finaliza, mientras que, en realidad, la actualización de la RNA y los demás procedimientos son manejados por la capa de RRC / Estrato de acceso.
En el caso específico de actualizaciones de RNA de movilidad, puesto que el Rechazo de RRC puede ser enviado en el SRB0, el UE tampoco tiene certeza sobre si la red ha sido actualizada o no acerca de la ubicación del UE, es decir, podría haber cierta incertidumbre sobre cómo la red debería intentar llegar al UE en RRC_INACTIVO a través de localización de la RAN.
Otro procedimiento que sigue sin estar claro es cuando el UE ha enviado una Solicitud de reanudación de RRC para una actualización de RNA de movilidad, recibida en respuesta un Rechazo de RRC, inició el temporizador de espera y, mientras el temporizador de espera está en ejecución, el UE realiza la reselección de celda posible incluso a una celda que pertenece a la RNA con el que se configuró el UE.
Compendio
La invención se expone en las reivindicaciones adjuntas.
Breve descripción de los dibujos
La figura 1 es un diagrama de bloques de alto nivel de una arquitectura a modo de ejemplo de la red UTRAN evolucionada (E-UTRAN) y una red 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 a modo de ejemplo en términos de sus componentes constituyentes, protocolos e interfaces.
La figura 2B es un diagrama de bloques de capas de protocolo a modo de ejemplo 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 de protocolo de interfaz de radio de LTE a modo de ejemplo desde la perspectiva de la capa PHY.
Las figuras 3A y 3B son diagramas de bloques de ejemplos de estructuras de tramas de radio de LTE de enlace descendente y de enlace ascendente, respectivamente, utilizadas para la operación de dúplex por división de la frecuencia (FDD).
La figura 4 muestra un diagrama de bloques de una arquitectura de red lógica 5G a modo de ejemplo.
Las figuras 5A y 5B muestran un diagrama de transición de estado a modo de ejemplo y un diagrama de flujo a modo de ejemplo, respectivamente, que muestran posibles transiciones entre estados de RRC en NR.
Las figuras 6A, 6B, 6C, 6D y 6E muestran diagramas de flujo a modo de ejemplo de procedimientos de reanudación de conexión de RRC que implican que el UE envíe un mensaje RRCResumeRequest a la red, con diversas respuestas de la red.
La figura 7 ilustra un sistema de comunicación a modo de ejemplo.
La figura 8 es un diagrama de bloques generalizado de un ordenador central que se comunica a través de una estación base con un equipo de usuario a través de una conexión parcialmente inalámbrica.
Las figuras 9-12 son diagramas de flujo que ilustran métodos implementados en un sistema de comunicación que incluye un ordenador central, una estación base y un equipo de usuario.
La figura 13 es un diagrama de bloques que ilustra un nodo de red a modo de ejemplo.
La figura 14 es un diagrama de bloques que ilustra un dispositivo inalámbrico a modo de ejemplo.
La figura 15 es un diagrama de flujo de proceso que ilustra un método a modo de ejemplo, según algunas realizaciones, tal como se realiza en el dispositivo inalámbrico.
La figura 16 es un diagrama de flujo de proceso que ilustra otro método a modo de ejemplo realizado en el dispositivo inalámbrico.
La figura 17 es un diagrama de flujo del proceso que ilustra otro método a modo de ejemplo realizado en el dispositivo inalámbrico.
La figura 18 es un diagrama de flujo de proceso que ilustra otro método a modo de ejemplo realizado en el dispositivo inalámbrico.
La figura 19 es un diagrama de bloques que ilustra una representación funcional de un dispositivo inalámbrico a modo de ejemplo.
Las realizaciones ilustradas en las figuras 16 a 18 y sus descripciones correspondientes no están abarcadas por la redacción de las reivindicaciones, pero se consideran útiles para comprender la invención.
Descripción detallada
Algunas de las realizaciones contempladas en el presente documento se describirán a continuación más completamente con referencia a los dibujos adjuntos. No obstante, otras realizaciones están contenidas dentro del alcance del asunto dado a conocer en el presente documento; el asunto dado a conocer no debe ser interpretado como limitado solamente a las realizaciones establecidas en el presente documento; por el contrario, estas realizaciones se dan a conocer a modo de ejemplo para transmitir el alcance del asunto a los expertos en la materia. Además, los siguientes términos se utilizan a lo largo de la descripción que se proporciona a continuación:
• Nodo de radio:Tal como se utiliza en este documento, un “nodo de radio” puede ser un “nodo de acceso por radio” o un “dispositivo inalámbrico.”
• Nodo de acceso por radio:Tal como se utiliza en este documento, 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 funciona para transmitir y/o recibir señales de manera inalámbrica. Algunos ejemplos de un nodo de acceso por radio incluyen, entre otros, una estación base (por ejemplo, una estación base (gNB) de Nueva radio (NR) en una red de NR de quinta generación (5G) del 3GPP o un Nodo B mejorado o evolucionado (eNB) en una red de LTE del 3GPP), una macro estación base o de alta potencia, una estación base de baja potencia (por ejemplo, una micro estación base, una pico estación base, un eNB doméstico o similar) y un nodo de retransmisión.
• Nodo de red central:Tal como se utiliza en este documento, un “nodo de red central” es cualquier tipo de nodo en una red central. Algunos ejemplos de un nodo de red central incluyen, por ejemplo, una entidad de gestión de la movilidad (MME), una pasarela de red de datos en paquetes (P-GW), una función de exposición de capacidad de servicio (Service Capability Exposure Function, SCEF), o similares.
• Dispositivo inalámbrico:Tal como se utiliza en este documento, un “dispositivo inalámbrico” es cualquier tipo de dispositivo que tiene acceso a (es decir, es atendido por) una red de comunicaciones celulares, mediante la transmisión y/o recepción inalámbrica de señales a uno o varios nodos de acceso por radio. Algunos ejemplos de dispositivo inalámbrico incluyen, entre otros, un UE en una red del 3GPP y un dispositivo de comunicación de tipo máquina (Machine Type Communication, MTC).
•Nodo de red:Tal como se utiliza en este documento, un “nodo de red” es cualquier nodo que forma parte de la red de acceso por radio o de la red central de una red/sistema de comunicaciones celulares.
Cabe señalar que la descripción proporcionada en el presente documento se centra en un sistema de comunicaciones celulares del 3GPP y, por lo tanto, a menudo se utiliza terminología del 3GPP o terminología similar a la terminología del 3GPP. No obstante, los conceptos dados a conocer en el presente documento no están limitados a un sistema del 3GPP. Además, aunque en el presente documento se utiliza el término “celda”, se debe entender que (concretamente con respecto a los conceptos de NR de 5G) se pueden utilizar haces en lugar de celdas y, por lo tanto, los conceptos descritos en el presente documento se aplican por igual tanto a las celdas como a los haces.
En el presente documento se describen diversas realizaciones a modo de ejemplo, tales como métodos, procedimientos y/u operaciones realizadas por un UE en estado RRC_INACTIVO en una red de NR. Estas realizaciones se utilizan solamente con fines ilustrativos, sin limitación. Por ejemplo, los principios de estas realizaciones son igualmente aplicables a otras configuraciones, planteamientos y/o tipos de red incluidos, entre otros:
• UE en estado RRC_INACTIVO en redes de LTE;
• Procedimientos inter-RAT de UE en RRC_INACTIVO, principalmente entre LTE y RAN de NR conectadas a la misma CN (Red central de 5G). En estos planteamientos, el temporizador de actualización periódica de RNA, T380, se define como un temporizador inter-RAT (es decir, sigue funcionando incluso cuando el UE está cambiando de RAT). Si T380 expira cuando el UE está en la otra RAT, el UE realizará una actualización periódica de RNA en esa RAT. Estos planteamientos inter-RAT incluyen:
oUE en RRC_CONNECTED de LTE se suspende en RRC_INACTIVO de LTE, inicia T380, realiza gestión de movilidad y permanece en espera en una celda de NR (es decir, se convierte en RRC_INACTIVO en NR). Mientras está en NR, T380 expira, y el UE intenta realizar una actualización de RNA (con una solicitud de reanudación) en NR. La red puede responder con un RRCReject.
oEl UE en RRC_CONECTADO de NR se suspende a RRC_INACTIVO de NR, inicia T380, realiza gestión de movilidad y permanece en espera en una celda de LTE (es decir, se vuelve RRC_INACTIVO en lTe ). Mientras está en LTE, T380 expira y el UE intenta realizar una actualización de RNA (con una solicitud de reanudación) en NR. La red puede responder con un RRCReject.
En el presente documento se describen diversas realizaciones a modo de ejemplo tales como métodos, procedimientos y/u operaciones realizadas por un UE tras recibir un mensaje RRCReject con un temporizador de espera. Estas realizaciones se utilizan solamente con fines ilustrativos, sin limitación. Por ejemplo, los principios de sus realizaciones son igualmente aplicables a otras configuraciones, planteamientos y/o tipos de red que implican una “funcionalidad de rechazo” por parte de la red, pero sin utilizar este mensaje exacto. Por ejemplo, una liberación de RRC o una liberación de r Rc con configuración de suspensión también puede incluir un temporizador de espera que indique que el UE no accederá al sistema hasta que expire ese temporizador (o el UE realice una reselección de celda). En el caso de que el sistema soporte la “funcionalidad de rechazo” por medio de RRCReject o liberación de RRC, también puede haber diferencias en el comportamiento del UE dependiendo del mensaje que utilice la red para responder al UE. Por ejemplo, el RRCReject normalmente se envía utilizando el SRB0, que no está protegido, mientras que la liberación de RRC con indicación de suspensión (o mensaje equivalente) que mueve los UE al estado RRC_INACTIVO utiliza el SRB1, que está protegido y es seguro. Estos aspectos se explican más adelante con respecto a diversas realizaciones.
También cabe señalar que las técnicas específicas que se describen a continuación se describen en el contexto de actualizaciones de RNA activadas por movilidad. No obstante, las técnicas también pueden ser aplicables a otros planteamientos en los que se activa el procedimiento de reanudación de RRC, por ejemplo, en respuesta a una localización de RAN o a la disponibilidad de datos de enlace ascendente (UL).
En un primer enfoque, que comprende varias realizaciones posibles, el UE, que se puede denominar de manera más general un dispositivo inalámbrico, ajusta el temporizador de RNAU periódica en el valor del temporizador de espera, tras recibir un mensaje que rechaza el UE con un tiempo de espera. (por ejemplo, rechazo o liberación de RRC con un temporizador de espera), donde el mensaje es en respuesta a una actualización de RNA de movilidad (por ejemplo, activada por que el UE entra en una celda que no pertenece a su RNA configurada). El UE inicia el temporizador de espera de rechazo (por ejemplo, T302 en las especificaciones preliminares de NR), ajusta el temporizador de RNAU periódica T380 al mismo valor utilizado para ajustar el temporizador de espera T302 e inicia el temporizador de RNAU periódica. En consecuencia, el UE realiza un intento de RNAU periódica inmediatamente después de que expire el temporizador de espera T302. Este enfoque es especialmente útil en el caso de que el mensaje de rechazo sea enviado en el SRB0, puesto que si este mensaje se enviara en el SRB1, la red podría actualizar el contexto y proporcionar explícitamente un temporizador de RNAU periódica. Una ventaja de ajustar el temporizador de RNAU periódica en el temporizador de espera es que el UE se comporta según el comportamiento definido según el temporizador de RNAU periódica, sin necesidad de especificar acciones excepcionales, y sin dejar pendiente la RNAU de movilidad. Esto puede acelerar la notificación de que el UE ha cambiado las RNA, en muchas circunstancias.
Se puede observar que al ajustar el temporizador de RNAU periódica al temporizador de espera, el UE no realizará una RNAU de movilidad tras la reselección de celda, aunque el temporizador de espera expirará y entonces se le permitirá al UE acceder al sistema. Esto se puede considerar un resultado especialmente útil si se desea evitar una señalización innecesaria, manejándose la localización necesaria en esta situación a través de la localización de la red central.
Desde una perspectiva de red, se puede observar que el comportamiento del UE descrito puede llevar a que la red no reciba una RNAU de movilidad cuando el UE entra en una celda que no pertenece a su RNA configurada. No obstante, puesto que la red sabe que puede ocurrir un rechazo debido a un rechazo en una celda específica sin actualizar necesariamente el contexto del UE sobre esa ocurrencia del rechazo, la red aún puede suponer que el UE está en cobertura, aunque posiblemente no en su RNA configurada. La red puede ser configurada para intentar localizar al UE en la lista de t A i configurada, por ejemplo, si falla el intento inicial en la RNA del UE. Por lo tanto, la red puede intentar de todos modos localizar al UE con localización de RAN.
En una variante del enfoque descrito anteriormente, el UE ajusta el temporizador de RNAU periódica al valor del temporizador de espera solo si recibe una indicación en el mensaje de rechazo de RRC de la red. Esa indicación puede ser algo que establece la red si tiene el contexto de UE disponible pero aún prefiere rechazar el UE.
En otra variante de los enfoques anteriores, tras recibir el mensaje de rechazo en respuesta a una actualización de la RNA de movilidad, el UE inicia el temporizador de espera de rechazo (por ejemplo, T302 en las especificaciones preliminares de NR), reinicia el temporizador de RNAU periódica a un valor predeterminado y lo notifica a la capa de RRC.
En otra variante más de los enfoques anteriores, se puede definir un comportamiento ligeramente diferente en el caso de que la RNAU de movilidad rechazada sea en realidad una RNAU y una TAU de movilidad combinada. Tras recibir el mensaje de rechazo en respuesta a una actualización de la RNA de movilidad, el UE inicia el temporizador de espera de rechazo (por ejemplo, T302 en las especificaciones preliminares de NR), reinicia el temporizador de RNAU periódica a un valor y lo notifica a la capa de RRC. Si se produce una reselección de celda, el UE realiza inmediatamente una actualización del área de seguimiento.
Según otro conjunto de técnicas, el concepto de notificación pendiente se aplica a los problemas explicados anteriormente. Por lo tanto, en algunas realizaciones, tras recibir el mensaje de rechazo (por ejemplo, rechazo de RRC con temporizador de espera) en respuesta a una actualización de la RNA de movilidad (o a otros casos de reanudación), el UE inicia el temporizador de espera de rechazo (por ejemplo, T302 en las especificaciones preliminares de NR), y lo notifica a la capa de RRC, de modo que la capa de RRC (o capa de AS) haga que la actualización de la RNA de movilidad (u otros casos de reanudación, por ejemplo, datos de UL, respuesta de localización de RAN) sea una notificación pendiente que es rastreada por el UE.
Al convertirla en una notificación pendiente, el UE intenta volver a realizar el procedimiento de reanudación tan pronto como se le permita al UE. Por ejemplo:
- Tras la expiración del temporizador de espera T302, la capa de RRC (o capa de AS) solicita al UE que realice el procedimiento de reanudación pendiente (por ejemplo, RNAU de movilidad).
En una variante, ese procedimiento de reanudación posterior, que estaba pendiente, contiene una indicación de que no se trata del primer intento sino de una notificación pendiente. Eso puede indicar a la red que se trata de una notificación tardía. Esto puede ser útil en caso de que la red haya intentado localizar al UE sin éxito en su RNA mientras T302 estaba en ejecución (es decir, el UE fue rechazado al intentar realizar una RNA de movilidad en la celda que no pertenece a su RNA configurada).
Desde una perspectiva de red (por ejemplo, para el caso de RNAU activada por movilidad), se puede observar que al hacer que la RNAU de movilidad esté pendiente en el UE, la red sabe que debe recibir la RNAU de movilidad tan pronto como se le permita al UE enviarlo, lo que puede simplificar la acción de localización de la RAN de la red. Mientras T302 está funcionando, la red puede intentar localizar al UE en su RNA sin una respuesta del UE, pero posteriormente puede intentar la localización de la CN para encontrar al UE en una celda que no pertenece a su RNA. Puede ocurrir un problema adicional si esa RNA de movilidad es una RNA combinada con TAU, es decir, cuando el UE está en una celda que no está dentro de su lista de TAI. En ese caso, se definen las siguientes variantes:
- Si la RNAU de movilidad que está pendiente es una RNAU y una TAU combinadas, es decir, el UE está cruzando la frontera de la RNA y la frontera de la TAU al mismo tiempo, la solicitud de reanudación tiene un valor de causa “señalización de datos móviles” y debe tener mayor prioridad en las políticas de control de acceso; en caso, contrario, el UE puede resultar inalcanzable para la localización tanto de la RAN como de la CN. Otra variante es definir un valor de causa para esta combinación de RNA/TAU en lugar de decir simplemente que se trata de señalización de datos móviles. Otra alternativa es la implementación en la red de priorizar estas solicitudes de reanudación.
En algunas circunstancias, la primera oportunidad permitida para volver a realizar el procedimiento de reanudación puede ser tras la reselección de celda, tras la cual el UE realiza el procedimiento de reanudación pendiente (por ejemplo, RNAU de movilidad) en diversas realizaciones. Como variante, este procedimiento de reanudación posterior puede contener una indicación de que no se trata del primer intento. Esto puede ser útil para la red en caso de que el UE intente realizar una RNAU de movilidad debido a que ha entrado en una celda que no está en su RNA configurada, sea rechazado por la red e inicie T302, y realice una reselección de celda a una celda que está dentro de su RNA configurada mientras T302 está en ejecución.
Desde una perspectiva de red, se puede observar que el UE puede volver a seleccionar una celda que está nuevamente dentro de su RAN configurada. No obstante, enviar la RNA pendiente permite a la red descubrir qué ha sucedido, por ejemplo, en el caso de que la red haya intentado localizar al UE mediante búsqueda de RAN y el UE no haya respondido.
En otra variante de los enfoques anteriores donde el procedimiento de reanudación queda pendiente, el temporizador T380 no se modifica tras la recepción del mensaje de rechazo, en algunas realizaciones, lo que puede simplificar la implementación de la red ya que la red aún puede esperar las RNAU periódicas independientemente de los planteamientos de rechazo.
En algunas realizaciones, el procedimiento pendiente se cambia debido al cambio de cualquiera de las siguientes condiciones:
- el UE entra en una nueva celda,
- el UE obtiene un procedimiento de mayor prioridad, o
- el UE tiene prohibido acceder a la celda objetivo.
Según otro conjunto de técnicas, estrechamente relacionadas con las descritas inmediatamente antes, el procedimiento de reanudación queda pendiente solo bajo ciertas condiciones. En algunas realizaciones, tras recibir el mensaje de rechazo (por ejemplo, rechazo de RRC con temporizador de espera) en respuesta a un mensaje de solicitud de reanudar, el UE inicia el temporizador de espera de rechazo (por ejemplo, T302 en las especificaciones preliminares de NR) y lo notifica a la capa de RRC, por lo que la capa de RRC (o capa de AS) hace que el procedimiento de reanudación sea una notificación pendiente, pero no necesariamente desencadena el procedimiento de reanudar pendiente cuando está permitido, solo cuando se cumplen ciertas condiciones, tal como se describe a continuación:
- Tras la expiración del temporizador de espera T302, el UE solo realiza nuevamente la RNAU de movilidad pendiente si tras la expiración del temporizador el UE todavía permanece en espera en una celda que no está dentro de su RNA configurada. Si tras la expiración del temporizador el UE está en su RNA configurada, el UE descarta la actualización de RNA de movilidad pendiente.
- Tras la reselección de la celda, el UE realiza la RNAU de movilidad pendiente solo si la nueva celda no pertenece a su RNA configurada. En otras palabras, si el UE realiza una reselección de celdas mientras T302 está en ejecución y la nueva celda pertenece a la RNA configurada del UE, el UE descarta la actualización de RNA de movilidad pendiente.
- Tras la reselección de celda y/o la expiración del temporizador de espera T302 solo si la RNAU de movilidad pendiente es una actualización combinada de RNA y área de seguimiento, es decir, el UE realiza la RNAU de movilidad pendiente. En otra variante de este enfoque, tras la reselección de celda y/o la expiración del temporizador de espera T302 solo si la RNAU de movilidad pendiente es una actualización combinada de RNA y área de seguimiento, es decir, el UE realiza una actualización del área de seguimiento en lugar de la RNAU de movilidad, ya que eso permite al UE actualizar tanto la RAN como la CN de su ubicación.
- T ras la activación de una prioridad más alta en el UE (por ejemplo, una llamada de emergencia), el procedimiento de reanudación pendiente se vuelve a activar (independientemente de si T302 está en ejecución) o el procedimiento de reanudación pendiente se descarta y, en su lugar, solo se realiza el procedimiento de mayor prioridad.
- Tras la reselección de la celda, si el UE selecciona una celda que no se considera adecuada para permanecer en espera (por ejemplo, el UE tiene prohibido acceder a la celda), en este caso, el procedimiento de reanudación pendiente puede ser descartado o realizado en una etapa posterior cuando el UE seleccione una celda adecuada.
En otra variante de los enfoques en la que el procedimiento de reanudar queda pendiente, el temporizador T380 no se modifica tras la recepción del mensaje de rechazo, lo que puede simplificar la implementación de la red, ya que la red aún puede esperar RNAU periódicas independientemente de los planteamientos de rechazo.
En otro conjunto más de enfoques, el procedimiento de reanudación no está pendiente. Según algunas realizaciones, tras la expiración del temporizador de espera T302, el UE no tiene que enviar inmediatamente un procedimiento de reanudación (es decir, el RRC y/o las capas superiores no consideran pendiente el mensaje), sino que simplemente confía en las acciones relacionadas con el procedimiento de reanudar tras recibir el mensaje de rechazo del UE. Esto puede crear un problema temporal de accesibilidad desde el lado de la red que podría ser resuelto mediante localización de la CN. Por otro lado, puede simplificar significativamente el comportamiento del UE.
En algunas realizaciones, tras el rechazo, el UE lo notifica a la capa superior y, tras la expiración de T302, el UE realiza el procedimiento de reanudación. Después de recibir un mensaje de rechazo después de intentar realizar una RNAU de movilidad u otro procedimiento de reanudación, el UE lo notifica a las capas superiores y, tras la expiración del temporizador de espera T302, el UE realiza inmediatamente una actualización del área de seguimiento/actualización del área de registro u otro procedimiento de recuperación del NAS. De esta manera, el estado de UE-RAN se reconstruiría a partir de la red central. Esta solución es útil, por ejemplo, si el UE se ha movido a un área diferente de la CN y no ha sido accesible desde la red durante el tiempo de espera.
En una variante de este último enfoque, tras la expiración de T302, el UE descarta el contexto de UE, entra en RRC_EN REPOSO desde RRC_INACTIVO y realiza el procedimiento de nivel de NAS.
En algunas realizaciones, cuando el UE es rechazado al intentar realizar una RNAU de movilidad, el UE inicia el temporizador de espera T302 y continúa monitorizando las notificaciones de la localización de la RAN según su configuración almacenada (proporcionadas cuando el UE se movió a RRC_INACTIVO, es decir, no en el mensaje que rechaza el UE). El UE continúa monitorizando la localización de RAN, ya que la red puede conocer la ubicación actual del UE (la celda actual en la que permanece en espera) a pesar del rechazo de la actualización de RNA de movilidad.
En realizaciones correspondientes desde una perspectiva de red, si la red conoce la ubicación del UE después de rechazar una solicitud de actualización de RNA, la red puede realizar localización de RAN en la nueva celda en la que permanece en espera el UE (es decir, la celda en la que el UE fue rechazado) a pesar de que la celda en la que permanece en espera no necesariamente pertenece a la RNA configurada de ese UE.
En algunas realizaciones, cuando el UE es rechazado al intentar realizar una RNAU de movilidad, el UE inicia el temporizador de espera T302 y deja de monitorizar las notificaciones de localización de RAN según su configuración almacenada (proporcionada cuando el UE se movió a RRC_INACTIVO, es decir, no en el mensaje de rechazo del UE) y solo monitoriza la localización de la CN. El UE continúa monitorizando la localización de la CN para ahorrar batería, ya que es posible que la red de todos modos no conozca la ubicación actual del UE (la celda actual en la que permanece en espera).
En realizaciones correspondientes desde una perspectiva de red, el mensaje de rechazo es enviado en el SRB0, la red puede rechazar al Ue sin actualizar el contexto del UE. Por lo tanto, es posible que el nodo en el que el UE ha intentado realizar la RNAU de movilidad ni siquiera intente recuperar el contexto. Y, si llega una notificación de búsqueda al nodo donde está el contexto, el nodo puede intentar la localización de la RAN en la RNA configurada del UE y, si eso falla, la red puede intentar realmente la localización de la CN. Puesto que la localización de la RAN fallará de todos modos, tras entrar en la RNA y ser rechazado, podría ser útil no continuar monitorizando la localización de la RAN para el UE, ya que es posible que la red no lo intente de todos modos.
En otras realizaciones adicionales, la red puede incluir en el mensaje de rechazo una indicación al UE sobre si el UE continuará realizando la localización de la RAN o no. Esa indicación es básicamente una forma de indicarle al UE que el nodo que tiene el contexto del UE conoce la ubicación del UE a nivel de celda.
En algunas realizaciones, el UE almacena información sobre la recepción de mensajes que rechazan al UE de la red. La información sobre el rechazo puede contener, por ejemplo:
- Un contador, que se incrementa con cada intento rechazado. Ese contador puede ser específico por cada valor de causa, es decir, en este caso específico, para RNAU periódicas.
- La ubicación exacta en la que el UE fue rechazado, por ejemplo, agregando al informe el PCI y/o identificador de celda y/o identificador de celda global y/o PLMN para cada intento rechazado.
La información descrita anteriormente se puede utilizar de diferentes maneras. Por ejemplo, se puede crear un informe a partir de esa información almacenada y notificarlo a la red cuando el UE entra en RRC_CONECTADO. Otra utilización podría ser utilizar la información como entrada a una función de control de acceso de modo que si se activa una RNAU mientras T302 está en ejecución, dependiendo del número de intentos frustrados de las RNAU, la función de control de acceso puede autorizar al UE a enviar una solicitud de reanudación con RNAU.
En otras realizaciones, se define un mecanismo de protección donde después de X intentos de RNAU seguidos por el rechazo de la red (donde X puede estar fijado por el estándar o ser configurable), el UE realiza diferentes acciones:
- En una variante, el UE descarta su contexto de UE y notifica a las capas superiores y/o a la capa de RRC. A continuación, inmediatamente después de que el UE pueda acceder a la red nuevamente (por ejemplo, tras la expiración de T302 o tras la reselección de celda), realiza una recuperación de NAS;
- en otra variante, el UE realiza una reselección de celdas entre frecuencias o una reselección de celdas entre RAT, e intenta realizar una RNAU periódica.
Algunas de las técnicas descritas anteriormente pueden ser implementadas en las especificaciones de RRC de NR de la siguiente manera. En primer lugar, los enfoques en los que se reinicia el temporizador de RNAU periódica se pueden implementar según:
.3.13.8 Recepción del RRCReject por parte del UE
El UE deberá:
1> detener el temporizador T314;
1> reiniciar el MAC y liberar la configuración del MAC;
1 > iniciar el temporizador T302, con el valor del temporizador ajustado al tiempo de espera;
1> reiniciar el temporizador de RNAU periódica T380 a un RRCResumeRequest activado por las capas superiores.
1> si RRCReject se envía en respuesta a un RRCResumeRequest activado por las capas superiores;
2> informar a las capas superiores sobre el fallo al reanudar la conexión de RRC y acceder a la información relacionada con el control de acceso, tras lo cual el procedimiento finaliza
Las realizaciones en las que la RNAU de movilidad queda pendiente pueden ser implementadas según:
5.3.13.8 Recepción del RRCReject por parte del UE
El UE deberá:
1> detener el temporizador T314;
1> reiniciar el MAC y liberar la configuración del MAC;
1 > iniciar el temporizador T302, con el valor del temporizador ajustado al tiempo de espera;
1> detener T380, si está en funcionamiento;
1> si RRCReject se envía en respuesta a un RRCResumeRequest activado por las capas superiores;
2> informar a las capas superiores sobre el fallo al reanudar la conexión de RRC y acceder a la información relacionada con el control de acceso, tras lo cual el procedimiento finaliza;
1> si RRCReject se envía en respuesta a un RRCResumeRequest debido a movilidad (es decir, tras entrar en una celda que no pertenece a su RNA configurada);
2> informar a la capa superior de RRC (o a la capa de AS) sobre el fallo al reanudar la conexión de RRC y acceder a la información relacionada con el control de acceso (es decir, debido al rechazo con el temporizador de rechazo), que considerará la RNAU como pendiente, tras lo cual el procedimiento finaliza;
5.3.13.6 Reselección de celda mientras T314 o T302 está en ejecución
El UE deberá:
1> si se produce una reselección de celda mientras T314 o T302 está en ejecución:
3> detener el temporizador T314 si está en ejecución;
3> detener el temporizador T302 si está en ejecución;
3> reiniciar el MAC, liberar la configuración del MAC y restablecer el RLC para todos los RB que son establecidos; 3> descartar el contexto de seguridad temporal (previamente restaurado) y las claves KRRCenc, KRRCint, KUPint y KUPenc; 3> realizar el procedimiento de reanudación de RRC tal como se especifica en 5.3.13;
5.3.13.x Expiración o detención de T302
El UE deberá:
1> si el temporizador T302 expira o se detiene (por ejemplo, tras la reselección de celda):
2> informar a las capas superiores sobre la eliminación de la prohibición para el acceso de terminación móvil, y activar cualquier actualización de RNA pendiente;
Realizaciones en las que, tras el rechazo, el UE lo notifica a las capas superiores y tras la expiración de T302, el UE realiza la actualización del área de seguimiento y se puede implementar de la siguiente manera:
5.3.13.8 Recepción del RRCReject por parte del UE
El UE deberá:
1> detener el temporizador T314;
1> reiniciar el MAC y liberar la configuración del MAC;
1 > iniciar el temporizador T302, con el valor del temporizador ajustado al tiempo de espera;
1> si RRCReject se envía en respuesta a un RRCResumeRequest activado por las capas superiores;
2> informar a las capas superiores sobre el fallo al reanudar la conexión de RRC y acceder a la información relacionada con el control de acceso, tras lo cual el procedimiento finaliza;
5.3.13.6 Reselección de celda mientras T314 o T302 está en ejecución
El UE deberá:
1> si se produce una reselección de celda mientras T314 o T302 está en ejecución:
3> detener el temporizador T314 si está en ejecución;
3> detener el temporizador T302 si está en ejecución;
3> reiniciar el MAC, liberar la configuración del MAC y restablecer el RLC para todos los RB que están establecidos;
3> descartar el contexto de seguridad temporal (previamente restaurado) y las claves KRRCenc, KRRCint, KUPint y KUPenc;
3> si hay un RRCResumeRequest pendiente (por ejemplo, debido al control de acceso);
4> realizar el procedimiento de reanudación del RRC tal como se especifica en 5.3.13;
5.3.13.x Expiración o detención de T302
El UE deberá:
1> si el temporizador T302 expira o se detiene (por ejemplo, tras la reselección de celda):
2> informar a las capas superiores sobre la eliminación de la prohibición para el acceso de terminación móvil y activar cualquier actualización de RNA pendiente;
La figura 7, según diversas realizaciones, muestra un sistema de comunicación que incluye una red de telecomunicaciones 710, tal como una red celular del tipo de 3GPP, que comprende una red de acceso 711, tal como una gNB-RAN, y una red central 714 (por ejemplo, 5GC). La red de acceso 711 comprende una pluralidad de estaciones base 712a, 712b, 712c, tales como gNB u otros tipos de puntos de acceso inalámbrico, definiendo cada una un área de cobertura 713a, 713b, 713c correspondiente. Cada estación base 712a, 712b, 712c se puede conectar a la red central 714 a través de una conexión cableada o inalámbrica 715. Un primer equipo de usuario (UE) 791 ubicado en el área de cobertura 713c está configurado para conectarse de manera inalámbrica o ser localizado por la correspondiente estación base 712c. Un segundo UE 792 en el área de cobertura 713a se puede conectar de manera inalámbrica a la estación base 712a correspondiente. Si bien en este ejemplo se ilustran una pluralidad de UE 791, 792, las realizaciones dadas a conocer son igualmente aplicables a una situación en la que un solo UE está en el área de cobertura, o donde un solo UE se está conectando a la estación base 712 correspondiente.
La red de telecomunicaciones 710 está conectada a un ordenador central 730, que puede estar incorporado 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 730 puede estar bajo la propiedad o el control de un proveedor de servicios, o puede ser accionado por el proveedor de servicios o en nombre del proveedor de servicios. Las conexiones 721, 722 entre la red de telecomunicaciones 710 y el ordenador central 730 se pueden extender directamente desde la red central 714 al ordenador central 730, o pueden pasar a través de una red intermedia 720 opcional. La red intermedia 720 puede ser una de, o una combinación de, más de una red pública, privada o alojada; la red intermedia 720, si la hay, puede ser una red troncal o Internet; en concreto, la red intermedia 720 puede comprender dos o más subredes (no mostradas).
El sistema de comunicación de la figura 7 en su conjunto permite la conectividad entre uno de los UE 791, 792 conectados y el ordenador central 730. La conectividad se puede describir como una conexión de libre transmisión (Over-The-Top, OTT) 750. El ordenador central 730 y los UE 791, 792 conectados están configurados para comunicar datos y/o señalización a través de la conexión OTT 750, utilizando la red de acceso 711, la red central 714, cualquier red intermedia 720 y posible infraestructura adicional (no mostrada) como intermediarios. La conexión OTT 750 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 750 desconocen el enrutamiento de las comunicaciones de enlace ascendente y descendente. Por ejemplo, una estación base 712 puede no ser informada o no necesita ser informada sobre el enrutamiento pasado de una comunicación de enlace descendente entrante con datos que se originan desde un ordenador central 730 para ser reenviados (por ejemplo, traspasados) a un UE 791 conectado. De manera similar, la estación base 712 no necesita conocer el encaminamiento futuro de una comunicación de enlace ascendente saliente que se origina desde el UE 791 hacia el ordenador central 730.
Implementaciones a modo de ejemplo, según una realización, del UE, estación base y ordenador central explicadas en los párrafos anteriores se describirán a continuación con referencia a la figura 8. En un sistema de comunicación 800, un ordenador central 810 comprende hardware 815 que incluye una interfaz de comunicación 816 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 de comunicación 800. El ordenador central 810 comprende, además, circuitería de procesamiento 818, que pueden tener capacidades de almacenamiento y/o procesamiento. En concreto, la circuitería de procesamiento 818 puede comprender uno o más procesadores programables, circuitos integrados de aplicación específica, conjuntos de puertas programables en campo o combinaciones de estos (no mostradas) adaptados para ejecutar instrucciones. El ordenador central 810 comprende, además, software 811, que se almacena en el ordenador central 810 o es accesible a través del mismo y ejecutable mediante la circuitería de procesamiento 818. El software 811 incluye una aplicación principal 812. La aplicación 812 puede ser accionada para proporcionar un servicio a un usuario remoto, tal como un UE 830 que se conecta a través de una conexión OTT 850 que termina en el UE 830 y el ordenador central 810. Al proporcionar el servicio al usuario remoto, la aplicación principal 812 puede proporcionar datos de usuario que se transmiten mediante la conexión OTT 850.
El sistema de comunicación 800 incluye, además, una estación base 820 proporcionada en un sistema de telecomunicaciones y que comprende hardware 825 que le permite comunicarse con el ordenador central 810 y con el UE 830. El hardware 825 puede incluir una interfaz de comunicación 826 para establecer y mantener una conexión por cable o inalámbrica con una interfaz de un dispositivo de comunicación diferente del sistema de comunicación 800, así como una interfaz de radio 827 para establecer y mantener al menos una conexión inalámbrica 870 con el UE 830 ubicado en un área de cobertura (no mostrada en figura 8) atendida por la estación base 820. La interfaz de comunicación 826 puede ser configurada para facilitar una conexión 860 al ordenador central 810. La conexión 860 puede ser directa o puede pasar a través de una red central (no mostrada en la figura 8) del sistema de telecomunicaciones 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 825 de la estación base 820 incluye, además, circuitería de procesamiento 828, que puede comprender uno o más procesadores programables, circuitos integrados de aplicación específica, conjuntos de puertas programables en campo o combinaciones de estos (no mostradas) adaptados para ejecutar instrucciones. La estación base 820 tiene, además, software 821 almacenado internamente o accesible a través de una conexión externa.
El sistema de comunicación 800 incluye, además, el UE 830 ya mencionado. Su hardware 835 puede incluir una interfaz de radio 837 configurada para establecer y mantener una conexión inalámbrica 870 con una estación base que presta servicio a un área de cobertura en la que se encuentra actualmente el UE 830. El hardware 835 del UE 830 incluye, además, circuitería de procesamiento 838, que pueden comprender uno o más procesadores programables, circuitos integrados de aplicación específica, conjuntos de puertas programables en campo o combinaciones de estos (no mostradas) adaptados para ejecutar instrucciones. El UE 830 comprende, además, software 831, que está almacenado o es accesible por el UE 830 y ejecutable mediante la circuitería de procesamiento 838. El software 831 incluye una aplicación cliente 832. La aplicación cliente 832 puede ser operable para proporcionar un servicio a un ser humano o usuario no humano a través del UE 830, con el soporte del ordenador central 810. En el ordenador central 810, una aplicación principal 812 en ejecución se puede comunicar con la aplicación cliente 832 en ejecución a través de la conexión OTT 850 que termina en el UE 830 y el ordenador central 810. Al proporcionar el servicio al usuario, la aplicación cliente 832 puede recibir datos de solicitud desde la aplicación principal 812 y proporcionar datos del usuario en respuesta a la solicitud de datos. La conexión OTT 850 puede transferir tanto los datos de la solicitud como los datos del usuario. La aplicación cliente 832 puede interactuar con el usuario para generar los datos de usuario que proporciona.
Cabe señalar que el ordenador central 810, la estación base 820 y el UE 830 ilustrados en la figura 8 pueden ser idénticos al ordenador central 730, una de las estaciones base 712a, 712b, 712c y uno de los UE 791, 792 de la figura 7, respectivamente. Es decir, el funcionamiento interno de estas entidades puede ser tal como se muestra en la figura 8 e independientemente, la topología de la red circundante puede ser la de la figura 7.
En la figura 8, la conexión OTT 850 se ha dibujado de manera abstracta para ilustrar la comunicación entre el ordenador central 810 y el equipo de usuario 830 a través de la estación base 820, sin referencia explícita a ningún dispositivo intermediario, y el enrutamiento preciso de mensajes a través de estos dispositivos. La infraestructura de red puede determinar el enrutamiento, que puede ser configurado para ocultarse del UE 830 o del proveedor de servicios que opera el ordenador central 810, o ambos. Mientras la conexión OTT 850 está activa, la infraestructura de red puede tomar, además, decisiones, mediante las cuales cambia dinámicamente el enrutamiento (por ejemplo, basándose en la consideración de equilibrio de carga o en la reconfiguración de la red).
La conexión inalámbrica 870 entre el UE 830 y la estación base 820 está según las explicaciones de las realizaciones descritas a lo largo de esta invención. Una o más de las diversas realizaciones mejoran el rendimiento de los servicios OTT proporcionados al UE 830 utilizando la conexión OTT 850, en la que la conexión inalámbrica 870 forma el último segmento. Más precisamente, se define un comportamiento claro del UE tras la recepción de un rechazo de RRC en respuesta a una actualización de RNA de movilidad, facilitando acciones de red en términos de accesibilidad a través de localización de la RAN. Las técnicas también pueden ser utilizadas para evitar que el UE termine en un estado o celda en el que ya no sea accesible para la red y los servicios de capa superior. De manera más general, los mecanismos descritos en el presente documento evitan la ambigüedad en términos de falta de coincidencia de estado entre el UE y la red. Estas realizaciones darán como resultado un rendimiento mejorado, tal como un rendimiento mejor y/o más consistente, y/o menores retrasos, para los usuarios de la RAN.
Se puede proporcionar un procedimiento de medición con el fin de monitorizar la velocidad de datos, la latencia y otros factores en los que mejoran una o más realizaciones. Puede haber además una funcionalidad de red opcional para reconfigurar la conexión OTT 850 entre el ordenador central 810 y el UE 830, en respuesta a variaciones en los resultados de la medición. El procedimiento de medición y/o la funcionalidad de red para reconfigurar la conexión OTT 850 se puede implementar en el software 811 del ordenador central 810 o en el software 831 del UE 830, o en ambos. En realizaciones, los sensores (no mostrados) pueden ser implementados en o en asociación con dispositivos de comunicación a través de los cuales pasa la conexión OTT 850; los sensores pueden participar en el procedimiento de medición suministrando valores de las cantidades monitorizadas ejemplificadas anteriormente o suministrando valores de otras cantidades físicas a partir de las cuales el software 811,831 puede calcular o estimar las cantidades monitorizadas. La reconfiguración de la conexión OTT 850 puede incluir formato de mensaje, configuraciones de retransmisión, enrutamiento preferente, etc.; la reconfiguración no necesita afectar a la estación base 820, y puede ser desconocida o imperceptible para la estación base 820. Dichos procedimientos y funcionalidades pueden ser conocidos y puestos en práctica en la técnica. En ciertas realizaciones, las mediciones pueden implicar señalización de UE patentada que facilita las mediciones de rendimiento, tiempos de propagación, latencia y similares del ordenador central 810. Las mediciones pueden ser implementadas debido a que el software 811, 831 hace que se transmitan mensajes, en concreto mensajes vacíos o ficticios, utilizando la conexión OTT 850 mientras monitoriza tiempos de propagación, errores, etc.
La figura 9 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según 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 las figuras 7 y 8. Para simplificar la presente invención, en esta sección solo se incluirán referencias a los dibujos de la figura 9. En una primera etapa 910 del método, el ordenador central proporciona datos del usuario. En una subetapa 911 opcional de la primera etapa 910, el ordenador central proporciona los datos del usuario ejecutando una aplicación principal. En una segunda etapa 920, el ordenador central inicia una transmisión que lleva los datos del usuario al UE. En una tercera etapa 930 opcional, la estación base transmite al UE los datos de usuario que fueron transportados en la transmisión que inició el ordenador central, según las explicaciones de las realizaciones descritas a lo largo de esta invención. En una cuarta etapa 940 opcional, el UE ejecuta una aplicación cliente asociada con la aplicación principal ejecutada por el ordenador central.
La figura 10 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según 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 las figuras 7 y 8. Para simplificar la presente invención, en esta sección solo se incluirán referencias a los dibujos de la figura 10. En una primera etapa 1010 del método, el ordenador central proporciona datos del usuario. En una subetapa opcional (no mostrada), el ordenador central proporciona datos del usuario ejecutando una aplicación principal. En una segunda etapa 1020, el ordenador central inicia una transmisión que lleva los datos del usuario al UE. La transmisión puede pasar a través de la estación base, según las explicaciones de las realizaciones descritas a lo largo de esta invención. En una tercera etapa 1030 opcional, el UE recibe los datos del usuario transportados en la transmisión.
La figura 11 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según 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 las figuras 7 y 8. Para simplificar la presente invención, en esta sección solo se incluirán referencias a los dibujos de la figura 11. En una primera etapa 1110 opcional del método, el UE recibe datos de entrada proporcionados por el ordenador central. Adicional o alternativamente, en una segunda etapa 1120 opcional, el UE proporciona datos de usuario. En una subetapa 1121 opcional de la segunda etapa 1120, el Ue proporciona los datos del usuario ejecutando una aplicación cliente. En una subetapa 1111 opcional adicional de la primera etapa 2010, el UE ejecuta una aplicación cliente que proporciona los datos del usuario en reacción a los datos de entrada recibidos proporcionados por el ordenador central. Al proporcionar los datos del usuario, la aplicación cliente ejecutada puede considerar, además, la entrada del usuario recibida del usuario. Independientemente de la manera específica en la que se proporcionaron los datos del usuario, el UE inicia, en una tercera subetapa 1130 opcional, la transmisión de los datos del usuario al ordenador central. En una cuarta etapa 1140 del método, el ordenador central recibe los datos del usuario transmitidos desde el UE, según las explicaciones de las realizaciones descritas a lo largo de esta invención.
La figura 12 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según 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 las figuras 7 y 8. Para simplificar la presente invención, en esta sección solo se incluirán referencias a los dibujos de la figura 12. En una primera etapa 1210 opcional del método, según las explicaciones de las realizaciones descritas a lo largo de esta invención, la estación base recibe datos de usuario del UE. En una segunda etapa 1220 opcional, la estación base inicia la transmisión de los datos de usuario recibidos, al ordenador central. En una tercera etapa 1230, el ordenador central recibe los datos del usuario transportados en la transmisión iniciada por la estación base.
La figura 13 es un diagrama de bloques que ilustra un nodo de red 30 a modo de ejemplo, que puede ser configurado para funcionar como una estación base. El nodo de red 30 puede ser uno de múltiples nodos de red en un sistema basado en la nube que lleva a cabo las técnicas descritas. El nodo de red 30 puede ser, por ejemplo, un eNB o un gNB de 5G. El nodo de red 30 proporciona una interfaz aérea para un dispositivo inalámbrico, por ejemplo, una interfaz aérea 5G para transmisión de enlace descendente y recepción de enlace ascendente, que se implementa a través de antenas 34 y circuitos transceptores 36. Los circuitos transceptores 36 incluye circuitos de transmisión, circuitos de recepción y circuitos de control asociados que están configurados conjuntamente para transmitir y recibir señales según una tecnología de acceso por radio, con el fin de proporcionar comunicación celular o servicios de WLAN si es necesario. Según diversas realizaciones, los servicios de comunicación celular pueden ser operarse según uno cualquiera o más de los estándares celulares 3GPP, GSM, GPRS, WCDMA, HSDPA, LTE, LTE-Advanced y 5G. El nodo de red 30 también incluye circuitería de interfaz de comunicación 38 para comunicarse con nodos en la red central, otros nodos de radio pares y/u otros tipos de nodos en la red.
El nodo de red 30 también incluye uno o más circuitos de procesamiento 32 que están asociados operativamente con y configurados para controlar el circuito de interfaz de comunicación 38 y/o el circuito transceptor 36. La circuitería de procesamiento 32 comprende uno o más procesadores digitales 42, por ejemplo, uno o más microprocesadores, microcontroladores, procesadores de señales digitales (Digital Signal Processor, DSP), matrices de puertas programables en campo (Field Programmable Gate Arrays, FPGA), dispositivos lógicos programables complejos (Complex Programmable Logic Devices, CPLD), circuitos integrados específicos de la aplicación (Application Specific Integrated Circuits, ASIC), o cualquier combinación de ellos. De manera más general, la circuitería de procesamiento 32 puede comprender circuitos fijos o circuitos programables que están especialmente configurados mediante la ejecución de instrucciones de programa que implementan la funcionalidad explicada en el presente documento, o pueden comprender alguna combinación de circuitos fijos y programables. El o los procesadores 42 pueden ser multinúcleo.
La circuitería de procesamiento 32 también incluye una memoria 44. La memoria 44, en algunas realizaciones, almacena uno o más programas informáticos 46 y, opcionalmente, datos de configuración 48. La memoria 44 proporciona almacenamiento no transitorio para el programa informático 46 y puede comprender uno o más tipos de medios legibles por un ordenador, tales como almacenamiento en disco, almacenamiento en memoria de estado sólido o cualquier combinación de los mismos. A modo de ejemplo no limitativo, la memoria 44 puede comprender una o más de memoria SRAM, DRAM, EEPROM y FLASH, que pueden estar en la circuitería de procesamiento 32 y/o separadas de la circuitería de procesamiento 32. En general, la memoria 44 comprende uno o más tipos de medios de almacenamiento legibles por un ordenador que proporcionan almacenamiento no transitorio del programa informático 46 y cualquier dato de configuración 48 utilizado por el nodo de red 30. En este caso, “no transitorio” significa almacenamiento permanente, semipermanente o persistente al menos temporalmente y abarca tanto el almacenamiento a largo plazo en memoria no volátil como el almacenamiento en memoria de trabajo, por ejemplo, para la ejecución de programas.
En algunas realizaciones, la circuitería de procesamiento 32 de uno o más nodos de red 30 conectados a una red inalámbrica está configurada para realizar operaciones para manejar informes de actualización de área con respecto a la red inalámbrica en las técnicas descritas en el presente documento.
La figura 14 ilustra un ejemplo del dispositivo inalámbrico 50 correspondiente que está configurado para realizar las técnicas descritas en el presente documento para que el dispositivo inalámbrico maneje configuraciones de medición. El dispositivo inalámbrico 50 también se puede denominar, en diversos contextos, un dispositivo de comunicación por radio, un UE, un dispositivo objetivo, un UE de dispositivo a dispositivo (D2D), un UE de tipo máquina o un UE capaz de comunicarse de máquina a máquina (M2M), un UE equipado con sensores, un PDA (asistente digital personal, Personal Digital Assistant), una tableta inalámbrica, un terminal móvil, un teléfono inteligente, un equipo integrado en un ordenador portátil (Laptop Embedded Equipment, LEE), un equipo montado en un ordenador portátil (Laptop Mounted Equipment, LME), un dongle de USB inalámbrico, un equipo en las instalaciones del cliente (Customer Premises Equipment, CPE), etc.
El dispositivo inalámbrico 50 se comunica con uno o más nodos de radio o estaciones base, tales como uno o más nodos de red 30, a través de antenas 54 y de un circuito transceptor 56. El circuito transceptor 56 puede incluir circuitos de transmisión, circuitos de recepción y circuitos de control asociados, que están configurados conjuntamente para transmitir y recibir señales según una tecnología de acceso por radio, con el fin de proporcionar servicios de comunicación celular.
El dispositivo inalámbrico 50 también incluye uno o más circuitos de procesamiento 52 que están asociados operativamente con y controlan los circuitos transceptores de radio 56. La circuitería de procesamiento 52 comprende uno o más circuitos de procesamiento digital, por ejemplo, uno o más microprocesadores, microcontroladores, DSP , FPGA, CPLD, ASIC o cualquier combinación de ellos. De manera más general, la circuitería de procesamiento 52 puede comprender circuitos fijos o circuitos programables que están especialmente adaptados mediante la ejecución de instrucciones de programa que implementan la funcionalidad explicada en el presente documento, o pueden comprender alguna combinación de circuitos fijos y programados. La circuitería de procesamiento 52 puede ser multinúcleo.
La circuitería de procesamiento 52 también incluye una memoria 64. La memoria 64, en algunas realizaciones, almacena uno o más programas informáticos 66 y, opcionalmente, datos de configuración 68. La memoria 64 proporciona almacenamiento no transitorio para el programa informático 66 y puede comprender uno o más tipos de medios legibles por un ordenador, tales como almacenamiento en disco, almacenamiento en memoria de estado sólido o cualquier combinación de los mismos. A modo de ejemplo no limitativo, la memoria 64 comprende una o más de las memorias SRAM, DRAM, EEPROM y FLASH, que pueden estar en la circuitería de procesamiento 52 y/o separadas de la circuitería de procesamiento 52. En general, la memoria 64 comprende uno o más tipos de medios de almacenamiento legibles por un ordenador que proporcionan almacenamiento no transitorio del programa informático 66 y cualquier dato de configuración 68 utilizado por el dispositivo inalámbrico 50.
En consecuencia, en algunas realizaciones, la circuitería de procesamiento 52 del dispositivo inalámbrico 50 está configurada para operar en una red inalámbrica y manejar informes de actualización de área.
La circuitería de procesamiento 52 está configurada para iniciar una RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico. La circuitería de procesamiento 52 también está configurada para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado. El mensaje incluye o va acompañado de una indicación de que es aplicable un valor de tiempo de espera. La circuitería de procesamiento 52 también está configurada para, en respuesta al mensaje, ajustar un temporizador de espera de rechazo en el valor del tiempo de espera y realizar la RNAU al expirar el temporizador de espera de rechazo, entrando en un estado RRC_INACTIVO desde un estado RRC_CONEC<t>A<d>O.
La figura 15 es un diagrama de flujo de proceso que ilustra un método 1500 correspondiente implementado en el dispositivo inalámbrico 50 para manejar informes de actualización de área. El método 1500 incluye iniciar una RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a un RNA configurada para el dispositivo inalámbrico (bloque 1502). El método 500 incluye recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNA<u>ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera (bloque 1504). El método 500 también incluye, en respuesta al mensaje, ajustar un temporizador de espera de rechazo al valor del tiempo de espera (bloque 1506) y realizar la RNAU al expirar el temporizador de espera de rechazo (bloque 1508). En algunas realizaciones, el dispositivo inalámbrico también ajusta un temporizador de RNAU periódica al valor del tiempo de espera, en respuesta al mensaje, y realiza la RNAU tras la expiración del temporizador de espera de rechazo y el temporizador de RNAU periódica.
En algunas realizaciones, el dispositivo inalámbrico está en un estado inactivo de la conexión de recursos de radio (RRC), e iniciar la RNAU incluye el envío de una solicitud de reanudar una conexión de RRC. El mensaje puede incluir un mensaje de rechazo de reanudación de RRC o un mensaje de liberación de RRC.
En algunas realizaciones, el temporizador de espera de rechazo es el temporizador T302 especificado por el 3GPP, y el temporizador de RNAU periódica es el temporizador T380 especificado por el 3GPP.
En algunas realizaciones, el método comprende, además, rastrear la RNAU como una notificación pendiente mientras el temporizador de espera de rechazo está en ejecución. En algunas realizaciones, ajustar el temporizador de RNAU periódica al valor del tiempo de espera puede responder a una indicación en el mensaje de que el temporizador de RNAU periódica se debe ajustar al valor del tiempo de espera. El dispositivo inalámbrico se abstiene de realizar una actualización RNAU tras la reselección de la celda antes de la expiración del temporizador de espera de rechazo.
Según algunas realizaciones, el dispositivo inalámbrico 50 está configurado para realizar otro método para manejar los informes de actualización del área. En este caso, la circuitería de procesamiento 52 está configurada para iniciar una RNAU y una TAU combinadas, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico y que no pertenece a un área de seguimiento configurada para el dispositivo inalámbrico. La circuitería de procesamiento 52 también está configurada para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU y la TAU combinadas ha sido rechazado, comprendiendo el mensaje o estando acompañado por una indicación de que un valor de tiempo de espera es aplicable. La circuitería de procesamiento 52 está configurada para, en respuesta al mensaje, ajustar un temporizador de espera de rechazo al valor del tiempo de espera y realizar posteriormente una reselección de celda, antes de que expire el temporizador de espera de rechazo. La circuitería de procesamiento 52 está configurado para realizar inmediatamente una TAU, después de la reselección de celda.
La circuitería de procesamiento 52 también está configurada para realizar un método 1600 correspondiente, según algunas realizaciones. El método 1600 mostrado en la figura 16 incluye iniciar una RNAU y una TAU combinadas, en respuesta a detectar que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico y que no pertenece a un área de seguimiento configurada para el dispositivo inalámbrico (bloque 1602). El método 1600 incluye recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU y la TAU combinadas ha sido rechazado, comprendiendo o estando acompañado el mensaje por una indicación de que es aplicable un valor de tiempo de espera (bloque 1604). El método 1600 también incluye, en respuesta al mensaje, ajustar un temporizador de espera de rechazo al valor del tiempo de espera (bloque 1606). El método 1600 incluye, además, realizar posteriormente una reselección de celda, antes de que expire el temporizador de espera de rechazo (bloque 1608) y realizar inmediatamente una TAU, después de la reselección de celda (bloque 1600).
Según algunas realizaciones, el dispositivo inalámbrico 50 está configurado para realizar otro método para manejar informes de actualización de área. En este caso, la circuitería de procesamiento 52 está configurada para iniciar una RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico. La circuitería de procesamiento 52 está configurada para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera. La circuitería de procesamiento 52 está configurada, además, para, en respuesta al mensaje, ajustar un temporizador de espera de rechazo al valor del tiempo de espera y notificar el rechazo a la capa de RRC del dispositivo inalámbrico. En algunas realizaciones, la circuitería de procesamiento 52 está configurada, además, para, en respuesta al mensaje, ajustar un temporizador de RNAU periódica a un valor predeterminado.
La circuitería de procesamiento 52 también está configurada para realizar un método 1700 correspondiente, según algunas realizaciones. El método 1700 mostrado en la figura 17 incluye iniciar una RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico (bloque 1702). El método 1700 también incluye recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNA<u>ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera (bloque 1704). El método 1700 incluye, además, en respuesta al mensaje, ajustar un temporizador de espera de rechazo al valor del tiempo de espera, y notificar el rechazo a la capa de RRC del dispositivo inalámbrico (bloque 1706). En algunas realizaciones, el método comprende, además, en respuesta al mensaje, ajustar un temporizador de RNAU periódica a un valor predeterminado.
Según algunas realizaciones, el dispositivo inalámbrico 50 está configurado para realizar otro método más para manejar informes de actualización de área. En este caso, la circuitería de procesamiento 52 está configurada para iniciar una RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico. La circuitería de procesamiento 52 también está configurada para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera. La circuitería de procesamiento 52 está configurada para, en respuesta al mensaje, rastrear la RNAU rechazada como una notificación pendiente, de tal manera que la RNAU rechazada se intenta nuevamente tan pronto como se permita y/o tan pronto como se cumplan ciertas condiciones.
La circuitería de procesamiento 52 también está configurada para realizar un método correspondiente 1800, según algunas realizaciones. El método 1800 mostrado en la figura 18 incluye iniciar una RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico (bloque 1802). El método 1800 también incluye recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNA<u>ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera (bloque 1804). El método 1800 incluye, además, en respuesta al mensaje, rastrear la RNAU rechazada como una notificación pendiente, de tal manera que la RNAU rechazada se intenta nuevamente tan pronto como se permita y/o tan pronto como se cumplan ciertas condiciones (bloque 1806).
El método 1800 puede incluir, además, intentar la RNAU rechazada nuevamente en respuesta a la expiración de un temporizador de espera de rechazo. Intentar la RNAU rechazada puede responder, además, a la determinación de que el dispositivo inalámbrico todavía permanece en espera en una celda fuera de la RNA configurada para el dispositivo inalámbrico, cuando expira el temporizador de espera de rechazo. Intentar la RNAU rechazada también puede responder además a la determinación de que la RNAU rechazada es una RNAU y una TAU combinadas.
En algunas realizaciones, el método 1800 puede incluir intentar la RNAU rechazada nuevamente en respuesta a una reselección de celda. Intentar la RNAU rechazada puede responder, además, a la determinación de que la reselección de celda es para una celda que no está en la RNAU configurada para el dispositivo inalámbrico. Intentar la RNAU rechazada puede responder además a la determinación de que la RNAU rechazada es una RNAU y una TAU combinadas.
En algunas realizaciones, intentar nuevamente la RNAU rechazada incluye enviar una solicitud de reanudar una conexión de RRC, a la red inalámbrica, indicando la solicitud de reanudar una conexión de RRC que el mensaje Reanudar conexión de RRC corresponde a una notificación pendiente.
En otras realizaciones, el dispositivo inalámbrico está en un estado de RRC Inactivo, e iniciar la RNAU comprende enviar una solicitud de reanudar una conexión de RRC. El mensaje puede incluir un mensaje de rechazo de reanudación de RRC o un mensaje de liberación de RRC.
El método 1800 puede incluir continuar monitorizando la localización de la red de acceso por radio (RAN) según una configuración almacenada, después de recibir el mensaje. El método 1800 también puede incluir monitorizar solo la localización de la red central (CN), después de recibir el mensaje.
Tal como se analizó en detalle anteriormente, las técnicas descritas en el presente documento, por ejemplo, tal como se ilustra en los diagramas de flujo de proceso de las figuras 15-18, se pueden implementar, en su totalidad o en parte, utilizando instrucciones de programa informático ejecutadas por uno o más procesadores. Se apreciará que una implementación funcional de estas técnicas puede ser representada en términos de módulos funcionales, donde cada módulo funcional corresponde a una unidad funcional de software que se ejecuta en un procesador apropiado, o a un circuito de hardware digital funcional, o alguna combinación de ambos.
La figura 19 ilustra un ejemplo de módulo funcional o arquitectura de circuito que se puede implementar en un dispositivo inalámbrico 50. La implementación incluye un módulo de iniciación 1902 para iniciar una RNAU, que responde a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico. La implementación también incluye un módulo de recepción 1904 para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera. La implementación también incluye un módulo de configuración 1906 para, en respuesta al mensaje, ajustar un temporizador de espera de rechazo y un temporizador de RNAU periódica al valor del tiempo de espera, y un módulo de realización 1908 para realizar la RNAU al expirar el temporizador de espera de rechazo y el temporizador de RNAU periódica.
En otra implementación de ejemplo, el módulo de iniciación 1902 es para iniciar una RNAU y una TAU combinadas, en respuesta a detectar que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico y que no pertenece a un área de seguimiento configurada para el dispositivo inalámbrico. El módulo de recepción 1904 es para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU y la TAU combinadas ha sido rechazado, comprendiendo el mensaje o estando acompañado por una indicación de que es aplicable un valor de tiempo de espera. El módulo de configuración 1906 sirve para, en respuesta al mensaje, ajustar un temporizador de espera de rechazo al valor del tiempo de espera, y reiniciar un temporizador de RNAU periódica. El módulo de realización 1908 sirve para realizar posteriormente una reselección de celdas, antes de que expire el temporizador de RNAU periódica y para realizar inmediatamente una TAU, después de la reselección de celdas.
En otra implementación a modo de ejemplo, el módulo de iniciación 1902 es para iniciar una RNAU, en respuesta a detectar que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico, y el módulo de recepción 1904 es para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado, comprendiendo o estando acompañado el mensaje por una indicación de que es aplicable un valor de tiempo de espera. El módulo de configuración 1906 sirve para, en respuesta al mensaje, ajustar un temporizador de espera de rechazo al valor del tiempo de espera, ajustar un temporizador de RNAU periódica a un valor predeterminado y notificar el rechazo a la capa de RRC del dispositivo inalámbrico.
En otra implementación a modo de ejemplo, el módulo de iniciación 1902 es para iniciar una RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a una RNA configurada para el dispositivo inalámbrico. El módulo de recepción 1904 sirve para recibir, desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera. La implementación también puede incluir un módulo de ajuste 1910 para, en respuesta al mensaje, rastrear la RNAU rechazada como una notificación pendiente, de tal manera que la RNAU rechazada se intenta nuevamente tan pronto como se permita y/o tan pronto como se cumplan ciertas condiciones.
Claims (9)
1. Un método para un dispositivo inalámbrico que opera en una red inalámbrica, para el manejo de informes de actualización de área, comprendiendo el método:
iniciar (1502) una actualización del área de la red de radio, RNAU, en respuesta a la detección de que el dispositivo inalámbrico ha entrado en una celda que no pertenece a un área de la red de radio, RNA, configurada para el dispositivo inalámbrico;
recibir (1504), desde la red inalámbrica, un mensaje que indica que el intento del dispositivo inalámbrico de realizar la RNAU ha sido rechazado, comprendiendo el mensaje o estando acompañado de una indicación de que es aplicable un valor de tiempo de espera;
en respuesta al mensaje, ajustar (1506) un temporizador de espera de rechazo al valor del tiempo de espera; caracterizado por:
realizar (1508) la RNAU tras la expiración del temporizador de espera de rechazo.
2. El método de la reivindicación 1, en el que el dispositivo inalámbrico está en un estado inactivo de la conexión de recursos de radio, RRC, y en el que iniciar (1502) la RNAU comprende enviar una solicitud de reanudar una conexión de RRC.
3. El método de la reivindicación 2, en el que el mensaje comprende un mensaje de rechazar reanudación de RRC o un mensaje de liberación de RRC.
4. El método de cualquiera de las reivindicaciones 1 a 3, en el que el temporizador de espera de rechazo es el temporizador T302 especificado por el proyecto de asociación de tercera generación, 3GPP.
5. El método de cualquiera de las reivindicaciones 1 a 4, en el que el método comprende, además,
en respuesta al mensaje, ajustar un temporizador de RNAU periódica al valor del tiempo de espera, y en el que el método comprende realizar (1508) la RNAU tras la expiración del temporizador de espera de rechazo y el temporizador de RNAU periódica.
6. El método de la reivindicación 5, en el que el temporizador de RNAU periódica es el temporizador T380 especificado por el 3GPP.
7. El método de la reivindicación 5 o 6, en el que dicho ajuste (1506) del temporizador de RNAU periódica al valor del tiempo de espera responde a una indicación en el mensaje de que el temporizador de RNAU periódica debe ser ajustado al valor del tiempo de espera.
8. El método de cualquiera de las reivindicaciones 1 a 7, en el que el método comprende, además, rastrear la RNAU como una notificación pendiente mientras se ejecuta el temporizador de espera de rechazo.
9. Un dispositivo inalámbrico adaptado para realizar un método según cualquiera de las reivindicaciones 1 a 8.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862667969P | 2018-05-07 | 2018-05-07 | |
| PCT/SE2019/050400 WO2019216809A1 (en) | 2018-05-07 | 2019-05-07 | Methods and apparatuses for handling radio access network notification area (rna) update configuration upon reject |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2966758T3 true ES2966758T3 (es) | 2024-04-24 |
Family
ID=66589863
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES19724956T Active ES2966758T3 (es) | 2018-05-07 | 2019-05-07 | Método y aparato para manejar la configuración de la actualización del área de notificación de la red de acceso por radio (RNA) tras un rechazo |
Country Status (10)
| Country | Link |
|---|---|
| US (3) | US11012848B2 (es) |
| EP (1) | EP3791623B1 (es) |
| JP (2) | JP7280891B2 (es) |
| CN (1) | CN112088542B (es) |
| CO (1) | CO2020013580A2 (es) |
| ES (1) | ES2966758T3 (es) |
| MX (1) | MX2020011703A (es) |
| PL (1) | PL3791623T3 (es) |
| WO (1) | WO2019216809A1 (es) |
| ZA (1) | ZA202006254B (es) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107666683B (zh) * | 2016-07-29 | 2019-08-30 | 电信科学技术研究院 | 一种无线系统区域管理的方法、终端及基站 |
| MX2020011703A (es) * | 2018-05-07 | 2020-12-10 | Ericsson Telefon Ab L M | Metodos y aparatos para manejar la configuracion de actualizacion de area de notificacion de red de acceso por radio (rna) luego de rechazo. |
| US11178719B2 (en) * | 2018-05-07 | 2021-11-16 | Htc Corporation | Device and method of handling an radio resource control resume procedure |
| US11700649B2 (en) * | 2018-05-10 | 2023-07-11 | Samsung Electronics Co., Ltd. | Method and apparatus for supporting network connection of terminal in next generation mobile communication system |
| EP3791684A1 (en) * | 2018-05-10 | 2021-03-17 | Telefonaktiebolaget LM Ericsson (publ) | Ue behavior with rejection of resume request |
| EP3834482B1 (en) * | 2018-08-10 | 2023-04-19 | FG Innovation Company Limited | Method and apparatus for rrc state transition |
| WO2020042118A1 (zh) * | 2018-08-30 | 2020-03-05 | 北京小米移动软件有限公司 | 接入控制方法、装置及存储介质 |
| CN114145045B (zh) * | 2020-07-03 | 2024-04-23 | 北京小米移动软件有限公司 | 接入控制的方法、装置、通信设备及存储介质 |
| US11889470B2 (en) * | 2020-09-18 | 2024-01-30 | Parallel Wireless, Inc. | Paging optimization |
| WO2022170477A1 (zh) * | 2021-02-09 | 2022-08-18 | Oppo广东移动通信有限公司 | 无线通信方法、终端设备和网络设备 |
| WO2022205360A1 (en) * | 2021-04-01 | 2022-10-06 | Lenovo (Beijing) Limited | Method and apparatus for location notification and small data transmission in radio resource control inactive state |
| CN113179543B (zh) * | 2021-04-16 | 2022-12-27 | Oppo广东移动通信有限公司 | 一种恢复rrc连接的方法及终端、计算机存储介质 |
| CN113286344B (zh) * | 2021-05-19 | 2023-04-07 | 深圳传音控股股份有限公司 | 控制方法、移动终端及存储介质 |
| WO2023102926A1 (zh) * | 2021-12-10 | 2023-06-15 | 北京小米移动软件有限公司 | 信息传输方法、装置、通信设备和存储介质 |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2715887C (en) * | 2009-10-02 | 2015-11-24 | Research In Motion Limited | Apparatus and method for handling a connection reject message |
| US8526945B2 (en) * | 2011-03-31 | 2013-09-03 | Alcatel Lucent | Tracking and paging at boundries in LTE networks |
| CN103037348B (zh) * | 2011-09-30 | 2017-11-07 | 中兴通讯股份有限公司 | 一种跟踪区更新方法及系统 |
| US9008043B2 (en) * | 2011-09-30 | 2015-04-14 | Lg Electronics Inc. | Method for processing data associated with location area update in a wireless communication system |
| WO2013137698A1 (ko) * | 2012-03-16 | 2013-09-19 | 엘지전자 주식회사 | 무선 통신 시스템에서 nas 시그널링 요청 처리 방법 및 장치 |
| US9247575B2 (en) * | 2012-03-27 | 2016-01-26 | Blackberry Limited | eNB storing RRC configuration information at another network component |
| USRE48671E1 (en) * | 2012-05-09 | 2021-08-03 | Nokia Technologies Oy | Handling tracking area update reject without extended delay |
| CN104396336B (zh) * | 2012-06-19 | 2018-05-01 | 诺基亚技术有限公司 | 用于蜂窝连接管理的方法和装置 |
| US8644824B1 (en) * | 2012-07-13 | 2014-02-04 | Sprint Spectrum L.P. | Tracking registration buffer in a cellular network |
| US9123029B2 (en) * | 2012-10-03 | 2015-09-01 | International Business Machines Corporation | Delayed display of electronic messages |
| US9693254B2 (en) * | 2012-10-04 | 2017-06-27 | Lg Electronics Inc. | Method for reporting denied connection in wireless communication system and apparatus supporting same |
| US9088586B2 (en) * | 2012-12-03 | 2015-07-21 | At&T Mobility Ii Llc | Apparatus and method for managing requests for service |
| WO2014148782A1 (ko) * | 2013-03-18 | 2014-09-25 | 에스케이텔레콤 주식회사 | 다수 캐리어 시스템에서 단말의 동작 방법 |
| WO2014163363A1 (en) * | 2013-04-01 | 2014-10-09 | Samsung Electronics Co., Ltd. | Location registration method and apparatus of terminal in mobile communication system |
| WO2016126109A1 (ko) | 2015-02-03 | 2016-08-11 | 엘지전자 주식회사 | 네트워크 선택 및 트래픽 라우팅을 수행하는 방법 및 사용자 장치 |
| KR102452940B1 (ko) * | 2015-09-24 | 2022-10-11 | 삼성전자 주식회사 | 무선 통신 시스템에서 이동성 향상을 위한 방법 및 장치 |
| US10820241B2 (en) | 2016-02-15 | 2020-10-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Network nodes and methods performed therein for enabling communication in a communication network |
| KR102468945B1 (ko) * | 2016-03-08 | 2022-11-21 | 삼성전자 주식회사 | 핸드오버를 지원하는 방법 및 장치 |
| US10314099B2 (en) * | 2016-07-02 | 2019-06-04 | Intel IP Corporation | Communication protocol recovery system and method |
| US10051473B2 (en) * | 2016-08-12 | 2018-08-14 | Apple Inc. | Secure connection release and network redirection |
| JP7012716B2 (ja) * | 2016-10-24 | 2022-01-28 | クアルコム，インコーポレイテッド | 禁止エリア手順および接続解放管理 |
| CN108040367B (zh) | 2016-11-04 | 2019-09-17 | 电信科学技术研究院 | 一种ue位置区域更新方法、接入网实体、ue及核心网实体 |
| US11259208B2 (en) * | 2017-06-08 | 2022-02-22 | Lg Electronics Inc. | Overload control method in wireless communication system and device for same |
| EP3643095B1 (en) * | 2017-06-27 | 2022-01-26 | LG Electronics Inc. | Method for performing rlau procedure and device supporting the same |
| CN109451880B (zh) * | 2017-09-21 | 2022-11-18 | 北京小米移动软件有限公司 | 网络连接方法及装置 |
| CN111989947A (zh) * | 2018-04-02 | 2020-11-24 | 夏普株式会社 | 用于无线通信中的组合区域更新和点播系统信息请求的装置和方法 |
| EP3791681B1 (en) | 2018-05-07 | 2023-04-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for suspending inactive when resuming and resuming inactive when suspending |
| MX2020011703A (es) * | 2018-05-07 | 2020-12-10 | Ericsson Telefon Ab L M | Metodos y aparatos para manejar la configuracion de actualizacion de area de notificacion de red de acceso por radio (rna) luego de rechazo. |
| CN114727426A (zh) | 2021-01-05 | 2022-07-08 | 夏普株式会社 | 数据传输方法以及用户设备 |
-
2019
- 2019-05-07 MX MX2020011703A patent/MX2020011703A/es unknown
- 2019-05-07 ES ES19724956T patent/ES2966758T3/es active Active
- 2019-05-07 WO PCT/SE2019/050400 patent/WO2019216809A1/en unknown
- 2019-05-07 PL PL19724956.8T patent/PL3791623T3/pl unknown
- 2019-05-07 JP JP2020557964A patent/JP7280891B2/ja active Active
- 2019-05-07 US US16/466,546 patent/US11012848B2/en active Active
- 2019-05-07 CN CN201980030821.0A patent/CN112088542B/zh active Active
- 2019-05-07 EP EP19724956.8A patent/EP3791623B1/en active Active
-
2020
- 2020-10-08 ZA ZA2020/06254A patent/ZA202006254B/en unknown
- 2020-10-28 CO CONC2020/0013580A patent/CO2020013580A2/es unknown
-
2021
- 2021-04-16 US US17/232,329 patent/US11792635B2/en active Active
-
2023
- 2023-02-14 JP JP2023020933A patent/JP7433488B2/ja active Active
- 2023-09-12 US US18/367,011 patent/US20230422015A1/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| CO2020013580A2 (es) | 2020-11-20 |
| EP3791623C0 (en) | 2023-11-15 |
| US11012848B2 (en) | 2021-05-18 |
| JP7433488B2 (ja) | 2024-02-19 |
| JP7280891B2 (ja) | 2023-05-24 |
| US20210235256A1 (en) | 2021-07-29 |
| JP2023062059A (ja) | 2023-05-02 |
| US20200120477A1 (en) | 2020-04-16 |
| WO2019216809A1 (en) | 2019-11-14 |
| PL3791623T3 (pl) | 2024-04-15 |
| JP2021522707A (ja) | 2021-08-30 |
| EP3791623A1 (en) | 2021-03-17 |
| US20230422015A1 (en) | 2023-12-28 |
| ZA202006254B (en) | 2022-01-26 |
| CN112088542A (zh) | 2020-12-15 |
| CN112088542B (zh) | 2024-04-30 |
| EP3791623B1 (en) | 2023-11-15 |
| US11792635B2 (en) | 2023-10-17 |
| MX2020011703A (es) | 2020-12-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2966758T3 (es) | Método y aparato para manejar la configuración de la actualización del área de notificación de la red de acceso por radio (RNA) tras un rechazo | |
| US11943062B2 (en) | Method and apparatus for performing light connection in wireless communication system | |
| US11889577B2 (en) | Methods for handling periodic radio access network notification area (RNA) update configuration upon reject | |
| EP3481139B1 (en) | Method and device for performing service request procedure in wireless communication system | |
| ES2947134T3 (es) | Métodos para suspender la inactividad en reanudaciones y reanudar la inactividad en suspensiones | |
| BR112016029900B1 (pt) | Equipamento de usuário e estação base para mecanismos de sinalização pelo ar leve em comunicações de dados | |
| ES2963419T3 (es) | Verificación de la seguridad cuando se reanuda una conexión de RRC | |
| CN118102436A (zh) | 用于处置拒绝时的无线电接入网通知区域（rna）更新配置的方法和设备 |