ES2961827T3 - Solicitud de reanudación seguida por liberación y redirección - Google Patents
Solicitud de reanudación seguida por liberación y redirección Download PDFInfo
- Publication number
- ES2961827T3 ES2961827T3 ES22171190T ES22171190T ES2961827T3 ES 2961827 T3 ES2961827 T3 ES 2961827T3 ES 22171190 T ES22171190 T ES 22171190T ES 22171190 T ES22171190 T ES 22171190T ES 2961827 T3 ES2961827 T3 ES 2961827T3
- Authority
- ES
- Spain
- Prior art keywords
- rrc
- release
- resume
- network
- message
- 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 claims abstract description 141
- 238000004891 communication Methods 0.000 claims abstract description 59
- 230000004044 response Effects 0.000 claims abstract description 18
- 238000005516 engineering process Methods 0.000 claims abstract description 8
- 230000007774 longterm Effects 0.000 claims description 4
- 238000012508 change request Methods 0.000 claims 2
- 230000006870 function Effects 0.000 description 42
- 238000012545 processing Methods 0.000 description 28
- 230000011664 signaling Effects 0.000 description 27
- 230000007704 transition Effects 0.000 description 25
- 230000008569 process Effects 0.000 description 24
- 230000008859 change Effects 0.000 description 21
- 238000007726 management method Methods 0.000 description 13
- 238000005259 measurement Methods 0.000 description 13
- 230000003993 interaction Effects 0.000 description 12
- 230000005540 biological transmission Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 10
- 230000009471 action Effects 0.000 description 8
- 230000006978 adaptation Effects 0.000 description 8
- 230000010267 cellular communication Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 239000000725 suspension Substances 0.000 description 4
- CSRZQMIRAZTJOY-UHFFFAOYSA-N trimethylsilyl iodide Substances C[Si](C)(C)I CSRZQMIRAZTJOY-UHFFFAOYSA-N 0.000 description 4
- 230000004913 activation Effects 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 238000005457 optimization Methods 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 102100022734 Acyl carrier protein, mitochondrial Human genes 0.000 description 2
- 101000678845 Homo sapiens Acyl carrier protein, mitochondrial Proteins 0.000 description 2
- 101001055444 Homo sapiens Mediator of RNA polymerase II transcription subunit 20 Proteins 0.000 description 2
- 102100026165 Mediator of RNA polymerase II transcription subunit 20 Human genes 0.000 description 2
- 238000007792 addition Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 101150119040 Nsmf gene Proteins 0.000 description 1
- 101150096310 SIB1 gene Proteins 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000002779 inactivation Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
-
- 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
- H04W36/00—Hand-off or reselection arrangements
- H04W36/04—Reselecting a cell layer in multi-layered cells
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/08—Reselecting an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- 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
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/30—Connection release
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
En el presente documento se proporcionan métodos y sistemas para la solicitud de currículum seguido de la liberación y la redirección. Según un aspecto, un método realizado por un Equipo de Usuario para comunicarse dentro de una red de telecomunicaciones comprende: mientras está en un estado INACTIVO de Control de Recursos de Radio (RRC), enviar, a una estación base, una solicitud para reanudar la comunicación y, sin ingresar un estado RRC CONNECED, que recibe, desde la estación base, una instrucción para liberar y redirigir; y en respuesta a recibir la instrucción de liberar y redirigir, realizar la selección de celda en una Tecnología de Acceso por Radio e intentar establecer o reanudar la comunicación con la celda seleccionada. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Solicitud de reanudación seguida por liberación y redirección
Aplicaciones relacionadas
Esta solicitud reivindica el beneficio del número de serie 62/736,332 de la solicitud de patente provisional, presentada el 25 de septiembre de 2018.
Campo técnico
Esta solicitud se refiere a un método y a un sistema para manejar una solicitud de reanudación seguida por una liberación y redirección de una manera que obvia la necesidad de que el Equipo de Usuario (en inglés, User Equipment, UE) entre primero en un modo conectado.
Antecedentes
La evolución a largo plazo (en inglés, Long Term Evolution, LTE) define el estado de un equipo de usuario (UE) en términos de estados de control de recursos de radio (en inglés, Radio Resource Control, r RC) y estados de gestión de conexión (en inglés, Connection Management, CM).
• En el estado RRC_IDLE (RRC EN REPOSO), un UE es conocido por el núcleo de paquetes evolucionado (en inglés, Evolved Packet Core, EPS) y tiene una dirección de Protocolo de Internet (IP, por sus siglas en inglés), pero no es conocido por una estación base particular tal como un Nodo B evolucionado o mejorado (eNB, por sus siglas en inglés).
• En el estado RRC_CONNECTED (RRC CONECTADO), el UE es conocido tanto por el núcleo de paquetes evolucionado (en inglés, Evolved Packet Core, EPC) como por el eNB.
• En el estado CM-IDLE (CM EN REPOSO), no existe ninguna conexión de señalización de estrato sin acceso (en inglés, Non-Access Stratum, NAS) entre el UE y la red. No hay contexto para el UE en el eNB. El UE no está conectado a una entidad de gestión de movilidad (en inglés, Mobility Management Entity, MME).
• En el estado CM-CONNECTED (CM CONECTADO), existe una conexión de señalización NAS y la MME conoce la ubicación del UE, que coordina el traspaso y otros procedimientos relacionados con la movilidad.
Como se usa en la presente memoria, un UE en el estado RRC_IDLE puede denominarse "UE de RRCJDLE", un UE en el estado RRC_CONNECTED puede denominarse "UE de RRC_CONNECTED", y así sucesivamente.
LTE - Suspender y Reanudar
En la versión 13 (en inglés, Release 13, Rel-13) de LTE se introdujo un mecanismo para que un UE sea suspendido por la red en un estado suspendido similar a RRCJDLE pero con la diferencia de que el UE almacena el contexto del estrato de acceso (en inglés, Access Stratum, AS) o el contexto RRC. Esto hace posible reducir la señalización cuando el UE vuelve a activarse de nuevo reanudando la conexión RRC, en lugar de como antes de establecer la conexión RRC desde cero. Reducir la señalización podría tener varios beneficios, tales como reducir la latencia, por ejemplo, para teléfonos inteligentes que acceden a Internet, y reducir el consumo de batería, especialmente para dispositivos de tipo máquina que envían muy pocos datos. La solución de la Rel-13 describe un proceso en donde el UE envía un mensaje de RRCConnectionResumeRequest (solicitud de reanudación de conexión RRC) a la red y en respuesta recibe una RRCConnectionResume (reanudación de conexión RRC) de la red. El RRCConnectionResume no está cifrado pero está protegido por integridad.
NR - RRC_INACTIVE
En la versión 15 (en inglés, Release 15, Rel-15) de LTE, que también se denomina LTE mejorado (en inglés, enhanced LTE, eLTE) o LTE conectado a la red central (NGC) de quinta generación (en inglés, Fifth Generation, 5G), y en radio nueva (en inglés, New Radio, NR), como parte del trabajo estandarizado en radio nueva de quinta generación (5G NR, por sus siglas en inglés) en el proyecto de asociación de tercera generación (en inglés, Third Generation Partnership Project, 3GPP), se ha decidido que la NR debe soportar un estado RRC_INACTIVE con algunas propiedades similares al estado suspendido en Rel-13 de LTE. El RRC_INACTIVE tiene propiedades ligeramente diferentes del estado de LTE ya que es un estado RRC separado y no forma parte de RRCJDLE como en LTE. Además, la conexión de red central (en inglés, Core Network, CN) / conexión (interfaz NG o N2) de acceso de radio (en inglés, Radio Access Network, RAN) se mantiene para RRC_INACTIVE mientras estuvo suspendida en LTE.
La figura 1 ilustra una máquina de estados de UE y posibles transiciones de estado entre los estados de RRC en NR. Las propiedades de los estados en la figura 1 son las siguientes:
RRC_IDLE. Las capas superiores pueden configurar una recepción discontinua (en inglés, Discontinuous Reception, DRX) específica de UE. El UE controla la movilidad basándose en la configuración de red. El UE supervisa un canal de paginación para la CN usando una identidad de abonado móvil temporal (en inglés, Temporary Mobile Subscribe Identity, 5G-S-TMSI) de la evolución de la arquitectura del sistema (en inglés, System Architecture Evolution, SAE) de 5G, realiza mediciones de celda vecina y (re)selección de celda y adquiere información del sistema.
RRC_INACTIVE (RRC INACTIVO). Las capas superiores o la capa RRC pueden configurar un DRX específico de UE. El UE controla la movilidad basado en la configuración de red. El UE almacena el contexto de estrato de acceso (AS). El UE supervisa un canal de paginación para la paginación de CN usando la 5G-S-TMSI y la paginación de RAN usando un identificador temporal de red de radio inactiva (en inglés, Inactive Radio Network Temporary Identifier, I-RNTI), realiza mediciones de celda vecina y (re)selección de celda, realiza actualizaciones de área de notificación basadas en RAN periódicamente y cuando se mueve fuera del área de notificación basada en RAN, y adquiere información del sistema.
RRC_CONNECTED. El UE almacena el contexto de AS. Se produce la transferencia de datos de unidifusión hacia/desde UE. En las capas inferiores, el UE puede configurarse con un DRX específico de UE. Para los UE que soportan la agregación de portadora (en inglés, Carrier Aggregation, CA), se pueden agregar una o más celdas secundarias (en inglés, Secondary Cells, SCells) con la celda especial (en inglés, Special Cell, SpCell) o la celda primaria (en inglés, Primary Cell, PCell) para aumentar el ancho de banda. Para los UE que soportan conectividad dual (en inglés, Dual Connectivity, DC), se puede agregar un grupo de celdas secundarias (en inglés, Secondary Cell Group, SCG) con el grupo de celdas maestras (en inglés, Master Cell Group, MCG) para aumentar el ancho de banda. Se soporta la movilidad controlada por la red, es decir, el traspaso dentro de NR y hacia/desde la red de acceso de radio terrestre universal evolucionada (en inglés, Evolved Universal Terrestrial Radio Access Network, E-UTRAN). El UE supervisa un canal de paginación, supervisa los canales de control asociados con el canal de datos compartido para determinar si los datos están programados para él, proporciona calidad del canal e información de retroalimentación, realiza mediciones de celdas vecinas e informes de medición, y adquiere información del sistema.
La figura 1 ilustra las posibles transiciones de estado entre los estados RRC_IDLE, RRC_CONNECTED, y RRC_INACTIVE. En la figura 1, estas transiciones son las siguientes:
La transición 102 de estado, "liberar [y redirigir]", se denomina así porque un UE puede liberarse con o sin ser redirigido a otra frecuencia o tecnología de acceso de radio (en inglés, Radio Access Technology, RAT).
Característica de liberación y redirección
En LTE, según la especificación técnica (en inglés, Technical Specification, TS) 36.331 de 3GPP, la característica de liberación y redirección se usa para liberar un UE de RRC_CONNECTED a RRC_IDLE y redirigirlo a otra frecuencia, ya sea en la misma RAT o en una RAT diferente. En lo sucesivo, se presume que una TS es una TS de 3GPP a menos que se especifique lo contrario.
Durante la reunión RAN2#99 en Berlín del grupo de trabajo de la capa 2 de red de acceso de radio (en inglés, Radio Access Network Layer 2, RAN2) del 3GPP, se acordaron las funcionalidades de "liberación y redirección" y "prioridades de reselección de celda tras la liberación" (denominada información de control de movilidad en LTE) para NR:
• Acuerdo 11: se acordó que el tipo de mensaje RRC Connection Release (liberación de conexión de RRC) puede incluir información de causa, redirección de frecuencia de portadora, e información de control de movilidad de modo en reposo.
• Acuerdo 27: se acordó que, para la transición de RRC CONECTADO a INACTIVO, el tipo de mensaje RRC Connection Release incluye (a) la misma información que se enumera en el acuerdo 11 (es decir, información de causa, redirección de frecuencia de portadora e información de control de movilidad), y puede incluir (b) identidad de UE (o identidad de contexto de UE) y, opcionalmente, (c) indicación de suspensión/inactivación (para mayor estudio (FFS, por sus siglas en inglés) si está implícita o explícitamente), (d) ciclo de DRX configurado por RAN, (e) temporizador de notificación periódica de RAN, y (f) área de notificación de RAN.
Estas propuestas se han especificado en la especificación de RRC (TS 38.331) y en las especificaciones del modo En Reposo/Inactivo (TS 38.304). En el documento RRC (TS 38.331), el mensaje RRCRelease se usa para mover el UE de RRC_CONNECTED a RRC_IDLE o de RRC_CONNECTED a RRC_INACTIVE. La función de liberación y redirección se activa entonces cuando el campo redirectCarrierInfo (información de portadora redirigida) está incluido en el mensaje RRCRelease. A continuación, se reproduce un extracto del documento TS 38.331, con las adiciones pertinentes en negrita.
[INICIO EXTRACTO DE RRC TS 38.331]
[FIN EXTRACTO RRC TS 38.311] Según el documento TS 38.304, el siguiente comportamiento del UE se especifica tras la recepción del campo redirectedCarrierInfo (información de portadora redirigida):
En la transición del estado RRC_CONNECTED al estado RRC_IDLE o al estado RRC_INACTIVE, el UE intentará acampar en una celda adecuada según el campo redirectedCarrierInfo (es decir, una celda que tiene la frecuencia de portadora especificada) si el campo redirectedCarrierInfo se incluye en el mensaje de RRC usado para esta transición. Si el UE no puede encontrar una celda adecuada, se permite al UE acampar en cualquier celda adecuada de la RAT indicada. Si el mensaje de liberación de RRC no contiene el campo redirectedCarrierInfo, el UE intentará seleccionar una celda adecuada en una portadora de NR. Si no se encuentra una celda adecuada según lo anterior, el UE realizará la selección de celda usando la información almacenada para encontrar una celda adecuada para acampar.
Cuando se vuelve al estado RRC_IDLE después de que UE se movió al estado RRC_CONNECTED desde el estado acampado en cualquier celda, el UE intentará acampar en una celda aceptable según el campo redirectedCarrierInfo, si se incluye en el mensaje de liberación de RRC. Si el UE no puede encontrar una celda aceptable, se le permite al UE acampar en cualquier celda aceptable de la RAT indicada. Si el mensaje de liberación de RRC no contiene el campo redirectedCarrierInfo el UE intentará seleccionar una celda aceptable en una portadora de NR. Si no se encuentra una celda aceptable según lo anterior, el UE continuará buscando una celda aceptable de cualquier red móvil terrestre pública (en inglés, Public Land Mobile Network, PLMN) en el estado de cualquier selección de celda.
Procedimiento de actualización de adaptación de usuario de la parte de aplicación del subsistema de red de radio (en inglés, Radio Network Subsytem Application Part User Adaptation, RNA)
En RAN2#99bis en Praga, se ha acordado que para las actualizaciones de área de RAN, un RRCResumeRequest (solicitud de reanudación de RRC) puede ser respondido por la red con un RRCRelease,que posiblemente contiene información de redirección:
• Acuerdo 3: un UE en el estado INACTIVO, que intenta reanudar una conexión de RRC, puede recibir MSG4 enviado a través de SRB1 (portador de radio de selección 1) con al menos protección de integridad para mover el UE de nuevo al estado INACTIVO (es decir, no rechazado). (Caso de uso de actualización de RNA)
• Acuerdo 4: el MSG4 (es decir, no rechazado) del acuerdo 3 puede configurar al menos los mismos parámetros que pueden ser configurados por el mensaje que mueve el UE al estado INACTIVO (por ejemplo, I-RNTI (identificador temporal de la red radio), RNA, ciclo de DRX de RAN, temporizador RNAU (actualización de la adaptación del usuario de la parte de aplicación del subsistema de red de radio) periódico, frecuencia de portadora redirigida, para información de control de movilidad de modo inactivo o información de prioridad de reselección). (el marco de seguridad debe discutirse independientemente)
• Acuerdo 5: un UE en el estado INACTIVO, que intenta reanudar la conexión de RRC, puede recibir MSG4 enviado a través de SRB1 con al menos protección de integridad para mover el UE al estado EN REPOSO.
RRCRelease (liberación de RRC) convencional sin redirección
La Figura 2 ilustra un procedimiento de actualización de la adaptación de usuario de la parte de aplicación del subsistema de red de radio convencional (RNA). La Figura 2 describe el procedimiento de actualización de RNA activado por UE cuando un UE en el estado RRC_INACTIVO sale del RNA configurado que implica la recuperación de contexto a través de la interfaz Xn. Debido a que la liberación no implica una redirección, el UE puede realizar este procedimiento sin entrar al estado RRC_CONNECTED. En la etapa 200, el UE emite un mensaje RRCResumeRequest que indica que esto es para una actualización de RNA. La Estación Base de Radio Nueva (en inglés, New Radio Base Station, gNB) que recibe esta solicitud recupera el contexto de UE de la última gNB de servicio (etapas 202 y 204) y proporciona una indicación de dirección de reenvío de datos a la última gNB de servicio (etapa 206). La primera gNB solicita entonces que la función de gestión de acceso y movilidad (en inglés, Access and Mobility Management Function, AMF) de servicio realice un cambio de ruta (etapas 208 y 210). La primera gNB responde entonces al UE con un RRCRelease (etapa 212) que incluye información de suspendConfig (configuración inactiva). La primera gNB notifica entonces a la última gNB de servicio que puede descartar la información de contexto de ese UE (etapa 214).
Problemas con las soluciones existentes
Actualmente existen ciertos desafíos. Según los estándares del 3GPP actuales, cuando una publicación incluye información de redirección que redirige el UE a una RAT diferente, el UE pasará al estado RRC_IDLE. En la práctica, un UE que recibe información de redirección pasa al estado RRC_IDLE de todos modos. Por tanto, el proceso convencional mostrado en la Figura 2 es aceptable para el RRCRelease sin redirección, pero no es aceptable si el RRCRelease incluye información de redirección, porque el UE pasará al estado RRC_IDLE y perderá cualquier seguridad que se hubiera activado.
La pregunta entonces era si era necesario o no proteger la información de redirección. En la reunión de RAN2 RAN2#AH 2018-07 en Montreal, los aspectos de seguridad del mensaje RRCRelease que contiene información de redirección se discutió para NR y RAN2 envió una Declaración de Coordinación (en inglés, Liaison Statement, LS) al Servicio de 3GPP y al Grupo de Trabajo 3 de Aspectos del Sistema (en inglés, System Aspects, SA) - Seguridad (SA3), solicitando si ese mensaje podría enviarse sin protección por razones de rendimiento, como la latencia puede ser alto y se puede generar demasiada señalización cuando el UE viene de RRC_IDLE y necesita entrar en RRC_CONNECTED y establecer seguridad de AS. Las discusiones fueron que la redirección parecía información sensible para ser protegida, más tarde confirmado por el SA3.
Por tanto, se ha decidido que, debido a aspectos de seguridad del mensaje RRCRelease, el UE debe haber establecido seguridad de AS antes de recibir un mensaje RRCRelease que incluye información de redirección. Como resultado, un proceso tal como el proceso de actualización de RNA ilustrado en la Figura 2 no es adecuado para recibir un mensaje de liberación que incluye información de redirección. En cambio, los sistemas convencionales deben usar un proceso tal como el que se muestra en la Figura 3.
Liberación convencional con redirección a un UE de frecuencia de NR en el estado RRC_IDLE
La Figura 3 ilustra un proceso convencional para liberar y redirigir a una frecuencia de NR para un UE actualmente en el estado RRC_IDLE. En la reunión RAN2#103 en Gotemburgo, el SA3 respondió a la LS de RAN2 sobre los aspectos de seguridad del mensaje RRCRelease que contiene parte de esta información, indicando que el SA3 considera necesario que el RAN2 se asegure de que el mensaje de liberación de conexión de RRC esté al menos protegida por integridad, y que esto es necesario para permitir que el UE valide la autenticidad del origen del mensaje y evite ataque de falsificación a la estación base.
En otras palabras, un mensaje RRCRelease solo puede ser procesado por un UE de RRC_CONNECTED y si viene de manera segura (es decir, al menos con integridad protegida).
Por tanto, en la Figura 3, el primer UE pasa del estado RRC_IDLE al estado RRC_CONNECTED (etapas 300 y 302), entonces pasa del estado CM-IDLE al estado CM-CONNECTED (etapas 304 y 306), establece el transporte de N<a>S (etapas 308, 310, 312, 314) y configura un contexto de seguridad (etapas 316, 318 y 320), antes de que pueda recibir el mensaje RRCRelease con información de redirección (etapa 322).
Además, según la especificación de RRC (más precisamente la descripción del campo redirectedCarrierInfo) y la especificación En Reposo/Inactivo, el UE solo puede ser redirigido si abandona el estado RRC_CONNECTED. Es posible que la especificación de RRC fuera escrita con un caso de uso específico en mente, es decir, cuando un nodo de red en un origen de RAT (por ejemplo, NR) se está sobrecargando y tampoco ha implementado traspasos / reconfiguración con sincronización o por alguna otra razón prefiere redirigir el UE de RRC_CONNECTED a otra frecuencia o RAT sin tener que configurar medidas. Este caso de uso presupone que el UE está en el estado RRC_CONNECTED.
Sin embargo, otro caso de uso relevante es donde el UE está en el estado RRC_IDLE y quiere iniciar un servicio dado y, debido a algunas condiciones de la red (por ejemplo, sobrecargado en una frecuencia particular y/o RAT, no soporta el servicio solicitado, como voz sobre Protocolo de Internet (en inglés, Voice over Internet Protocol, VoIP), etc.), el UE se mueve al estado RRC_CONNECTED y entonces se redirige con un mensaje de liberación. Este caso de uso sufre una penalización mayor en términos de latencia y señalización por el requisito de SA3 de que el mensaje debe protegerse.
Además, hay un problema de rendimiento en términos de latencia para los UE entrantes que intentan reanudar o configurar una conexión que quiere acceder a un servicio particular no soportado en una celda de destino (por ejemplo, VoIP, videollamada, etc.). Como se describió anteriormente, en el caso de un UE de RRC_IDLE, el UE necesitaría activar un procedimiento de establecimiento de RRC, entrar RRC_CONNECTED, realizar la activación de seguridad inicial, y solo entonces recibir la información de redirección protegida. Eso también implicaría alguna señalización de red central, como se muestra en la Figura 3.
Liberación convencional con redirección a una frecuencia de NR, UE en el estado RRC_INACTIVE
Con la introducción del estado RRC_INACTIVE en NR, el procedimiento para entrar al estado RRC_CONNECTED desde el RRC_INACTIVE es más rápido que el procedimiento para entrar al estado RRC_CONNECTED desde el estado RRC_IDLE. Por tanto, el caso de uso de un UE entrante que entra en el estado RRC_CONNECTED y entonces se libera se vuelve más rápido ya que la seguridad ya está activada, es decir, no hay necesidad de realizar el procedimiento de activación de seguridad inicial.
Sin embargo, a pesar de los beneficios en comparación con el estado RRC_IDLE, incluso para los UE de RRC_INACTIVE todavía hay una cantidad significativa de señalización y latencia debido al hecho de que el UE primero necesita entrar al estado RRC_CONNECTED antes de que pueda ser redirigido. La latencia en la liberación y la redirección que comienza desde el estado RRC_INACTIVE puede ser más corta en comparación con el caso donde el UE viene del estado RRC_IDLE, ya que la seguridad ya está activada. Tras enviar un mensaje RRCRelease seguro, la red puede mover el UE al estado RRC_IDLE o al estado RRC_INACTIVE. Como la red redirige el UE a otra frecuencia de NR, en un caso típico, la red mueve el UE al estado RRC_INACTIVE, para acelerar también la reanudación de la conexión en la frecuencia de destino, reduciendo aún más la latencia general, como se muestra en la Figura 4.
La Figura 4 ilustra un proceso convencional para la liberación con redirección a una frecuencia de NR para un UE que se encuentra actualmente en el estado RRC_INACTIVO. En la Figura 4, el UE emite un RRCResumeRequest (etapa 400). La gNB recupera el contexto de UE de la última gNB de servicio (etapas 402 y 404), y envía una instrucción RRCResume (reanudación RRC) al UE (etapa 406). Entonces, el UE entra en el estado RRC_CONNECTED y emite un mensaje RRCResumeComplete (reanudación RRC completa) a la gNB (etapa 408). La gNB opcionalmente proporciona una indicación de dirección de reenvío de datos a la última gNB de servicio (etapa 410). La gNB entonces inicia un cambio de ruta en la AMF (etapas 412 y 414), libera el contexto de UE (etapa 416), y envía un RRCRelease al UE (etapa 418). El RRCRelease da instrucciones al UE para ir al estado RRC_INACTIVE y se redirija a una frecuencia de NR. Entonces, el UE pasa al modo RRC_INACTIVE, entonces intenta reanudar en la frecuencia de NR indicada (etapa 420).
Como se muestra en la Figura 4, la latencia puede mejorarse si un UE de RRC_INACTIVE intenta reanudar una conexión de RRC y, después de entrar al estado RRC_CONNECTED, el UE se suspende al estado RRC_INACTIVE con información de redirección a una frecuencia de NR. En la celda de destino, el UE intenta reanudar la conexión. En este escenario, el retardo se puede calcular como:
2*RTT_nr (RRCResumeRequest, RRCResume, RRCResumeComplete, RRCRelease)
+ RTT_Xn (retardo de la red en origen a partir de obtención de contexto)
+ RTT_5gc (señalización entre CN y el conmutador de la ruta origen)
+ 1,5*RTT_nr (RRCResumeRequest, RRCResume, RRCResumeComplete)
+ RTT_Xn (retardo de la red en origen a partir de obtención de contexto)
+ RTT_5gc (señalización entre CN y el conmutador de la ruta origen)
= 3,5*RTT_nr 2*RTT_Xn 2*RTT_5gc.
Lanzamiento con redirección convencional a una frecuencia de Acceso Radio Terrestre Universal Evolucionado (en inglés, Evolved Universal Terrestrial Radio Access, E-UTRA), UE en el estado RRC_INACTIVE
La Figura 5 ilustra un proceso convencional para la liberación con redirección a una frecuencia de E-UTRA para un UE que se encuentra actualmente en el estado RRC_INACTIVE. En este caso de inter-RAT, si el servicio solicitado por el UE no es soportado por NR, la red puede redirigir el UE a otra RAT, por ejemplo, LTE. Tras la recepción RRCRelease con información de redirección, independientemente de si la red indica al UE que se mueva al estado RRC_INACTIVE o al estado RRC_IDLE, el UE realizará acciones tras entrar al estado RRC_IDLE y realizará la selección de celda a una celda de LTE en la frecuencia de E-UTRA indicada y, realizará un procedimiento de establecimiento de la conexión de RRC (en inglés, RRC Connection Setup) (transición del estado RRC_IDLE al estado RRC_CONNECTED en E-UTRA).
En la Figura 5, el UE emite un RRCResumeRequest (etapa 500). La gNB recupera el contexto de UE de la última gNB de servicio (etapas 502 y 504), y envía una instrucción RRCResume (reanudación de RRC) al UE (etapa 506). Entonces, el UE entra en el estado RRC_CONNECTED y emite un mensaje RRCResumeComplete (reanudación de RRC completa) al gNB (etapa 508). La gNB opcionalmente proporciona una indicación de dirección de reenvío de datos a la última gNB de servicio (etapa 510). Entonces, la gNB inicia una conmutación de ruta en la AMF (etapas 512 y 514), libera el contexto de UE (etapa 516), y envía un RRCRelease al UE (etapa 518). El mensaje RRCRelease puede ser con o sin suspendConfig (configuración inactiva) y redirige a una frecuencia de LTE. Entonces, el UE pasa al modo RRC_IDLE, realiza una selección de celda en la frecuencia de LTE indicada y activa el establecimiento de conexión RRC (etapa 520).
Como puede verse en el caso inter-RAT que se muestra en la Figura 5, la latencia se puede mejorar si un UE de RRC_INACTIVE intenta reanudar una conexión de RRC y, después de entrar al estado r Rc_CONNECTED, el UE se suspende al estado RRC_INACTIVE con información de redirección a una frecuencia de E-UTRA. En la celda de destino, el UE intenta establecer la conexión (usando una transición de estado RRC_IDLE a RRC_CONNECTED). En este escenario, el retardo se puede calcular como:
2*RTT_nr (RRCResumeRequest, RRCResume, RRCResumeComplete, RRCRelease)
+ RTT_Xn (retardo de la red en origen a partir de obtención de contexto)
+ RTT_5CN (señalización entre CN y el conmutador de la ruta origen)
3,5*RTT_eutra (RRCConnectionRequest, RRCSetup, RRSetupComplete, SecurityModeCommand, SecurityModeComplete)
+ 2,5*RTT_EPC (señalización entre CN y eNB destino)
= 2*RTT_nr 2,5*RTT_eutra RTT_5GC 2,5*RTT_EPC
Problema de solución existente
Según la especificación de RRC, tras la recepción del mensaje RRCRelease con el campo redirectedCarrierInfo, el UE actúa según lo descrito en el documento TS 38.304, que es lo siguiente: "En transición desde el estado RRC_CONNECTED al estado RRC_IDLE o al estado RRC_INACTIVE, el UE intentará acampar en una celda adecuada según redirectedCarrierInfo si se incluye en el mensaje de RRC usado para esta transición".
El documento: ERICSSON: "RRC state machine and RRC_INACTIVE characteristics", 3GPP DRAFT; R2-1700535 -RRC STATE MACHINE AND RRC_INACTIVE CHARACTERISTICS, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), 17 de enero de 2017, describe la adición de algunos principios que faltan del estado RRC_INACTIVE así como un posible estado de máquina que refleja un modelo basado en 3 estados: RRC_CONNECTED, RRC_IDLE y RRC_INACTIVE.
En resumen, las especificaciones actuales de 3GPP requieren que, tras recibir un mensaje de liberación de RRC (RRCResume), el UE primero entrará en el estado RRC_CONNECTED antes de que pueda recibir el campo redirectedCarrierInfo y realice un procedimiento de liberación y redirección. Debido a que el UE no tendrá ninguna conexión de datos en la celda origen/RAT origen, hay una señalización significativa a través de la interfaz de radio (para entrar primero al estado RRC_CONNECTED a través de un procedimiento de reanudación completo), señalización entre los nodos de la red de RAN (para la búsqueda de contexto), y señalización entre nodos RAN y CN (para cambio de ruta). El tema de la presente descripción intenta abordar estos problemas.
Compendio
Las realizaciones expuestas a continuación representan información para permitir a los expertos en la técnica poner en la práctica las realizaciones e ilustrar el mejor modo de poner en la práctica las realizaciones. Tras leer la siguiente descripción a la luz de las figuras de los dibujos adjuntos, los expertos en la técnica comprenderán los conceptos de la descripción y reconocerán las aplicaciones de estos conceptos no específicamente abordados en la presente memoria. Debe entenderse que estos conceptos y aplicaciones caen dentro del alcance de la descripción. Ciertos aspectos de la presente descripción y sus realizaciones pueden proporcionar soluciones a los desafíos antes mencionados u otros. La invención se define en las reivindicaciones independientes 1 y 12, detalles adicionales se definen en las reivindicaciones dependientes.
Por tanto, los sistemas y métodos descritos en la presente memoria incluyen redirigir un UE en el estado RRC_INACTIVE a una frecuencia / RAT diferente usando una liberación de dos etapas con procedimiento de redirección, es decir, se envía un mensaje de liberación con redirección en respuesta directa a una solicitud de reanudación.
Hay, propuestas en la presente memoria, varias realizaciones que abordan uno o más de los problemas descritos en la presente memoria. Ciertas realizaciones pueden proporcionar una o más de las siguientes ventajas técnicas. Una ventaja del método propuesto es la latencia y la señalización reducidas en las interfaces aéreas y las interfaces entre nodos (tanto entre los nodos RAN como entre RAN y CN).
Breve descripción de los dibujos
Las figuras de los dibujos adjuntos incorporadas y que forman parte de esta especificación ilustran varios aspectos de la descripción, y junto con la descripción sirven para explicar los principios de la descripción.
La figura 1 ilustra una máquina de estado de Equipo de Usuario (UE) y posibles transiciones de estado entre los estados de control de recursos de radio (RRC) en radio nueva (NR);
la figura 2 ilustra un procedimiento de actualización de la adaptación de usuario de la parte de aplicación del subsistema de red de radio convencional (RNA);
la figura 3 ilustra un proceso convencional para liberar y redirigir a una frecuencia de NR para un UE actualmente en el estado RRC_IDLE;
la figura 4 ilustra un proceso convencional de liberación con redirección a una frecuencia de NR para un UE actualmente en el estado RRC_INACTIVE;
la figura 5 ilustra un proceso convencional para la liberación con redirección a una frecuencia de E-UTRA para un UE actualmente en el estado RRC_INACTIVE;
la figura 6 ilustra un proceso ejemplar para la liberación y redirección, realizado por un UE, según algunas realizaciones de la presente descripción;
la figura 7 ilustra un proceso ejemplar para la liberación y redirección, realizado por un nodo de red, según algunas realizaciones de la presente descripción;
la figura 8 ilustra un proceso de dos etapas ejemplar para la liberación y la redirección según algunas realizaciones de la presente descripción;
la figura 9 ilustra una interacción convencional entre capas superiores / estrato de no acceso (NAS) y estrato de acceso (AS);
la figura 10 ilustra un proceso de dos etapas ejemplar para la liberación y redirección según algunas realizaciones de la presente descripción;
la figura 11 ilustra una interacción ejemplar entre capas NAS y AS ejemplares según algunas realizaciones de la presente descripción;
la figura 12 ilustra una interacción ejemplar entre capas NAS y AS ejemplares según algunas realizaciones de la presente descripción;
la figura 13 ilustra un ejemplo de una red de comunicaciones celulares según algunas realizaciones de la presente descripción;
la figura 14 ilustra un sistema de comunicación inalámbrica representado como una arquitectura de la red de quinta generación (5G) compuesta de funciones de red (en inglés, Network Functions, NF) centrales, donde la interacción entre dos NF cualesquiera está representada por un punto/interfaz de referencia punto a punto;
la figura 15 ilustra una arquitectura de la red 5G que usa interfaces basadas en servicios entre las NF en el plano de control;
la figura 16 es un diagrama de bloques esquemático de un nodo de acceso por radio según algunas formas de realización de la presente descripción;
la figura 17 es un diagrama de bloques esquemático que ilustra una realización virtualizada de un nodo de acceso por radio según algunas realizaciones de la presente descripción;
la figura 18 es un diagrama de bloques esquemático de un nodo de acceso por radio según algunas otras realizaciones de la presente descripción;
la figura 19 es un diagrama de bloques esquemático de un UE según algunas realizaciones de la presente descripción; la figura 20 es un diagrama de bloques esquemático del UE según algunas otras realizaciones de la presente descripción;
la figura 21 ilustra un sistema de comunicación según algunas realizaciones de la presente descripción;
la figura 22 ilustra un sistema de comunicación según algunas otras realizaciones de la presente descripción; la figura 23 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción;
la figura 24 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción;
la figura 25 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción; y
la figura 26 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción.
Descripción detallada
Algunas de las realizaciones contempladas en la presente memoria se describirán ahora de forma más completa con referencia a los dibujos adjuntos. Sin embargo, otras realizaciones están contenidas dentro del alcance del tema en la presente memoria, el tema descrito no debe interpretarse como limitado únicamente a las realizaciones expuestas en la presente memoria; más bien, estas realizaciones se proporcionan a modo de ejemplo para transmitir el alcance del tema a los expertos en la técnica.
Nodo de radio: Como se usa en la presente memoria, un "nodo de radio" es un nodo de acceso de radio o un dispositivo inalámbrico.
Nodo de acceso de radio: Como se usa en la presente memoria, un "nodo de acceso de radio" o "nodo de red de radio" es cualquier nodo en una red de acceso de radio de una red de comunicaciones celulares que opera para transmitir y/o recibir señales de forma inalámbrica. Algunos ejemplos de un nodo de acceso de radio incluyen, pero no se limitan a, una estación base (por ejemplo, una estación base (gNB) de radio nueva (NR) en una red de NR del proyecto de asociación de tercera generación (3GPP), quinta generación (5G) o un nodo B mejorado o evolucionado (eNB) en una red de evolución a largo plazo (LTE) de 3GPP), una estación base macro o de alta potencia, una estación base de baja potencia (por ejemplo, una estación base micro, una estación base pico, un eNB doméstico, o similar) y un nodo de retransmisión.
Nodo de red central: Como se usa en la presente memoria, un "nodo de red central" es cualquier tipo de nodo en una red central. Algunos ejemplos de un nodo de red central incluyen, por ejemplo, una entidad de gestión de movilidad (MME), una pasarela de red de paquetes de datos (en inglés, Packet Data Network Gateway, P-GW), una función de exposición de capacidad de servicio (en inglés, Service Capability Exposure Function, SCEF), o similares.
Dispositivo inalámbrico: Como se usa en la presente memoria, un "dispositivo inalámbrico" es cualquier tipo de dispositivo que tiene acceso a (es decir, es servido por) una red de comunicaciones celulares transmitiendo y/o recibiendo señales de forma inalámbrica a un nodo(s) de acceso de radio. Algunos ejemplos de un dispositivo inalámbrico incluyen, pero no se limitan a, un dispositivo de equipo de usuario (UE) en una red 3GPP y un dispositivo de comunicación de tipo de máquina (en inglés, Machine Type Communication, MTC).
Nodo de red: Como se usa en la presente memoria, un "nodo de red" es cualquier nodo que sea parte de la red de acceso de radio o la red central de una red/sistema de comunicaciones celulares.
Tener en cuenta que la descripción dada en la presente memoria se centra en un sistema de comunicaciones celulares 3GPP y, como tal, a menudo se usa terminología 3GPP o terminología similar a la terminología 3GPP. Sin embargo, los conceptos descritos en la presente memoria no se limitan a un sistema 3GPP.
Tener en cuenta que, en la descripción de esta memoria, se puede hacer referencia al término "celda"; sin embargo, particularmente con respecto a los conceptos de NR de 5G, se pueden usar haces en lugar de celdas y, como tal, es importante tener en cuenta que los conceptos descritos en la presente memoria son igualmente aplicables tanto a celdas como a haces.
Las realizaciones expuestas a continuación representan información para permitir a los expertos en la técnica poner en práctica las realizaciones e ilustrar el mejor modo de poner en práctica las realizaciones. Tras leer la siguiente descripción a la luz de las figuras de los dibujos adjuntos, los expertos en la técnica comprenderán los conceptos de la descripción y reconocerán las aplicaciones de estos conceptos que no se abordan particularmente en la presente memoria. Debe entenderse que estos conceptos y aplicaciones caen dentro del alcance de la descripción.
Liberación mejorada con redirección - UE
La figura 6 ilustra un proceso ejemplar de liberación y redirección, realizado por un UE, según algunas realizaciones de la presente descripción. En la realización ilustrada en la figura 6, un método ejecutado por un UE en estado inactivo (RRC_INACTIVE) de control de recursos de radio (RRC) comprende las siguientes etapas:
Etapa 600: recibir de las capas superiores (por ejemplo, la capa de estrato sin acceso (NAS)) una solicitud para reanudar una conexión de RRC (por ejemplo, una solicitud para iniciar un servicio dado con un valor de causa asociado, tal como: emergencia; acceso de alta prioridad (en inglés, highPriorityAccess); valores de causa de terminación móvil (en inglés, Mobile Terminated, MT), tal como acceso de MT (en inglés, MT-Access); valores de causa de origen móvil (en inglés, Mobile Originated, MO), tal como datos de MO (en inglés, MO-Data), llamada de voz de MO (en inglés, MO-VoiceCall), videollamada de MO (en inglés, MO-VideoCall) y SMS de MO (en inglés, MO-SMS); valores de causa del servicio de prioridad multimedia (en inglés, Multimedia Priority Service, MPS), tales como acceso de prioridad de MPS (en inglés, MPS-PriorityAccess); valores de causa de soporte crítico de misión (en inglés, Mission Critical Support, MCS), tal como acceso de prioridad de MCS (en inglés, MCS-PriorityAccess), o cualquier otro valor de causa introducido en el futuro). Estos servicios pueden ser soportados por todos los nodos o pueden ser soportados por algunos nodos pero no por otros.
Tras recibir la solicitud de las capas superiores, el UE puede realizar acciones tras transmitir un mensaje de solicitud de reanudación de RRC (RRC Resume Request) con un valor de causa que está asociado con la solicitud de las capas superiores.
Aunque la etapa 600 se describe anteriormente como una solicitud de las capas superiores, el método también es aplicable para una solicitud desde las capas AS o RRC, por ejemplo, en el caso de una actualización de RNA que se responde con un mensaje que suspende al UE de nuevo al estado RRC_INACTIVE (o equivalente) y redirigir el UE a otra frecuencia en la misma tecnología de acceso de radio (RAT) u otra frecuencia en una RAT diferente.
Etapa 602: transmitir, a un nodo de red (por ejemplo, un eNB), un mensaje de solicitud de reanudación de RRC (RRC Resume Request) con un valor de causa que está asociado con la solicitud de las capas superiores. Las redes convencionales solo pueden responder con un tipo de mensaje de solicitud de reanudación de RRC (RRC Resume Request), tal como un mensaje RRCResumeRequest o RRCResumeRequest1 (o un RRCConnectionResumeRequest) en LTE, o con un mensaje RRCRelease (o RRCConnectionRelease en LTE) en el caso de que la solicitud de reanudación de RRC (RRC Resume Request) esté asociada a las actualizaciones de adaptación de usuario de la parte de aplicación del subsistema de red de radio (RNA), por ejemplo, cuando tienen un valor de causa de actualización de autoridad de movimiento (en inglés, Movement Authority, MA).
Etapa 604: recibir, desde el nodo de red y en respuesta al mensaje en la etapa 602, un mensaje RRC Release (liberación de RRC) con información de redirección a otra portadora, que puede ser de la misma<r>A<t>o de una RAT diferente. Hay varios escenarios que involucran variaciones en el destino de redirección (por ejemplo, NR versus LTE) y si el mensaje RRC Release (liberación de RRC) incluye o no una configuración inactiva:
NR inactivo a NR inactivo. En algunas realizaciones, si el UE de RRC_INACTIVE intentó reanudar en NR y recibe una información de redirección a una frecuencia de NR, y el mensaje contiene una configuración inactiva, el UE permanece en estado RRC_INACTIVE y realiza la selección de celda tras entrar RRC_INACTIVE en la frecuencia de portadora indicada en el mensaje.
NR inactivo a NR en reposo. En algunas realizaciones, si el UE de RRC_INACTIVE intentó reanudar en NR y recibe una información de redirección a una frecuencia de NR, y el mensaje no contiene una configuración inactiva, el UE entra en el estado RRC_IDLE (y realiza acciones en consecuencia, por ejemplo, detener temporizadores, liberar recursos, etc.) y realiza la selección de celda tras entrar RRC_IDLE en la frecuencia de portadora indicada en el mensaje.
Los mismos principios se podrían aplicar a un procedimiento "LTE a LTE".
NR Inactivo a LTE Inactivo. En algunas realizaciones, si el UE de RRC_INACTIVE intentó reanudar en NR y recibe una información de redirección a una frecuencia de LTE, y el mensaje contiene una configuración inactiva, el UE permanece en el estado RRC_INACTIVE y realiza la selección de celda inter-RAT tras entrar RRC_INACTIVE en la frecuencia de portadora indicada en el mensaje. Eso lo ejecutan los UE que soportan RRC_INACTIVE en la RAT de destino, en este ejemplo, LTE. Si el UE no soporta RRC_INACTIVE en LTE, el UE entra RRC_IDLE tras recibir el RRCRelease con información de redirección independientemente de si el mensaje contiene una configuración inactiva o no y realiza la selección de celda inter-RAT tras entrar RRC_IDLE en la frecuencia de portadora indicada en el mensaje.
NR Inactivo a LTE en Reposo. En algunas realizaciones, si el UE de RRC_INACTIVE intentó reanudar en NR y recibe una información de redirección a una frecuencia de LTE, y el mensaje no contiene una configuración inactiva, el UE entra en el estado RRC_IDLE (y realiza acciones en consecuencia, por ejemplo, detener temporizadores, liberar recursos, etc.) y realiza la selección de celda tras entrar RRC_IDLE en la frecuencia de portadora indicada en el mensaje.
Los mismos principios podrían aplicarse a un procedimiento "LTE a NR".
En cualquiera de estos casos (LTE a NR, NR a NR, LTE a LTE o NR a LTE), el UE debe realizar la selección de celda.
Los diferentes escenarios descritos anteriormente se manejan por las etapas 606, 608, 610, 612 y 614 de la figura 6. En la realización ilustrada en la figura 6, el UE determina si la información de redirección es hacia la misma RAT (etapa 606), y de ser así, el UE permanecerá en el estado RRC_INACTIVE (etapa 608). Sin embargo, si la información de redirección es hacia una RAT diferente, el UE determinará si la nueva RAT soporta el estado RRC_INACTIVE (etapa 610) y, de ser así, permanecerá en ese estado (etapa 608) o de lo contrario, pasará al estado RRC_IDLE (etapa 612). Después de eso, el UE realiza las siguientes etapas.
Etapa 614: realizar la selección de celda tras entrar al estado RRC_INACTIVE o al estado RRC_IDLE, en la frecuencia indicada en el mensaje RRCRelease (en la información de redirección).
Al realizar la selección de celda, el UE puede entrar un nuevo RNA, es decir, una celda, área de seguimiento, área de registro, ID de área de RAN, etc. para el cual el UE no está configurado. En lugar de realizar una actualización de área de RAN, el UE intenta reanudar en la celda recién seleccionada según la causa de reanudación que generó primero el mensaje de solicitud de reanudación de RRC (RRC Resume Request) solicitado por la capa superior y al que se respondió con la liberación de RRC (RRC release) con información de redirección. En términos más generales, en algunas realizaciones la solicitud de capa superior y el procedimiento de reanudación se consideran pendientes y deben iniciarse después de la selección de celda. Deben tener prioridad de cualquier procedimiento de RRC o AS que se active tras la selección de celda, como entrar a una nueva área de RAN que no esté configurada como parte de la configuración de RNA para ese UE.
Tras realizar la selección de celda, el UE puede entrar en una nueva área de seguimiento (en inglés, Tracking Area) (o área de registro (en inglés, Registration Area)) con la que no está configurada (por ejemplo, que no forma parte de su lista de áreas configuradas). En estos escenarios, en algunas realizaciones, en lugar de realizar una actualización del área de seguimiento (en inglés, T racking Area Update) (o equivalente, como una actualización del área de registro (en inglés, Registration Area Update)), el método incluye intentar reanudar en la celda recién seleccionada según la causa de reanudación que generó primero el mensaje de solicitud de reanudación de RRC (RRC Resume Request) solicitado por la capa superior y que se respondió con la liberación de RRC con información de redirección. En algunas realizaciones, la solicitud de capa superior y el procedimiento de reanudación se consideran pendientes y deben iniciarse después de la selección de la celda. Deben tener prioridad de cualquier procedimiento de RRC, procedimiento de AS o incluso un procedimiento de NAS (en el caso de una actualización de área de registro) que se activa al seleccionar la celda.
Tras hacer la selección de celda, el UE puede entrar en una nueva área de seguimiento (o área de registro) con la que no está configurada (por ejemplo, que no forma parte de su lista de áreas configuradas). El método comprende, en lugar de realizar una actualización del área de seguimiento (o equivalente, como una actualización de área de registro), intentar reanudar en la celda recién seleccionada según la causa de reanudación que generó primero el mensaje de solicitud de reanudación de RRC (RRC Resume Request) solicitado por la capa superior y que se respondió con la liberación de RRC (RRC release) con información de redirección. En términos más generales, la solicitud de la capa superior y el procedimiento de reanudación se consideran de alguna manera pendientes y deben iniciarse después de la selección de la celda. Deben tener prioridad de cualquier procedimiento de RRC, procedimiento de AS, pero no un procedimiento de NAS relacionado con una actualización de área de registro activada tras la selección de celda. La razón podría deberse al hecho de que un servicio dado no es soportado antes de que se realice una actualización de área.
En algunas realizaciones, el UE realiza la selección de celda aunque no abandone el estado RRC_CONNECTED. Por tanto, este es un nuevo activador para la selección de celda: el UE está entrando en el estado RRC_INACTIVE o en el estado RRC_IDLE tras recibir un mensaje de liberación de RRC (ya sea al estado RRC_IDLE o al estado RRC_INACTIVE) cuando el UE viene del estado RRC_INACTIVE.
En la selección de celda tras entrar al estado RRC_INACTIVE o entrar al estado RRC_IDLE, el UE intentará acampar en una celda adecuada según redirectedCarrierInfo si se incluye en el mensaje de RRC usado para esta transición. Si el UE no puede encontrar una celda adecuada, se permite al UE acampar en cualquier celda adecuada de la RAT indicada. Si no se encuentra una celda adecuada según lo anterior, el UE realizará la selección de celda usando la información almacenada para encontrar una celda adecuada para acampar.
Etapa 616: determinar el estado actual de RRC del UE, por ejemplo, RRC_IDLE o RRC_INACTIVE.
Etapa 618: si el UE está en el estado RRC_INACTIVE, activar un procedimiento de reanudación de conexión en la RAT indicada u otro procedimiento en la RAT indicada basando en la información de redirección.
Etapa 620: si el UE está en el estado RRC_IDLE, desencadenar un procedimiento de establecimiento de conexión en la RAT indicada u otro procedimiento en la RAT indicada basado en la información de redirección.
Liberación mejorada con redirección - nodo de red
La figura 7 ilustra un proceso ejemplar para la liberación y redirección, realizado por un nodo de red, según algunas realizaciones de la presente descripción. En la realización ilustrada en la figura 7, un método ejecutado por un nodo de red comprende las siguientes etapas:
Etapa 700: recibir, desde un UE que está en el estado RRC_INACTIVE, un mensaje RRCResumeRequest que incluye un valor de causa o indica de otro modo que esto se solicitó por capas superiores. En esta etapa, la gNB de destino (o eNB o cualquier tipo de nodo de RAN) que sirve a la celda en la que el UE intenta reanudar recibe una solicitud de reanudación de RRC como mensaje desde el UE. El valor de causa asociado a esa solicitud de reanudación indica que la solicitud se activó por capas superiores en el UE (por ejemplo, NAS). Algunos ejemplos de estos incluyen, pero no se limitan a: emergencia, acceso de alta prioridad, acceso de MT, datos de MO, llamada de voz de MO, videollamada de MO, SMS de MO, acceso de prioridad de MPS o acceso prioritario de MCS.
Debido a alguna condición de la red o política local (por ejemplo, celda/portadora/RAT de destino sobrecargada o servicio asociado con un valor de causa no disponible en la celda/portadora/RAT de destino), la gNB de destino puede decidir redirigir a otra frecuencia o RAT. Alternativamente, si el contexto de AS no se reubica y es la gNB de origen la que genera el mensaje de liberación de RRC, puede ser la gNB de origen (o eNB o cualquier tipo de nodo de RAN) la que decida redirigir el UE. Sin embargo, esto puede requerir, por ejemplo, que el valor de causa o alguna otra información indicativa del servicio de solicitud se reenvíe al gNB de origen por la gNB de destino.
Etapa 702: determinar que el UE debe ser redirigido a otra frecuencia y/u otra RAT.
Etapa 704: tras determinar que el UE debe ser redirigido a otra frecuencia o a otra RAT, permitir la transmisión de un mensaje seguro sin mover el UE al estado RRC_CONNECTED. Esto se puede hacer con o sin reubicación de contexto.
En la primera alternativa, la gNB de destino busca el contexto de AS desde la gNB de origen (a veces llamado gNB de anclaje) a través de la interfaz Xn. Como parte del procedimiento de búsqueda de contexto, la gNB de origen también valida la identidad del UE que emite la solicitud (verificando el shortResumeMAC-I contenido en la solicitud de reanudación como mensaje). El contexto de AS contiene, entre otras cosas, los parámetros de seguridad (por ejemplo, clave de seguridad y algoritmos de seguridad) requeridos para reactivar la seguridad de AS para que el mensaje de liberación de RRC se pueda enviar protegido (de modo que se cumplan los requisitos de seguridad de SA3 para 5G). La gNB de destino también realiza un procedimiento de cambio de ruta con la AMF para informar al CN de la nueva ubicación del UE y actualizar las rutas del plano de control y de usuario. Como parte de este procedimiento, la gNB de destino también recibe un par {NCC, NH} nuevo desde la AMF. El valor de NCC de este par se incluye en la configuración inactiva (suspendConfig) en el mensaje de liberación de RRC enviado en la siguiente etapa. Como una optimización, para reducir aún más la latencia de la redirección, la gNB de destino puede elegir realizar el procedimiento de cambio de ruta en paralelo o después de enviar el mensaje de liberación (es decir, etapa 3 a continuación). Sin embargo, como el valor de NCC en el acuse de recibo del cambio de ruta se incluye normalmente en el mensaje de liberación, esto requiere que la gNB de destino pueda predecir/determinar el NCC recibido en el acuse de recibo del cambio de ruta antes de tiempo. Esto es posible ya que el siguiente NCC es típicamente el valor de NCC anterior (que se puede almacenar como parte del contexto de AS) incrementado en uno.
En la segunda alternativa, la gNB de destino sigue poniéndose en contacto con la gNB de origen para validar la solicitud, pero no obtiene el contexto de AS. Dado que el contexto de AS no se reubica, la gNB de destino no podrá reactivar la seguridad de AS y, por tanto, es la gNB de origen la que debe asegurar (es decir, proteger y cifrar la integridad) el mensaje de liberación. Esto implica que toda la información requerida para construir el mensaje de liberación debe ser conocida por la gNB de origen o reenviada a la gNB de origen por la gNB de destino. Por tanto, si la gNB de destino toma la decisión de redirigir el UE, debe enviar la información de redirección (por ejemplo, frecuencia de destino y RAT de destino) a la gNB de origen para que la gNB de origen pueda incluir la información de redirección en el mensaje de liberación. Hay que tener en cuenta que dado que el contexto de AS no se reubica, la gNB de destino no realiza el cambio de ruta.
En la técnica anterior, la actualización de área de RAN (en particular las actualizaciones periódicas de área de RAN) se ha mencionado como el procedimiento para usar la reanudación sin reubicación de contexto. El tema de la presente descripción introduce un caso de uso nuevo donde el nodo de destino, sabiendo que esto será un procedimiento de liberación y redirección, activa el procedimiento sin reubicación. El nodo de destino puede informar al nodo de origen del motivo por el que se libera y redirige para que el origen no tenga que preocuparse por algunos de los parámetros de configuración inactiva, tales como los relacionados con las actualizaciones de RNA. Puede haber una indicación en el mensaje desde el destino al origen que diga que es un procedimiento de liberación y redirección, sin reubicación de contexto.
Etapa 706: enviar, al UE, una respuesta al mensaje RRCResumeRequest, la respuesta que incluye una liberación de RRC con información de redirección. En esta etapa, si el contexto de AS se reubicó en la etapa anterior, la gNB de destino genera y asegura la información de redirección del mensaje de liberación y la envía al UE. El mensaje de liberación incluye información sobre la portadora redirigida (redirectedCarrierInfo) y, si la red quiere que el UE permanezca en estado RRC_INACTIVE, la configuración inactiva (suspendConfig). Si el contexto de AS no se reubica, el mensaje de liberación se construye y asegura por la gNB de origen y se envía al gNB de destino, que a su vez lo reenvía de forma transparente al UE. Cuando el mensaje de liberación se envía en respuesta a la solicitud de reanudación, el UE no pasa a RRC_CONNECTED; en su lugar, permanece en el estado RRC_INACTIVE, si la configuración inactiva está incluida en el mensaje de liberación, o pasa a RRC_IDLE, de lo contrario.
Etapa 708: manejar el contexto de UE dependiendo de si el UE se mueve al estado RRC_IDLE o al estado RRC_INACTIVE y si la información de redirección está inter-RAT o intra-RAT. Dado que RRC_INACTIVE no es soportado por RAT en la versión 15 (en inglés, Rel-15), el UE pasará automáticamente a RRC_IDLE si se redirige desde NR a LTE (o viceversa) independientemente de si el mensaje de liberación contiene la configuración inactiva o no. Por tanto, si la red redirige el UE desde NR a LTE (o viceversa), puede eliminar el contexto de AS después de haber enviado el mensaje de liberación. Dependiendo de si el contexto de AS no se reubica, es la gNB de origen o de destino la que elimina el contexto de AS.
Liberación con redirección a una frecuencia de NR, UE en estado RRC_INACTIVE, en 2 etapas
En la Figura 8 se muestra un método de la solución propuesta con reubicación de contexto y sin reubicación de contexto, donde las reducciones de latencia exactas son diferentes.
La figura 8 ilustra un proceso de dos etapas ejemplar para la liberación y la redirección según algunas realizaciones de la presente descripción. En este escenario, con la reubicación de contexto, el flujo de llamadas ilustrado en la figura 8 podría aplicarse a la redirección a una frecuencia de NR. En la realización ilustrada en la figura 8, se realizan las siguientes etapas:
Etapa 800: un UE en un estado RRC_INACTIVE, CM-CONNECTED emite un mensaje RRCResumeRequest a una primera gNB.
Etapa 802 y 804: la primera gNB recupera el contexto de UE de la última gNB de servicio.
Etapa 806: la primera gNB proporciona a la última gNB de servicio una indicación de dirección de reenvío de datos.
Etapa 808 y 810: la primera gNB solicita entonces que la AMF de servicio realice un cambio de ruta.
Etapa 812: la primera gNB responde entonces al UE con un mensaje RRCRelease que incluye información de suspendConfig (configuración inactiva) y que también redirige al UE a otra frecuencia de NR. A diferencia de los métodos de la técnica anterior, en los que la gNB emitiría un mensaje de reanudación de RRC (RRCResume) antes de emitir el mensaje RRCRelease, en la realización ilustrada en la figura 8, la gNB no emite primero un mensaje RRCResume (liberación de RRC). En consecuencia, el UE no entra en el estado RRC_CONNECTED.
Etapa 814: el UE entonces realiza la selección de celda en NR e intenta reanudar en la celda de destino. Etapa 816: la gNB emite un mensaje de liberación de contexto de UE (UE Context Release) a la última gNB de servicio.
Dado que, desde el punto de vista del UE, el proceso implicaba solo dos etapas - enviar la solicitud RRCResumeRequest (etapa 800) y recibir el RRCRelease con redirección (etapa 812) - este método se denomina en la presente memoria un proceso de "dos etapas". En la liberación y redirección de dos etapas con reubicación de contexto como se ilustra en la Figura 8, un UE de RRC_INACTIVE intenta reanudar una conexión de RRC y sin entrar al estado RRC_CONNECTED, el UE se suspende al estado RRC_INACTIVO con información de redirección a una frecuencia de NR. En la celda de destino, el UE intenta reanudar la conexión. En comparación con el caso convencional donde el UE entra primero en el estado RRC_CONNECTED para entonces ser liberado, se pueden omitir dos mensajes entre el UE y el destino (RRCResume y RRCResumeComplete). En este escenario, el retardo se puede calcular como:
RTT_nr (RRCResume, RRCRelease)
RTT_Xn (retardo de la red en origen a partir de obtención de contexto)
RTT_5gc (señalización entre CN y conmutador de ruta origen)
1,5*RTT_nr (RRCResumeRequest, RRCResume, RRCResumeComplete)
RTT_Xn (retardo de la red en origen a partir de obtención de contexto)
RTT_5gc (señalización entre CN y conmutador de ruta origen)
= 2,5*RTT_nr 3*RTT_Xn 2*RTT_5gc.
En algunas realizaciones, el proceso ilustrado en la figura 8 se optimiza aún más en el caso donde el UE realiza un procedimiento de dos etapas sin reubicación de contexto. En estas realizaciones, tras enviar un RRCResumeRequest (que no es una actualización de RNA) el UE recibe un RRCRelease con suspendConfig (configuración inactiva) pero la red no realiza la reubicación de contexto - por ejemplo, las etapas 808 y 810 no se realizan. Dado que la red sabe que en el caso de liberación y redirección, el UE va de todos modos a otra frecuencia y se reanuda en otra celda que puede estar en otra gNB, puede que no tenga sentido activar la búsqueda de contexto ya que ese nuevo destino puede activar la búsqueda de contexto nuevamente. Por tanto, un procedimiento de dos etapas (RRCResumeRequest seguido de un RRCRelease con suspendConfig (configuración inactiva) e información de redirección) sin la reubicación de contexto puede reducir aún más la latencia del procedimiento, debido al hecho de que no es necesario realizar un cambio de ruta (como el ancla gNB/eNB mantiene la conexión con el CN no necesitaría cambiar). En este escenario, el retardo se puede calcular como:
RTT_nr (RRCResumeRequest, RRCRelease)
1,5*RTT_Xn (retardo de la red origen a partir de obtención de contexto)
1,5*RTT_nr (RRCResumeRequest, RRCResume , RRCResumeComplete)
1,5*RTT_Xn (retardo de la red en origen a partir de obtención de contexto)
RTT_5gc (señalización entre CN y conmutador de ruta origen)
= 2,5*RTT_nr 3*RTT_Xn RTT_5gc.
Para la liberación y la redirección entre frecuencias, la latencia en escenarios diferentes se puede resumir en la siguiente tabla:
En algunas realizaciones, el procedimiento de dos etapas con reubicación de contexto se optimiza para lograr la misma latencia que el procedimiento de dos etapas sin reubicación de contexto. En esta optimización, el contexto se sigue obteniendo y el cambio de ruta se sigue realizando, pero la liberación con el mensaje de redirección se envía antes del cambio de ruta en lugar de después. Con referencia a la figura 8, en estas realizaciones, la etapa 812 se produciría antes en el proceso, por ejemplo, antes de la etapa 810, 808, 806, 804 u 802. De esta manera, dado que el UE puede comenzar a reanudar con la celda de destino inmediatamente después de recibir la liberación con el mensaje de redirección recibido, el procedimiento de cambio de ruta no se suma al retardo experimentado por el UE. Esta optimización es posible ya que la gNB puede preparar el mensaje de liberación antes de que se reciba la respuesta del cambio de ruta.
Liberación con redirección a una frecuencia de LTE, UE en estado RRC_INACTIVE, en 2 etapas
El flujo de llamadas para este caso es similar al caso anterior excepto que el UE se redirige a una portadora de LTE en lugar de una portadora de NR. También en este caso se pueden conseguir ganancias de latencia similares a las convencionales, aunque la señalización detallada difiere.
Otras aplicaciones
La presente descripción describe el método como acciones realizadas por un UE de RRC_INACTIVE en NR. Si bien el tema de la presente descripción es aplicable para ese caso, puede haber otros casos adicionales, donde el tema de la presente descripción sea igualmente aplicable, tales como:
• Todos los casos anteriores donde los procedimientos ocurren en LTE en lugar de NR; es decir, para el caso de los UE de RRC_INACTIVE de LTE (cuando el UE se conecta a 5GC y es soportado por la celda de LTE);
• Procedimientos inter-RAT en el estado RRC_INACTIVE, principalmente entre LTE y NR conectados al mismo CN (Red Core 5G):
° Un UE en el estado RRC_INACTIVE de LTE intenta reanudar y se suspende al estado RRC_INACTIVE de NR con liberación y redirección en dos etapas, y entonces intenta reanudar en NR según la información de redirección; ° Un UE en el estado RRC_INACTIVE de NR intenta reanudar y se suspende al estado RRC_INACTIVE de LTE con liberación y redirección en dos etapas, y entonces intenta reanudar en LTE según la información de redirección;
• Procedimientos inter-RAT en el estado RRC_INACTIVE o en el estado RRC_IDLE, por ejemplo, entre LTE y NR, incluso cuando el estado RRC_INACTIVE no es soportado por LTE (por ejemplo, en el caso de que LTE se conecte al núcleo de paquetes evolucionado (en inglés, Core Packet Evolved, EPC) o NR (en el caso de una red dada, frecuencia o parte de la red no soporta el estado inactivo):
° Un UE en el estado RRC_INACTIVE de LTE intenta reanudar y se suspende al estado RRC_INACTIVE de NR con liberación y redirección en dos etapas, y luego entra al estado RRC_IDLE e intenta establecer la conexión en NR según la información de redirección;
° Un UE en el estado RRC_INACTIVE de NR intenta reanudar y se suspende al estado RRC_INACTIVE de LTE con liberación y redirección en dos etapas, y entonces entra al estado RRC_IDLE e intenta establecer la conexión en LTE según la información de redirección;
Tener en cuenta que en la descripción del caso inter-RAT, se define un procedimiento de suspensión/reanudación armonizado para la movilidad de RRC_INACTIVE, es decir, el UE puede suspenderse en una RAT y reanudarse en la otra RAT.
Para el método descrito en el lado de la red, que puede ser cualquier nodo RAN que posiblemente tenga una celda asociada o, más fundamentalmente, donde el UE puede acampar y realizar un procedimiento de solicitud de reanudación. Ese nodo de red puede ser una gNB en el caso de una celda de NR o una celda de LTE conectada a 5GC. Ese nodo de red puede ser una gNB en el caso de una celda de NR. Ese nodo de red puede ser un Nodo B evolucionado o mejorado (eNB) en el caso de una celda de LTE (por ejemplo, conectada a EPC).
Para el método descrito en el lado de la red, el término interfaz Xn se ha usado para referirse a la interfaz Xn entre gNB(s) en el caso de NR/5GC. Sin embargo, el método se aplica a cualquier interfaz entre nodos entre nodos RAN donde el contexto de AS puede ser obtenido / reubicado, por ejemplo, interfaz X2 entre eNB(s) en LTE. En estos casos, los mensajes usan un protocolo de capa de aplicación como XnAP o X2AP.
Interacción entre capas de estrato de acceso (AS) y estrato sin acceso (NAS)
Otro aspecto novedoso del tema presentado en la presente memoria es la interacción entre las capas de AS y de NAS. En el caso de la técnica anterior, se informa a las capas superiores cuando se reanuda una conexión que estaba suspendida, es decir, cuando el UE entra en RRC_CONNECTED. Tras hacer eso, las capas superiores son conscientes de que los portadores se han reanudado con éxito. De lo contrario, se notifica a las capas superiores que ha ocurrido un fallo, y, en ese caso, las capas superiores pueden activar un procedimiento de recuperación de NAS (por ejemplo, actualización del área de seguimiento o actualización del área de registro). En el caso de una transición de RRC_IDLE a RRC_CONNECTED, ese tipo de acuse de recibo a las capas superiores se proporciona tras el establecimiento de los portadores, realizado durante la configuración de los recursos de radio.
Como parte del método, se notifica a las capas superiores que el UE se está suspendiendo después de una solicitud para reanudar la conexión. Mirando las especificaciones de RRC, actualmente se ve así hoy:
[INICIO EXTRACTO DE ESPECIFICACIONES RRC]
5.3.13.4 Recepción delRRCResumepor el UE
El UE deberá:
parar el temporizador T319
si elRRCResumeincluye elfullConfig:
realizar el procedimiento de configuración completo como se especifica en 5.3.5.11;
si no
restaurar el estado PDCP y resetear el valor COUNT para SRB2 y todos los DRB;
restaurar elcellGroupConfigdel contexto UE AS almacenado;
indicar para capas inferiores que el contexto UE AS almacenado se usa;
descartarfulll-RNTI, shortl-RNTIyel contexto UE AS almacenado, exceptoran-NotificationArea!nfo\si elRRCResumeincluye elmasterCellGroup:
realizar una configuración del grupo de celdas para elmasterCellGrouprecibido según 5.3.5.5;
Nota del editor: FFS si es soportado para configurarsecondaryCellGroupen la reanudación,
si el RRCResume incluye el radioBearerConfig:
realizar la configuración del portador de radio según 5.3.5.6;
Nota del editor: FFS si es necesario que haya un segundoradioBearerConfig.
reanudar SRB2 y todos los DRB;
si se almacena, descartar la información de prioridad de reselección de celda proporcionada por elcelIReselectionPrioritieso heredada de otra RAT;
detener el temporizador, si está funcionando;
si el mensajeRRCResumeincluye elmeasConfig:
realizar el procedimiento de configuración de medición como se especifica en 5.5.2;
reanudar las mediciones, si se suspendieron;
Nota del editor: FFS si es necesario definir las acciones del UE relacionadas con los temporizadores de control de acceso (equivalentes a T302, T303, T305, T306, T308 en LTE). Por ejemplo, informando a las capas superiores si no se pone en marcha un temporizador dado.
entraren RRC_CONNECTED;
indicar a las capas superiores que la conexión de RRC suspendida se ha reanudado;
detener el procedimiento de reselección de celda;
considerar la celda actual como la PCell;
establecer el contenido del mensajeRRCResumeCompletecomo sigue:
si la capa superior proporciona ÑAS PDU, establecer el dedicatedNAS-Message para incluir la información recibida de las capas superiores;
si la capa superior proporciona PLMN, establecer el selectedPLMN-ldentity para el PLMN seleccionado por las capas superiores (TS 24.501 [23]) a partir de los PLMN incluidos en elplmn-IdentityListen SIB1\
si elmasterCellGroupcontiene elreportUplinkTxDirectCurrent
incluir el upIinkTxDirectCurrentList;
enviar el mensajeRRCResumeCompletea las capas inferiores para su transmisión;
el procedimiento finaliza.
[FIN EXTRACTO DE ESPECIFICACIONES RRC]
La figura 9 ilustra una interacción convencional entre las capas superiores / NAS y AS. En la realización ilustrada en la figura 9, las siguientes etapas ocurren dentro de un UE:
Etapa 900: las capas superiores / NAS (en lo sucesivo, simplemente "el NAS") solicitan que se reanude una conexión suspendida.
Etapa 902: se envía a la red por el AS un mensaje RRCResumeRequest.
Etapa 904: se recibe de la red por el AS un mensaje RRCResume (reanudación de RRC).
Etapa 906: Se notifica a las capas superiores y se considera el procedimiento exitoso, por ejemplo, que la conexión suspendida se ha reanudado. El UE entra en el estado RRC_CONNECTED. Por tanto, la figura 9 ilustra el escenario donde un UE pasa del estado RRC_INACTIVO al estado RRC_CONNECTED.
La especificación de NAS (TS 24.501) también cubre el caso donde el UE en el estado RRC_CONNECTED (o 5GMM-CO<n>N<e>CTED en el caso de UE de 5GC) recibe un mensaje RRCRelease para pasar al estado RRC_INACTIVE, por ejemplo, GMM-CONNECTED con indicación inactiva, como se puede ver a continuación en el documento TS 38.331 y en el documento TS 24.501:
[INICIO EXTRACTOS DE ESPECIFICACIONES NAS]
5.3.8.3 Recepción delRRCReleasepor el UE
El UE deberá:
retrasar las siguientes acciones definidas en estas subcláusula 60ms a partir del momento en el que el mensajeRRCReleasese recibió u, opcionalmente, cuando las capas inferiores indican que el recibo del mensajeRRCReleasese ha reconocido con éxito, lo que se produzca antes.
detener el temporizador T320, si está funcionando;
si el mensajeRRCReleaseincluyeredirectedCarrielnfoindicando redirección aeutra:
sicnTypeestá incluido:
elcnTyperecibido se proporciona a las capas superiores;
NOTA: Manejar el caso si la celda E-UTRA seleccionada después de la redirección no soporta el tipo de red central especificado por elcnType,depende de la implementación del UE.
si el mensaje RRCRelease incluye la celIReselectionPriorities:
almacenar la información de prioridad de reselección proporcionada por lacelIReselectionPriorities;si está incluido el t320:
iniciar el temporizador T320, con el valor de temporizador establecido según el valor de t320; si no
aplicar la difusión de información de prioridad de reselección en la información de sistema;
sideprioritisationReqestá incluido:
iniciar o reiniciar el temporizador T325 con el valor de temporizador establecido aldeprioritisationTimerseñalizado;
almacenar eldeprioritisationReqhasta que T325 se agota;
si elRRCReleaseincluye suspendConfig:
aplicar elsuspendConfigrecibido;
almacenar fulll-RNTI, shortl-RNTI, nextHopChainingCount,t380y ran-PagingCycle proporcionados en suspendConfig;
resetear MAC;
restablecer entidades RCL para SRB1;
si el mensajeRRCReleaseconsuspendConfigse recibió en respuesta a unRRCResumeRequest ounRRCResumeRequest 1:
detener el temporizador T319 si está funcionando;
sustituir cualquier contexto de seguridad almacenado previamente por un contexto de seguridad nuevamente recibido en elsuspendConfig-,
sustituir el C-RNTI almacenado previamente por el C-RNTI temporal en la celda en la que el UE ha recibido el mensajeRRCRelease-,
sustituir lacellldentityalmacenada previamente por lacellldentity dela celda en la que el UE ha recibido el mensaje RRCRelease;
sustituir la identidad de celda física almacenada previamente por la identidad de celda física de la celda en la que el UE ha recibido el mensajeRRCRelease-,
si no
almacenar el Contexto UE AS incluyendo la configuración actual de RRC, el contexto de seguridad actual, el estado de PDCP incluyendo el estado de ROHC, la configuración de SDAP, el C-RNTI usado en la PCell de origen, lacellldentityy la identidad de celda física de la PCell de origen;
suspender todos los SRB y DRB, excepto SRBO;
iniciar el temporizador T380, con el valor de temporizador establecido at380\;
indicar la suspensión de la conexión RRC a las capas superiores;
entrar en RRCJNACTIVE y realizar los procedimientos especificados en TS 38.304 [21]
si no
realizar las acciones al ir a RRCJDLE como se especifica en 5.3.11, con la causa de liberación“otra”.Nota del editor: FFS si tiene que haber diferentes causas de liberación y acciones asociadas.
******
5.3.1.4 Modo 5GMM-CONNECTED con indicación de RRC inactivo
El UE deberá hacer la transición desde el modo 5GMM-CONNECTED por acceso 3GPP al modo 5GMM-CONNECTED con indicación de RRC inactivo al recibir una indicación desde las capas inferiores de que el UE ha hecho la transición al estado RRCJNACTIVE.
Tras:
- una activación de un procedimiento que requiere el envío de un mensaje ÑAS; o
- un paquete de datos de usuario de enlace ascendente a enviar para una sesión de PDU con recursos de plano de usuario suspendidos;
el UE en modo 5GMM-CONNECTED con Indicación de RRC inactivo por acceso 3GPP deberá solicitar a las capas inferiores la transición al estado RRC CONNECTED (ver 3GPP TS 38.300 [27]).
El UE deberá hacer la transición desde el modo 5GMM-CONNECTED con la indicación de RRC inactivo al modo 5GMM-CONNECTED por acceso 3GPP al recibir una indicación desde las capas inferiores de que el UE ha hecho la transición al estado RRC_CONNECTED (ver 3GPP TS 38.300 [27]).
NOTA: La AMF puede ser consciente de la transición entre el modo 5GMM-CONNECTED y el modo 5GMM-CONNECTED con indicación de RRC inactivo para un UE (ver 3GPP TS 23.502 [9])-
[FIN EXTRACTOS DE ESPECIFICACIONES ÑAS]
Aunque la especificación de NAS cubre los casos donde el UE pasa del estado RRC_CONNECTED al estado RRCJNACTIVE y del estado RRCJNACTIVE al estado RRC_CONNECTED, la especificación de NAS actual no cubre el caso donde las capas superiores solicitan una solicitud de reanudación cuando el UE está en RRCJNACTIVE y posiblemente reciba una liberación con redirección a RRC_IDLE (y en ese caso transición a 5GMM-IDLE) o RRCJNACTIVE (y en ese caso transición a 5GMM-CONNECTED con indicación inactiva). Este escenario se ilustra en la figura 10.
La figura 10 ilustra un proceso de dos etapas ejemplar para la liberación y la redirección según algunas realizaciones de la presente descripción, mostrando la incapacidad de un NAS convencional para manejar este escenario. En la realización ilustrada en la figura 10, las siguientes etapas ocurren dentro de un UE:
Etapa 1000: las capas superiores / NAS solicitan que se reanude una conexión suspendida.
Etapa 1002: El AS envía a la red un mensaje RRCResumeRequest
Etapa 1004: El AS recibe de la red un mensaje RRCRelease
Etapa 1006: Se notifica a las capas superiores, pero el NAS convencional no sabe qué hacer con esta información. Las figuras 11 y 12 ilustran realizaciones que abordan este problema.
La figura 11 ilustra una interacción ejemplar entre capas de NAS y de AS ejemplares según algunas realizaciones de la presente descripción. En la realización ilustrada en la figura 11, tras recibir el mensaje para entrar RRC_INACTIVE con una información de redirección después de enviar una solicitud de reanudación de RRC, el UE informa a las capas superiores que se está suspendiendo (aunque ya está suspendido). En algunas realizaciones, tras la indicación de las capas inferiores de la suspensión, las capas superiores considerarán al UE todavía en MM-CONECTADO con indicación inactiva y considerarán la primera solicitud pendiente, entendiendo implícitamente que el UE fue liberado con la información de redirección. Después de que el UE realice la selección de celda, las capas superiores pueden activar nuevamente la solicitud. En la realización ilustrada en la figura 11, las siguientes etapas ocurren dentro de un UE:
Etapa 1100: las capas superiores / NAS solicitan que se reanude una conexión suspendida.
Etapa 1102: el AS envía a la red un mensaje RRCResumeRequest.
Etapa 1104: el AS recibe de la red un mensaje RRCResume (reanudación de RRC)
Etapa 1106: el NAS considera que el procedimiento está pendiente.
Etapa 1108: las capas superiores activan la solicitud nuevamente, por ejemplo, al seleccionar la celda.
La figura 12 ilustra una interacción ejemplar entre capas de NAS y de AS ejemplares según algunas realizaciones de la presente descripción. En la realización ilustrada en la figura 12, tras recibir el mensaje para entrar RRC_INACTIVE con una información de redirección después de enviar una solicitud de reanudación de RRC, el UE informa a las capas superiores que se está suspendiendo (aunque ya está suspendido) e indica si se incluye una información de liberación y redirección. Tras la indicación de las capas inferiores de la suspensión con esta indicación de redirección, las capas superiores considerarán que el UE todavía está en MM-CONNECTED con indicación inactiva y considerarán la primera solicitud pendiente. Después de que el UE realice la selección de celda, las capas superiores pueden activar nuevamente la solicitud. En la realización ilustrada en la figura 12, las siguientes etapas ocurren dentro de un UE:
Etapa 1200: las capas superiores / NAS solicitan que se reanude una conexión suspendida.
Etapa 1202: el AS envía a la red un mensaje RRCResumeRequest.
Etapa 1204: el AS recibe de la red un mensaje RRCRelease, el mensaje que incluye información de redirección.
Etapa 1206: el AS considera que el procedimiento está pendiente y activa la solicitud pendiente tras la reselección de celda.
En otras realizaciones ejemplares más según la presente descripción, las solicitudes pendientes para reanudar desde las capas superiores son manejadas por la capa de AS si el UE es redirigido en un procedimiento de 2 etapas. En estas realizaciones, tras recibir el mensaje para entrar RRC_INACTIVE con una información de redirección después de enviar una solicitud de reanudación de RRC, el UE NO informa a las capas superiores que se está suspendiendo pero considera que la solicitud de las capas superiores sigue siendo válida. Por tanto, tras realizar la selección de celda según la información de redirección, el UE activa esa solicitud de reanudación pendiente de las capas superiores. Como las capas superiores pueden esperar una respuesta en algún momento, la indicación de una redirección de casos anteriores puede usarse para indicar a las capas superiores que el procedimiento no debe abortarse.
Implementaciones del método en las especificaciones
Algunas de las realizaciones según la presente descripción pueden codificarse dentro de las Especificaciones del 3GPP como se muestra a continuación. El texto nuevo está marcado en negrita y subrayado.
Una realización de la presente descripción puede codificar un cambio en las especificaciones de RRC, para aclarar que la redirectedCarrierInfo en el RRCRelease que conduce a la selección de celda no necesariamente puede conducir al procedimiento de abandonar RRC_CONNECTED:
l[INICIO CAMBIO 1 PROPUESTO PARA ESPECIFICACIONES RRC]
redirectedCarrierInfo
Indica una frecuencia de portadora (enlace descendente para FDD) y se usa para redirigir el UE a una NR o una frecuencia de portadora inter-RAT, por medio de la selección de celdas al abandonar RRC_CONNECTED o al ir a RRC INACTIVE desde RRC INACTIVE (procedimiento de dos etapas) o desde RRC IDLE, como se especifica en TS 38.304 [201.
[FIN CAMBIO 1 PROPUESTO PARA ESPECIFICACIONES RRC]
Otra realización de la presente descripción puede codificar un cambio en las especificaciones de En Reposo/Inactivo, para aclarar que redirectedCarrierInfo en el RRCRelease que conduce a la selección de celda, no conduce necesariamente al procedimiento de abandonar RRC_CONNECTED:
[INICIO CAMBIO 2 PROPUESTO PARA ESPECIFICACIONES RRC]
5.2.6 Selección de celda cuando se abandona el estado RRC_CONNECTED
En la transición de RRC_CONNECTED al estado RRCJDLE o al estado RRCJNACTIVE,o cuando se permanece en RRCJNACTIVO en un procedimiento de dos etapas (es decir, el UE se suspende sin entrar en RRC_CONEECTED),el UE deberá intentar acampar en una celda adecuada según redirectedCarrierInfo si se incluye en el mensaje RRC usado para esta transición. Si el UE no puede encontrar una celda adecuada, se permite al UE acampar en cualquier celda adecuada de la RAT indicada. Si el mensaje de liberación de RRC no contiene el campo redirectedCarrierInfo, el UE intentará seleccionar una celda adecuada en una portadora de NR. Si no se encuentra una celda adecuada según lo anterior, el UE realizará la selección de celda usando la Información almacenada para encontrar una celda adecuada para acampar.
Cuando se vuelve al estado RRCJDLE después de que UE se movió al estado RRC_CONNECTED desde el estado acampado en cualquier celda, el UE intentará acampar en una celda aceptable según el campo redirectedCarrierInfo, si se incluye en el mensaje de liberación de RRC. Si el UE no puede encontrar una celda aceptable, se le permite al UE acampar en cualquier celda aceptable de la RAT Indicada. Si el mensaje de liberación de RRC no contiene el campo redirectedCarrierInfo el UE intentará seleccionar una celda aceptable en una portadora de NR. Si no se encuentra una celda aceptable según lo anterior, el UE continuará buscando una celda aceptable de cualquier red móvil terrestre pública (en inglés, Public Land Mobile Network, PLMN) en el estado de cualquier selección de celda
[FIN CAMBIO 2 PROPUESTO PARA ESPECIFICACIONES RRC]
Otra realización de la presente descripción puede codificarse como un cambio en las especificaciones de la etapa 2 (TS 38.300), para aclarar que redirectedCarrierInfo en RRCRelease que conduce a la selección de celda, no conduce necesariamente al procedimiento de abandonar RRC_CONNECTED.
[INICIO CAMBIO 3 PROPUESTO PARA ESPECIFICACIONES RRC]
9.2.2.5Procedimiento de solicitud de reanudación/liberación en dos etapas(por ejemplo, actualización de RNA)
La siguiente figura describe el procedimiento de actualización de RNA activado por UE cuando sale del RNA configurado que implica la recuperación de contexto a través de Xn:
«F IG U R A 9.2.2.5-1: Procedimiento de actualización de R N A »
1. El UE se reanuda a partir de RRCJNACTIVE, proporcionando el l-RNTI asignado por la última gNB de servicio y valor de causa apropiado, por ejemplo, actualización de área de notificación RAN.
2. La gNB, si es capaz de resolver la identidad de gNB contenida en el l-RNTI, solicita que la última gNB de servicio proporcione el Contexto de UE.
3. La última gNB de servicio proporciona el contexto de UE.
4. La gNB puede mover el UE a RRC_CONNECTED, o enviar el UE de nuevo al estado RRCJNACTIVE o enviar el UE a RRCJDLE. Si el UE se envía a RRCJDLE, las siguientes etapas no son necesarias.
5. Si se debe evitar la pérdida de datos de usuario de DL almacenados en la memoria intermedia en la última gNB de servicio, la gNB proporciona direcciones de reenvío.
677. La gNB realiza un cambio de ruta.
8. La gNB activa la liberación de los recursos de UE en la última gNB de servicio.
El UE puede recibir unRRCReleasecon información de redirección en respuesta a un tipo de mensajeRRCResumeRequest.
[FIN CAMBIO PROPUESTO PARA ESPECIFICACIONES RRC]
Explicación adicional
La Figura 13 ilustra un ejemplo de una red 1300 de comunicaciones celulares según algunas realizaciones de la presente descripción. En las realizaciones descritas en la presente memoria, la red 1300 de comunicaciones celulares es una red NR de 5G. En este ejemplo, la red 1300 de comunicaciones celulares incluye estaciones base 1302-1 y 1302-2, que en LTE se denominan como eNB y en NR de 5G se denominan como gNB, que controlan las macroceldas 1304-1 y 1304-2 correspondientes. Las estaciones base 1302-1 y 1302-2 se denominan generalmente en la presente memoria colectivamente como estaciones base 1302 e individualmente como estación base 1302. Asimismo, las macroceldas 1304-1 y 1304-2 se denominan generalmente en la presente memoria colectivamente como macroceldas 1304 e individualmente como macrocelda 1304. La red 1300 de comunicaciones celulares también puede incluir varios nodos 1306-1 a 1306-4 de baja potencia que controlan las correspondientes celdas 1308-1 a 1308-4 pequeñas. Los nodos 1306-1 a 1306-4 de baja potencia pueden ser pequeñas estaciones base (tales como estaciones base pico o femto) o cabezales de radio remotos (en inglés, Remote Radio Heads, RRH), o similares. Notablemente, aunque no se ilustra, una o más de las celdas 1308-1 a 1308-4 pequeñas pueden ser proporcionadas alternativamente por las estaciones base 1302. Los nodos 1306-1 a 1306-4 de baja potencia se denominan generalmente en la presente memoria colectivamente como nodos 1306 de baja potencia e individualmente como nodo 1306 de baja potencia. Asimismo, las celdas 1308-1 a 1308-4 pequeñas se denominan generalmente en la presente memoria colectivamente como celdas 1308 pequeñas e individualmente como celda 1308 pequeña. Las estaciones base 1302 (y opcionalmente los nodos 1306 de baja potencia) están conectados a una red 1310 central.
Las estaciones base 1302 y los nodos 1306 de baja potencia proporcionan servicio a los dispositivos 1312-1 a 1312 5 inalámbricos en las celdas 1304 y 1308 correspondientes. Los dispositivos 1312-1 a 1312-5 inalámbricos se denominan generalmente en la presente memoria colectivamente como dispositivos 1312 inalámbricos e individualmente como dispositivo 1312 inalámbrico. Los dispositivos 1312 inalámbricos se denominan también a veces en la presente memoria como UE.
La figura 14 ilustra un sistema de comunicación inalámbrica representado como una arquitectura de la red 5G compuesta de funciones de red (en inglés, Network Functions, NF) centrales, donde la interacción entre dos cualesquiera NF está representada por un punto/interfaz de referencia punto a punto. La figura 14 puede verse como una implementación particular del sistema 1300 de la figura 13.
Vista desde el lado de acceso, la arquitectura de la red 5G mostrada en la figura 14 comprende una pluralidad de equipos de usuario (UEs) conectados a una red de acceso de radio (RAN) o una red de acceso (AN), así como a una función de gestión de acceso y movilidad (en inglés, Access and Mobility Management Function, AMF). Típicamente, la R(AN) comprende estaciones base, por ejemplo, tal como Nodos B evolucionados (eNBs) o estaciones base de NR (gNBs) o similares. Visto desde el lado de la red central, las NF centrales de 5G mostradas en la figura 14 incluyen una función de selección de segmento de red (en inglés, Network Slide Selection Function, NSSF), una función de servidor de autentificación (en inglés, Authentication Server Function, AUSF), una gestión de datos unificada (en inglés, Unified Data Management, UDM), una AMF, una función de gestión de sesiones (en inglés, Session Management Function, SMF), una función de control de políticas (en inglés, Policy Control Function, PCF), y una función de aplicación (en inglés, Application Function, AF).
Las representaciones de puntos de referencia de la arquitectura de la red 5G se usan para desarrollar flujos de llamadas detallados en la estandarización normativa. El punto de referencia N1 está definido para transportar señalización entre el UE y la AMF. Los puntos de referencia para la conexión entre la AN y la AMF y entre la AN y la UPF se definen como<n>2 y N3, respectivamente. Hay un punto de referencia, N11, entre la AMF y la SMF, lo que implica que la SMF está al menos parcialmente controlada por la AMF. La SMF y la UPF usan N4 para que la UPF se pueda configurar usando la señal de control generada por la SMF, y la UPF pueda informar de su estado a la SMF. El N9 es el punto de referencia para la conexión entre diferentes UPF, y el N14 es el punto de referencia que conecta entre diferentes AMF, respectivamente. Los N15 y N7 se definen desde que la PCF aplica la política a la AMF y la SMP, respectivamente. Se requiere el N12 para que la AMF realice la autentificación del UE. Los N8 y N10 se definen porque los datos de suscripción del UE son necesarios para la AMF y la SMF.
La red central 5G tiene como objetivo separar el plano de usuario y el plano de control. El plano de usuario transporta el tráfico de usuarios mientras que el plano de control transporta la señalización en la red. En la figura 14, la UPF está en el plano de usuario y todas las demás NF, es decir, AMF, SMF, PCF, AF, AUSF y UDM, están en el plano de control. La separación de los planos de usuario y de control garantiza que cada recurso del plano se escale independientemente. También permite que las UPF se desplieguen por separado de las funciones del plano de control de forma distribuida. En esta arquitectura, las UPF se pueden desplegar muy cerca de los UE para acortar el tiempo de ida y vuelta (en inglés, Round Trip Time, RTT) entre los UE y la red de datos para algunas aplicaciones que requieren baja latencia.
La arquitectura central de la red 5G se compone de funciones modularizadas. Por ejemplo, la AMF y la SMF son funciones independientes en el plano de control. La AMF y la SMF separadas permiten la evolución y el escalado independientes. Otras funciones del plano de control, como la PCF y la AUSF, se pueden separar como se muestra en la figura 14. El diseño de función modular permite que la red central 5G soporte varios servicios de manera flexible.
Cada NF interactúa directamente con otra NF. Es posible usar funciones intermedias para enrutar mensajes de una NF a otra NF. En el plano de control, se define como servicio un conjunto de interacciones entre dos NF para que sea posible su reutilización. Este servicio permite el soporte para la modularidad. El plano de usuario soporta interacciones tales como operaciones de reenvío entre diferentes UPF.
La figura 15 ilustra una arquitectura de la red 5G que usa interfaces basadas en servicios entre las NF en el plano de control, en lugar de los puntos/interfaces de referencia punto a punto usados en la arquitectura de la red 5G de la figura 14. Sin embargo, las NF descritas anteriormente con referencia a la figura 14 corresponden a las NF mostradas en la figura 15. El (los) servicio(s), etc., que una NF proporciona a otras NF autorizadas pueden exponerse a las NF autorizadas a través de la interfaz basada en servicios. En la figura 15, las interfaces basadas en servicios se indican con la letra "N" seguida del nombre de la NF, por ejemplo, Namf para la interfaz basada en servicios de la AMF y Nsmf para la interfaz basada en servicios de la SMF, etc. La función de exposición de red (en inglés, Network Exposure Function, NEF) y la función de repositorio de red (en inglés, Network Repository Function, NRF) en la figura 15 no se muestran en la figura 14 discutida anteriormente. Sin embargo, debe aclararse que todas las NF representados en la figura 14 pueden interactuar con la NEF y la NRF de la figura 15 según sea necesario, aunque no se indique explícitamente en la figura 14.
Algunas propiedades de las NF mostrados en las figuras 14 y 15 pueden describirse de la siguiente manera. La AMF proporciona autentificación, autorización, gestión de movilidad, etc. basada en UE. Un UE incluso usando tecnologías de acceso múltiple está básicamente conectado a una única AMF porque la AMF es independiente de las tecnologías de acceso. La SMF es responsable de la gestión de sesiones y asigna direcciones de Protocolo de Internet (IP) a los UE. También selecciona y controla la UPF para la transferencia de datos. Si un UE tiene varias sesiones, se pueden asignar diferentes SMF a cada sesión para gestionarlas individualmente y posiblemente proporcionar diferentes funcionalidades por sesión. La AF proporciona información en el flujo de paquetes a la PCF responsable del control de políticas para soportar la calidad de servicio (en inglés, Quality of Service, QoS). Basada en la información, la PCF determina políticas sobre movilidad y gestión de sesiones para hacer que la AMF y la SMF funcionen correctamente. La AUSF soporta la función de autenticación para UE o similar y, por tanto, almacena datos para la autentificación de UE o similar, mientras que la UDM almacena datos de suscripción del UE. La red de datos (en inglés, Data Network, DN), que no forma parte de la red central 5G, proporciona acceso a Internet o servicios de operador y similares.
Una NF puede implementarse como un elemento de red en un hardware dedicado, como una instancia de software que se ejecuta en un hardware dedicado, o como una función virtualizada instanciada en una plataforma apropiada, por ejemplo, una infraestructura en la nube.
La figura 16 es un diagrama de bloques esquemático de un nodo 1600 de acceso de radio según algunas formas de realización de la presente descripción. El nodo 1600 de acceso de radio puede ser, por ejemplo, una estación base 1302 o 1306. Como se ilustra, el nodo 1600 de acceso por radio incluye un sistema 1602 de control que incluye uno o más procesadores 1604 (por ejemplo, unidades centrales de procesamiento (en inglés, Central Processing Units, CPUs), circuitos integrados de aplicaciones específicas (en inglés, Application Specific Integrated Circuits, ASICs), matrices de puertas programables en campo (en inglés, Field Programmable Gate Arrays, FPGAs) y / o similares), memoria 1606, y una interfaz 1608 de red. El uno o más procesadores 1604 se denominan también en la presente memoria como circuitos de procesamiento. Además, el nodo 1600 de acceso de radio incluye una o más unidades 1610 de radio, cada una de las cuales incluye uno o más transmisores 1612 y uno o más receptores 1614 acoplados a una o más antenas 1616. Las unidades 1610 de radio pueden ser denominadas como o ser parte de circuitos de interfaz de radio. En algunas realizaciones, la(s) unidad(es) 1610 de radio es(son) externa(s) al sistema 1602 de control y está(n) conectada(s) al sistema 1602 de control a través de, por ejemplo, una conexión por cable (por ejemplo, un cable óptico). Sin embargo, en algunas otras realizaciones, la(s) unidad(es) 1610 de radio y potencialmente la(s) antena(s) 1616 están integradas junto con el sistema 1602 de control. El uno o más procesadores 1604 operan para proporcionar una o más funciones de un nodo 1600 de acceso de radio como se describe en la presente memoria. En algunas realizaciones, la(s) función(es) se implementan en software que se almacena, por ejemplo, en la memoria 1606 y se ejecuta por uno o más procesadores 1604.
La figura 17 es un diagrama de bloques esquemático que ilustra una realización virtualizada del nodo 1600 de acceso de radio según algunas realizaciones de la presente descripción. Esta discusión es igualmente aplicable a otros tipos de nodos de red. Además, otros tipos de nodos de red pueden tener arquitecturas virtualizadas similares.
Como se usa en la presente memoria, un nodo de acceso de radio "virtualizado" es una implementación del nodo 1600 de acceso de radio en el que al menos una parte de la funcionalidad del nodo 1600 de acceso de radio se implementa como un(os) componente(s) virtual(es) (por ejemplo, a través de una(s) máquina(s) que se ejecutan en un(os) nodo(s) de procesamiento físico en una(s) red(es)). Como se ilustra, en este ejemplo, el nodo 1600 de acceso de radio incluye el sistema 1602 de control que incluye uno o más procesadores 1604 (por ejemplo, CPU, ASIC, FPGA y/o similares), la memoria 1606, y la interfaz 1608 de red y la una o más unidades 1610 de radio que cada una incluye el uno o más transmisores 1612 y el uno o más receptores 1614 acoplados a la una o más antenas 1616, como se describió anteriormente. El sistema 1602 de control está conectado a la(s) unidad(es) 1610 de radio a través de, por ejemplo, un cable óptico o similar. El sistema 1602 de control está conectado a uno o más nodos 1700 de procesamiento acoplados o incluidos como parte de una(s) red(es) 1702 a través de la interfaz 1608 de red. Cada nodo 1700 de procesamiento incluye uno o más procesadores 1704 (por ejemplo, CPU, ASIC, FPGA y/o similares), la memoria 1706, y una interfaz 1708 de red.
En este ejemplo, las funciones 1710 del nodo 1600 de acceso de radio descrito en la presente memoria se implementan en uno o más nodos 1700 de procesamiento o se distribuyen a través del sistema 1602 de control y el uno o más nodos 1700 de procesamiento en cualquier manera deseada. En algunas realizaciones particulares, algunas o todas las funciones 1710 del nodo 1600 de acceso de radio descritas en la presente memoria se implementan como componentes virtuales ejecutados por una o más máquinas virtuales implementadas en un entorno(s) virtual(es) alojado(s) por el nodo(s) 1700 de procesamiento. Como apreciará un experto en la técnica, se usa señalización o comunicación adicional entre el(los) nodo(s) 1700 de procesamiento y el sistema 1602 de control para llevar a cabo al menos algunas de las funciones 1710 deseadas. En particular, en algunas realizaciones, el sistema 1602 de control puede no estar incluido, en cuyo caso la(s) unidad(es) 1610 de radio se comunican directamente con el(los) nodo(s) 1700 de procesamiento a través de una(s) interfaz(es) de red apropiada(s).
En algunas realizaciones, se proporciona un programa informático que incluye instrucciones que, cuando se ejecuta por al menos un procesador, hace que el al menos un procesador lleve a cabo la funcionalidad del nodo 1600 de acceso de radio o un nodo (por ejemplo, un nodo 1700 de procesamiento) que implementa uno o más funciones 1710 del nodo 1600 de acceso de radio en un entorno virtual según cualquiera de las realizaciones descritas en la presente memoria. En algunas realizaciones, se proporciona una portadora que comprende el producto de programa informático mencionado anteriormente. La portadora es una de una señal electrónica, una señal óptica, una señal de radio, o un medio de almacenamiento legible por ordenador (por ejemplo, un medio legible por ordenador no transitorio tal como la memoria).
La figura 18 es un diagrama de bloques esquemático del nodo 1600 de acceso de radio según algunas otras formas de realización de la presente descripción. El nodo 1600 de acceso de radio incluye uno o más módulos 1800, cada uno de los cuales está implementado en software. El(los) módulo(s) 1800 proporcionan la funcionalidad del nodo 1600 de acceso de radio descrito en la presente memoria. Esta discusión es igualmente aplicable al nodo 1700 de procesamiento de la figura 17 donde los módulos 1800 pueden implementarse en uno de los nodos 1700 de procesamiento o distribuirse a través de múltiples nodos 1700 de procesamiento y/o distribuirse a través del(de los) nodo(s) 1700 de procesamiento y el sistema 1602 de control.
La figura 19 es un diagrama de bloques esquemático de un UE 1900 según algunas formas de realización de la presente descripción. Como se ilustra, el UE 1900 incluye uno o más procesadores 1902 (por ejemplo, CPU, ASIC, FPGA y/o similares), la memoria 1904, y uno o más transceptores 1906, cada uno de los cuales incluye uno o más transmisores 1908 y uno o más receptores 1910 acoplados a una o más antenas 1912. El(los) transceptor(es) 1906 incluye circuitos frontales de radio conectado a la(s) antena(s) 1912 que está configurado para acondicionar señales comunicadas entre la(s) antena(s) 1912 y el(los) procesador(es) 1902, como apreciará un experto en la técnica. Los procesadores 1902 se denominan también en la presente memoria como circuitos de procesamiento. Los transceptores 1906 se denominan también en la presente memoria como circuitos de radio. En algunas realizaciones, la funcionalidad del UE 1900 descrita anteriormente puede implementarse total o parcialmente en software que se almacena, por ejemplo, en la memoria 1904 y se ejecuta por el(los) procesador(es) 1902. Hay que tener en cuenta que el UE 1900 puede incluir componentes adicionales que no se ilustran en la figura 19 tales como, por ejemplo, uno o más componentes de interfaz de usuario (por ejemplo, una interfaz de entrada/salida que incluye una pantalla, botones, una pantalla táctil, un micrófono, un(os) altavoz(ces), y/o similares y/o cualquier otro componente para permitir la entrada de información en el UE 1900 y/o permitir la salida de información desde el UE 1900), una fuente de alimentación (por ejemplo, una batería y circuitos de alimentación asociados), etc.
En algunas realizaciones, se proporciona un programa informático que incluye instrucciones que, cuando son ejecutadas por al menos un procesador, hace que el al menos un procesador lleve a cabo la funcionalidad 1900 del UE según cualquiera de las realizaciones descritas en la presente memoria. En algunas realizaciones, se proporciona una portadora que comprende el producto de programa informático mencionado anteriormente. La portadora es una de entre una señal electrónica, una señal óptica, una señal de radio, o un medio de almacenamiento legible por ordenador (por ejemplo, un medio legible por ordenador no transitorio tal como la memoria).
La figura 20 es un diagrama de bloques esquemático del UE 1900 según algunas otras realizaciones de la presente descripción. El UE 1900 incluye uno o más módulos 2000, cada uno de los cuales está implementado en software. El(los) módulo(s) 2000 proporcionan la funcionalidad 1900 del UE descrito en la presente memoria.
La figura 21 ilustra un sistema de comunicación según algunas formas de realización de la presente descripción. Con referencia a la Figura 21, según una realización, un sistema de comunicación incluye una red 2100 de telecomunicaciones, tal como una red celular de tipo 3GPP, que comprende una red 2102 de acceso, tal como una RAN, y una red 2104 central. La red 2102 de acceso comprende una pluralidad de estaciones base 2106A, 2106B, 2106C, tales como NB, eNB, gNB, u otros tipos de puntos de acceso (en inglés, Access Points, APs) inalámbricos, cada una de las cuales define un área 2108A, 2108B, 2108C de cobertura correspondiente. Cada estación base 2106A, 2106B, 2106C se puede conectar a la red 2104 central a través de una conexión 2110 cableada o inalámbrica. Un primer UE 2112 ubicado en el área 2108C de cobertura está configurado para conectarse de forma inalámbrica a, o ser buscado por, la correspondiente estación base 2106C. Un segundo UE 2114 en el área 2108A de cobertura se puede conectar de forma inalámbrica a la correspondiente estación base 2106A. Si bien en este ejemplo se ilustra una pluralidad de UE 2112, 2114, las realizaciones descritas son igualmente aplicables a una situación donde un único UE está en el área de cobertura o donde un único UE se conecta a la correspondiente estación base 2106.
La red 2100 de telecomunicaciones está conectada por sí misma a un ordenador 2116 principal, que puede estar incorporada en el hardware y/o software de un servidor autónomo, un servidor implementado en la nube, un servidor distribuido, o como recursos de procesamiento en una granja de servidores. El ordenador 2116 principal puede estar bajo la propiedad o el control de un proveedor de servicios, o puede ser operado por el proveedor de servicios o en nombre del proveedor de servicios. Las conexiones 2118 y 2120 entre la red 2100 de telecomunicaciones y el ordenador 2116 principal pueden extenderse directamente desde la red 2104 central al ordenador 2116 principal o pueden ir a través de una red 2122 intermedia opcional. La red 2122 intermedia puede ser una de, o una combinación de más de, una red pública, privada, o alojada; la red 2122 intermedia, si la hay, puede ser una red troncal o Internet; en particular, la red 2122 intermedia puede comprender dos o más subredes (no mostradas).
El sistema de comunicación de la figura 21 en su conjunto permite la conectividad entre los UE 2112, 2114 conectados y el ordenador 2116 principal. La conectividad puede describirse como una conexión 2124 de transmisión libre (en inglés, Over-the-Top, OTT). El ordenador 2116 principal y los UE 2112, 2114 conectados están configurados para comunicar datos y/o señalización a través de la conexión 2124 OTT, usando la red 2102 de acceso, la red 2104 central, cualquier red 2122 intermedia, y una posible infraestructura adicional (no mostrada) como intermediarios. La conexión 2124 OTT puede ser transparente en el sentido de que los dispositivos de comunicación participantes a través de los cuales pasa la conexión 2124 OTT desconocen el enrutamiento de las comunicaciones de enlace ascendente y descendente. Por ejemplo, la estación base 2106 puede no ser o no necesita ser informada sobre el enrutamiento pasado de una comunicación de enlace descendente entrante con datos que se originan en el ordenador 2116 principal para ser reenviados (por ejemplo, entregados) a un UE 2112 conectado. De forma similar, la estación 2106 no necesita estar al tanto del futuro enrutamiento de una comunicación de enlace ascendente saliente que se origina desde el UE 2112 hacia el ordenador 2116 principal.
La figura 22 ilustra un sistema de comunicación según algunas otras realizaciones de la presente descripción. Implementaciones de ejemplo, según una realización, del UE, la estación base y el ordenador principal discutidas en los párrafos anteriores se describirán ahora con referencia a la figura 22. En un sistema 2200 de comunicación, un ordenador 2202 principal comprende hardware 2204 que incluye una interfaz 2206 de comunicación configurada para establecer y mantener una conexión cableada o inalámbrica con una interfaz de un dispositivo de comunicación diferente del sistema 2200 de comunicación. El ordenador 2202 principal comprende además circuitos 2208 de procesamiento, que pueden tener capacidades de almacenamiento y/o procesamiento. En particular, los circuitos 2208 de procesamiento pueden comprender uno o más procesadores programables, ASIC, FPGA, o combinaciones de estos (no mostrados) adaptados para ejecutar instrucciones. El ordenador 2202 principal comprende además el software 2210, que está almacenado en o accesible por el ordenador 2202 principal y ejecutable por los circuitos 2208 de procesamiento. El software 2210 incluye una aplicación 2212 principal. La aplicación 2212 principal puede ser operable para proporcionar un servicio a un usuario remoto, tal como un UE 2214 que se conecta a través de una conexión 2216 OTT que termina en el UE 2214 y el ordenador 2202 principal. Al proporcionar el servicio al usuario remoto, la aplicación 2212 principal puede proporcionar datos de usuario que se transmiten usando la conexión 2216 OTT.
El sistema 2200 de comunicación incluye además una estación base 2218 proporcionada en un sistema de telecomunicaciones y que comprende hardware 2220 que le permite comunicarse con el ordenador 2202 principal y con el UE 2214. El hardware 2220 puede incluir una interfaz 2222 de comunicación para establecer y mantener una conexión por cable o inalámbrica con una interfaz de un dispositivo de comunicación diferente del sistema 2200 de comunicación, así como una interfaz 2224 de radio para establecer y mantener al menos una conexión 2226 inalámbrica con el UE 2214 ubicado en un área de cobertura (no se muestra en la figura 22) servida por la estación base 2218. La interfaz 2222 de comunicación puede configurarse para facilitar una conexión 2228 al ordenador 2202 principal. La conexión 2228 puede ser directa o puede pasar a través de una red central (no mostrada en la figura 22) del sistema de telecomunicaciones y/o a través de una o más redes intermedias fuera del sistema de telecomunicaciones. En la realización mostrada, el hardware 2220 de la estación base 2218 incluye además circuitos 2230 de procesamiento, que pueden comprender uno o más procesadores programables, ASIC, FPGA, o combinaciones de estos (no mostrados) adaptados para ejecutar instrucciones. La estación base 2218 tiene además software 2232 almacenado internamente o accesible a través de una conexión externa.
El sistema 2200 de comunicación incluye además el UE 2214 ya mencionado. El hardware 2234 del UE 2214 puede incluir una interfaz 2236 de radio configurada para establecer y mantener una conexión 2226 inalámbrica con una estación base que sirve a un área de cobertura en la que está ubicado actualmente el UE 2214. El hardware 2234 del UE 2214 incluye además circuitos 2238 de procesamiento, que puede comprender uno o más procesadores programables, ASIC, FPGA, o combinaciones de estos (no mostrados) adaptados para ejecutar instrucciones. El UE 2214 comprende además software 2240, que está almacenado o accesible por el UE 2214 y ejecutable por los circuitos 2238 de procesamiento. El software 2240 incluye una aplicación 2242 cliente. La aplicación 2242 cliente puede ser operable para proporcionar un servicio a un ser humano o un usuario no humano a través del UE 2214, con el soporte del ordenador 2202 principal. En el ordenador 2202 principal, la aplicación 2212 principal en ejecución puede comunicarse con la aplicación 2242 cliente en ejecución a través de la conexión 2216 OTT que termina en el UE 2214 y el ordenador 2202 principal. Al proporcionar el servicio al usuario, la aplicación 2242 cliente puede recibir datos de solicitud de la aplicación 2212 principal y proporcionar datos de usuario en respuesta a los datos de solicitud. La conexión 2216 OTT puede transferir tanto los datos de solicitud como los datos de usuario. La aplicación 2242 cliente puede interactuar con el usuario para generar los datos de usuario que proporciona.
Se observa que el ordenador 2202 principal, la estación base 2218, y el UE 2214 ilustrados en la figura 22 pueden ser similares o idénticos al ordenador 2116 principal, una de las estaciones base 2106A, 2106B, 2106C, y uno de los UE 2112, 2114 de la figura 21, respectivamente. Es decir, el funcionamiento interno de estas entidades puede ser como se muestra en la figura 22 e independientemente, la topología de la red circundante puede ser la de la figura 21.
En la figura 22, la conexión 2216 OTT se ha dibujado de forma abstracta para ilustrar la comunicación entre el ordenador 2202 principal y el UE 2214 a través de la estación base 2218 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 configurarse para ocultarse del UE 2214 o del proveedor de servicios que opera el ordenador 2202 principal, o ambos. Mientras la conexión 2216 OTT está activa, la infraestructura de red puede además tomar decisiones por las cuales cambia dinámicamente el enrutamiento (por ejemplo, sobre la base de la consideración del equilibrio de carga o la reconfiguración de red).
La conexión 2226 inalámbrica entre el UE 2214 y la estación base 2218 está según las enseñanzas de las realizaciones descritas a lo largo de esta descripción. Una o más de las varias realizaciones mejoran el rendimiento de los servicios OTT proporcionados al UE 2214 usando la conexión 2216 OTT, en la que la conexión 2226 inalámbrica forma el último segmento. Más precisamente, las enseñanzas de estas realizaciones pueden reducir el tiempo requerido para realizar una liberación y redirección para un UE que está en el estado RRC_INACTIVE y, por tanto, proporcionar beneficios tales como capacidad de respuesta mejorada del UE, señalización reducida entre el UE y las entidades de red, y reducción del consumo de energía por el UE.
Puede proporcionarse un procedimiento de medición con el fin de supervisar la tasa 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 2216 OTT entre el ordenador 2202 principal y el UE 2214, 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 2216 OTT puede implementarse en el software 2210 y el hardware 2204 del ordenador 2202 principal o en el software 2240 y el hardware 2234 del UE 2214, o ambos. En algunas realizaciones, los sensores (no mostrados) pueden desplegarse en o en asociación con dispositivos de comunicación a través de los cuales pasa la conexión 2216 OTT; los sensores pueden participar en el procedimiento de medición suministrando valores de las cantidades supervisadas ejemplificadas anteriormente, o suministrando valores de otras cantidades físicas de las cuales el software 2210, 2240 puede calcular o estimar las cantidades supervisadas. La reconfiguración de la conexión 2216 OTT puede incluir formato de mensaje, ajustes de retransmisión, enrutamiento preferido, etc.; la reconfiguración no necesita afectar a la estación base 2218, y puede ser desconocida o imperceptible para la estación base 2218. Tales procedimientos y funcionalidades pueden ser conocidos y practicados en la técnica. En ciertas realizaciones, las mediciones pueden implicar señalización de UE propia que facilita las mediciones de rendimiento del ordenador 2202 principal, tiempos de propagación, latencia, y similares. Las mediciones se pueden implementar de manera que el software 2210 y 2240 haga que se transmitan mensajes, en particular mensajes vacíos o "ficticios", usando la conexión 2216 OTT mientras supervisa los tiempos de propagación, errores, etc.
La figura 23 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción. El sistema de comunicación incluye un ordenador principal, una estación base, y un UE que pueden ser los descritos con referencia a las figuras 21 y 22. Para simplificar la presente descripción, en esta sección sólo se incluirán las referencias de los dibujos a la figura 23. En la etapa 2300, el ordenador principal proporciona datos de usuario. En la subetapa 2302 (que puede ser opcional) de la etapa 2300, el ordenador principal proporciona los datos de usuario ejecutando una aplicación principal. En la etapa 2304, el ordenador principal inicia una transmisión que lleva los datos de usuario al UE. En la etapa 2306 (que puede ser opcional), la estación base transmite al UE los datos de usuario que se llevaron en la transmisión que inició el ordenador principal, según las enseñanzas de las realizaciones descritas a lo largo de esta descripción. En la etapa 2308 (que también puede ser opcional), el UE ejecuta una aplicación de cliente asociada con la aplicación principal ejecutada por el ordenador principal.
La figura 24 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción. El sistema de comunicación incluye un ordenador principal, una estación base, y un UE que pueden ser los descritos con referencia a las figuras 21 y 22. Para simplificar la presente descripción, en esta sección sólo se incluirán las referencias de los dibujos a la figura 24. En la etapa 2400 del método, el ordenador principal proporciona datos de usuario. En una subetapa opcional (no mostrada), el ordenador principal proporciona los datos de usuario ejecutando una aplicación principal. En la etapa 2402, el ordenador principal inicia una transmisión que lleva los datos de usuario al UE. La transmisión puede pasar a través de la estación base, según las enseñanzas de las realizaciones descritas a lo largo de esta descripción. En la etapa 2404 (que puede ser opcional), el UE recibe los datos de usuario transportados en la transmisión.
La figura 25 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción. El sistema de comunicación incluye un ordenador principal, una estación base, y un UE que pueden ser los descritos con referencia a las figuras 21 y 22. Para simplificar la presente descripción, en esta sección solo se incluirán las referencias de los dibujos a la figura 25. En la etapa 2500 (que puede ser opcional), el UE recibe datos de entrada proporcionados por el ordenador principal. Adicional o alternativamente, en la etapa 2502, el UE proporciona datos de usuario. En la subetapa 2504 (que puede ser opcional) de la etapa 2500, el UE proporciona los datos de usuario ejecutando una aplicación de cliente. En la subetapa 2506 (que puede ser opcional) de la etapa 2502, el UE ejecuta una aplicación de cliente que proporciona los datos de usuario en reacción a los datos de entrada recibidos proporcionados por el ordenador principal. Al proporcionar los datos de usuario, la aplicación de cliente ejecutada puede considerar además la entrada de usuario recibida del usuario. Independientemente de la manera específica en que se proporcionaron los datos de usuario, el UE inicia, en la subetapa 2508 (que puede ser opcional), la transmisión de los datos de usuario al ordenador principal. En la etapa 2510 del método, el ordenador principal recibe los datos de usuario transmitidos desde el UE, según las enseñanzas de las realizaciones descritas a lo largo de esta descripción.
La figura 26 es un diagrama de flujo que ilustra un método implementado en un sistema de comunicación, según algunas realizaciones de la presente descripción. El sistema de comunicación incluye un ordenador principal, una estación base, y un UE que pueden ser los descritos con referencia a las figuras 21 y 22. Para simplificar la presente descripción, en esta sección sólo se incluirán las referencias de los dibujos a la figura 26. En la etapa 2600 (que puede ser opcional), según las enseñanzas de las realizaciones descritas a lo largo de esta descripción, la estación base recibe datos de usuario del UE. En la etapa 2602 (que puede ser opcional), la estación base inicia la transmisión de los datos de usuario recibidos al ordenador principal. En la etapa 2604 (que puede ser opcional), el ordenador principal recibe los datos de usuario transportados en la transmisión iniciada por la estación base.
Cualquier etapa, método, característica, función, o beneficio apropiado descrito en la presente memoria puede realizarse a través de una o más unidades funcionales o módulos de uno o más aparatos virtuales. Cada aparato virtual puede comprender varias de estas unidades funcionales. Estas unidades funcionales pueden implementarse a través de circuitos de procesamiento, que pueden incluir uno o más microprocesadores o microcontroladores, así como otro hardware digital, que puede incluir procesadores de señales digitales (en inglés, Digital Signal Processor, DSP), lógica digital de propósito especial, y similares. Los circuitos de procesamiento pueden configurarse para ejecutar el código de programa almacenado en la memoria, que puede incluir uno o varios tipos de memoria, tales como memoria de solo lectura (en inglés, Read Only Memory, ROM), memoria de acceso aleatorio (en inglés, Random Access Memory, RAM), memoria caché, dispositivos de memoria flash, dispositivos de almacenamiento óptico, etc. El código de programa almacenado en memoria incluye instrucciones de programa para ejecutar uno o más protocolos de telecomunicaciones y/o comunicaciones de datos, así como instrucciones para llevar a cabo una o más de las técnicas descritas en la presente memoria. En algunas implementaciones, los circuitos de procesamiento se pueden usar para hacer que la unidad funcional respectiva realice las funciones correspondientes según una o más realizaciones de la presente descripción.
Si bien los procesos en las figuras pueden mostrar un orden particular de operaciones realizadas por ciertas realizaciones de la presente descripción, debe entenderse que tal orden es ejemplar (por ejemplo, realizaciones alternativas pueden realizar las operaciones en un orden diferente, combinar ciertas operaciones, superponer ciertas operaciones, etc.).
En esta descripción pueden usarse al menos algunas de las siguientes abreviaturas. Si hay una inconsistencia entre las abreviaturas, se debe dar preferencia a cómo se usa anteriormente. Si se enumera varias veces a continuación, se debe preferir la primera lista a cualquier lista(s) posterior(es).
3G Tercera generación
3GPP Proyecto de asociación de tercera generación
4G Cuarta generación
5G Quinta generación
5GS Sistema de quinta generación
5GMM Gestión de movilidad del sistema de quinta generación
5GC Red central de quinta generación
5G-S-TMSI Quinta generación: evolución de la arquitectura del sistema: identidad de abonado móvil temporal AF Función de aplicación
AMF Función de gestión de acceso y movilidad
AN Red de acceso
AP Punto de acceso
ARFCN Número absoluto de canal de radiofrecuencia
AS Estrato de acceso
ASIC Circuito integrado de aplicación especifica
AUSF Función del servidor de autenticación
CA Agregación de portadoras
CN Red central
CPU Unidad central de procesamiento
C-RNTI Identificador temporal de la red de radio celular
DC Conectividad dual
DL Enlace descendente
DN Red de datos
DRB Portador de radio de datos
DRX Recepción discontinua
DSP Procesador de señal digital
eNB Nodo B mejorado o evolucionado
EPC Núcleo de paquetes mejorado o evolucionado
E-UTRA Acceso de radio terrestre universal evolucionado
E-UTRAN Red de acceso de radio terrestre universal evolucionada
FDD Duplexación por división de frecuencia
FFS Para mayor estudio
FPGA Matriz de compuertas lógicas programables de campo
gNB Nueva estación base de radio
ID Identificador / Identidad
IP Protocolo de Internet
I-RNTI Identificador temporal de la red de radio para el estado RRC_INACTIVE LS Declaración de enlace
LTE Evolución a largo plazo
MA Autoridad de movimiento
MAC Control de acceso al medio
MCG Grupo de celdas maestras
MCS Soporte de misión crítica
MME Entidad de gestión de la movilidad
MO Móvil originado (originado por móvil)
MPS Servicio Prioritario Multimedia
MT Móvil terminado (terminado por móvil)
MTC Comunicación de tipo de máquina
NAS Estrato de no acceso
NB Banda estrecha
NCC Contador de encadenamiento del siguiente salto
NEF Función de exposición de red
NF Función de red
NH Siguiente salto
NR Radio nueva
NRF Función de repositorio de red
NSSF Función de selección de segmento de red
OTT De transmisión libre
PCell Celda primaria
PCF Función de control de políticas
PDCP Protocolo de convergencia de paquetes de datos
PDU Unidad de datos de protocolo
P-GW Puerta de enlace de red de paquetes de datos
PLMN Red móvil terrestre pública
QoS Calidad de servicio
RAM Memoria de acceso aleatorio
RAN Red de acceso de radio
RAT Tecnología de acceso de radio
RLC Control de enlace de radio
RNA Adaptación del usuario de la parte de aplicación del subsistema de red de radio
RNAU Actualización de la adaptación del usuario de la parte de aplicación del subsistema de red de radio
RNTI Identificador temporal de la red de radio
ROHC Compresión de cabecera robusta
ROM Memoria de solo lectura
RRC Control de recursos de radio
RRH Cabezal de radio remota
RTT Tiempo de ida y vuelta
SAE Evolución de la arquitectura del sistema
SAP Punto de acceso al servicio
SCEF Función de exposición de capacidad de servicio
SCell Celda secundaria
SGC Grupo de celdas secundarias
SDAP Protocolo de adaptación de datos de servicio
SGC Función de gestión de sesiones
SMS Servicio de mensajes cortos
SpCell Celda especial
SRB Portador de radio de señalización
TMSI Identidad temporal del suscriptor móvil
TS Especificación técnica
UDM Gestión de datos unificada
UE Equipo de usuario
UTRA Acceso de radio terrestre universal
UTRAN Red de acceso de radio terrestre universal
VoIP Voz sobre protocolo de internet
X2AP Protocolo de aplicación de interfaz X2
XnAP Protocolo de aplicación de interfaz Xn
Claims (12)
1. Un método para hacer funcionar un sistema de comunicaciones, el sistema de comunicaciones comprende un dispositivo inalámbrico y una estación base, el método en el sistema comprende:
enviar (600) desde el dispositivo inalámbrico, una solicitud para reanudar la comunicación, mientras está en un estado INACTIVO de control de recursos de radio, RRC, caracterizado por que:
en respuesta a recibir la solicitud para reanudar la comunicación a la estación base, y sin enviar primero al dispositivo inalámbrico una instrucción para reanudar, enviar (706), desde la estación base, una instrucción para liberar y redirigir, y
en respuesta a recibir la instrucción para liberar y redirigir en el dispositivo inalámbrico y sin entrar en un estado CONECTADO de RRC, realizar (614) selección de celda en una tecnología de acceso de radio, RAT, e intentar establecer (620) o reanudar (618) comunicación con una celda seleccionada.
2. El método de la reivindicación 1, en donde la solicitud para reanudar la comunicación comprende un mensaje RRCResumeRequest y la instrucción para liberar y redirigir comprende un mensaje RRCRelease.
3. El método de una cualquiera de las reivindicaciones 1 - 2, en donde la instrucción para liberar y redirigir identifica la RAT en la que se realizará la selección de celda.
4. El método de una cualquiera de las reivindicaciones 1 - 3, en donde la RAT en la que se realizará la selección de celda comprende una frecuencia de radio nueva, NR, o una frecuencia de evolución a largo plazo, LTE.
5. El método de una cualquiera de las reivindicaciones 1 - 4, en donde intentar establecer o reanudar la comunicación con la celda seleccionada comprende intentar establecer comunicación con la celda seleccionada.
6. El método de la reivindicación, en donde intentar establecer comunicación con la celda seleccionada comprende realizar un procedimiento de establecimiento de RRC.
7. El método de una cualquiera de las reivindicaciones 1 - 4, en donde intentar establecer o reanudar la comunicación con la celda seleccionada comprende intentar reanudar la comunicación con la celda seleccionada.
8. El método de la reivindicación 8, en donde intentar reanudar la comunicación con la celda seleccionada comprende realizar un procedimiento de reanudación de RRC.
9. El método de una cualquiera de las reivindicaciones 1 - 8, que comprende además, antes de enviar la instrucción para liberar y redirigir, realizar una reubicación de contexto en la estación base.
10. El método de la reivindicación 9, en donde realizar la reubicación de contexto comprende además las etapas de:
recuperar, desde una última estación base de servicio, un contexto asociado con el UE;
enviar, a una función de gestión de acceso y movilidad, AMF, una solicitud de cambio de ruta; y recibir, de la AMF, una respuesta de solicitud de cambio de ruta.
11. El método de la reivindicación 9 o 10 que comprende además, después de enviar la instrucción para liberar y redirigir, enviar, a la última estación base de servicio, una instrucción para liberar el contexto asociado con el UE.
12. Un sistema de comunicaciones que comprende:
un dispositivo inalámbrico adaptado para enviar, una solicitud para reanudar la comunicación, mientras está en un estado INACTIVO de control de recursos de radio, RRC, caracterizado por:
una estación base adaptada para, en respuesta a recibir la solicitud para reanudar la comunicación a la estación base, y sin enviar primero al dispositivo inalámbrico una instrucción para reanudar, enviar (706), una instrucción para liberar y redirigir, y
en respuesta a recibir la instrucción para liberar y redirigir en el dispositivo inalámbrico y sin entrar en un estado CONECTADO de RRC, el dispositivo inalámbrico está además adaptado para realizar (614) selección de celda en una tecnología de acceso de radio, RAT, e intentar establecer (620) o reanudar (618) comunicación con una celda seleccionada.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862736332P | 2018-09-25 | 2018-09-25 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2961827T3 true ES2961827T3 (es) | 2024-03-14 |
Family
ID=67211796
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES19737268T Active ES2888407T3 (es) | 2018-09-25 | 2019-06-27 | Solicitud de reanudación seguida por liberación y redirección |
| ES22171190T Active ES2961827T3 (es) | 2018-09-25 | 2019-06-27 | Solicitud de reanudación seguida por liberación y redirección |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES19737268T Active ES2888407T3 (es) | 2018-09-25 | 2019-06-27 | Solicitud de reanudación seguida por liberación y redirección |
Country Status (12)
| Country | Link |
|---|---|
| US (3) | US11924693B2 (es) |
| EP (3) | EP3677089B1 (es) |
| JP (1) | JP7145319B2 (es) |
| CN (1) | CN112740824B (es) |
| BR (1) | BR112021004810A2 (es) |
| CO (1) | CO2021004048A2 (es) |
| DK (1) | DK3826422T3 (es) |
| ES (2) | ES2888407T3 (es) |
| HU (1) | HUE054234T2 (es) |
| PL (1) | PL3677089T3 (es) |
| PT (1) | PT3826422T (es) |
| WO (1) | WO2020067944A1 (es) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10667185B2 (en) * | 2018-03-28 | 2020-05-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for avoiding unnecessary actions in resume procedure |
| JP6970650B2 (ja) * | 2018-09-20 | 2021-11-24 | Kddi株式会社 | 待ち受け状態で通信を行う端末装置、その制御方法、及びプログラム |
| CN115996486A (zh) * | 2018-10-04 | 2023-04-21 | 谷歌有限责任公司 | 用于处理无线电资源控制小区组配置的方法 |
| WO2021025246A1 (en) * | 2019-08-06 | 2021-02-11 | Lg Electronics Inc. | Method and apparatus for handling security information between a wireless device and a network for a fast rrc release procedure in a wireless communication system |
| EP4044759A4 (en) * | 2019-11-07 | 2022-11-02 | Huawei Technologies Co., Ltd. | RADIO RESOURCE CONTROL (RRC) CONNECTION RESTORATION METHOD AND DEVICE |
| EP4122284A1 (en) * | 2020-03-18 | 2023-01-25 | Telefonaktiebolaget LM ERICSSON (PUBL) | Determination of operational state |
| CN113840337B (zh) * | 2020-06-23 | 2022-09-20 | 荣耀终端有限公司 | 一种提升终端寻呼响应速度的方法及终端 |
| CN113905457B (zh) * | 2020-07-06 | 2023-08-08 | 维沃移动通信有限公司 | 消息发送方法、接收方法、装置及通信设备 |
| CN113905452B (zh) * | 2020-07-06 | 2023-08-08 | 维沃移动通信有限公司 | 消息发送方法、接收方法、装置及通信设备 |
| WO2022027612A1 (zh) * | 2020-08-07 | 2022-02-10 | 华为技术有限公司 | 信令传输的方法和装置 |
| BR102021016648A2 (pt) * | 2020-08-26 | 2022-03-08 | Nokia Technologies Oy | Realocação de contexto de equipamento de usuário na borda de área de notificação de rede de acesso de rádio |
| US20220078875A1 (en) * | 2020-09-08 | 2022-03-10 | Asustek Computer Inc. | Method and apparatus for timer control for rrc connection resume procedure in a wireless communication system |
| EP3968696A1 (en) * | 2020-09-15 | 2022-03-16 | Nokia Technologies Oy | Ng based context release and data forwarding for multi-hop mobility |
| WO2022067660A1 (zh) * | 2020-09-30 | 2022-04-07 | 华为技术有限公司 | 一种小区驻留方法及装置 |
| WO2022082582A1 (en) * | 2020-10-22 | 2022-04-28 | Apple Inc. | Rrc-based user data transmission in inactive state |
| GB2608262A (en) * | 2021-05-11 | 2022-12-28 | Samsung Electronics Co Ltd | Improvements in and relating to proximity services in a telecommunication network |
| KR20230021425A (ko) * | 2021-08-05 | 2023-02-14 | 김성훈 | 무선 이동 통신 시스템에서 rrc 연결을 재개하는 방법 및 장치 |
| CN113727467A (zh) * | 2021-09-24 | 2021-11-30 | Oppo广东移动通信有限公司 | 一种恢复rrc连接的方法、装置、芯片、设备及存储介质 |
| WO2024031268A1 (en) * | 2022-08-08 | 2024-02-15 | Zte Corporation | Methods and devices for determining target cell id for mac-i calculation |
| CN115499886A (zh) * | 2022-08-09 | 2022-12-20 | 华为技术有限公司 | 一种mps管理方法及相关装置 |
| US12022383B1 (en) | 2023-11-10 | 2024-06-25 | T-Mobile Usa, Inc. | Radio exposure function for telecommunications networks |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114449603B (zh) | 2012-12-24 | 2024-06-07 | 北京三星通信技术研究有限公司 | 无线通信系统中的基站及由其执行的方法 |
| EP3216306B1 (en) | 2014-11-07 | 2020-09-02 | Telefonaktiebolaget LM Ericsson (publ) | Method and gateway node for suspending and resuming ran-cn connections |
| CN107615828B (zh) | 2015-05-15 | 2021-10-26 | 夏普株式会社 | 终端装置、基站装置以及方法 |
| BR112017014947A2 (pt) | 2016-01-08 | 2018-03-13 | Ericsson Telefon Ab L M | ?método de controle de recurso de rádio, produto de programa de computador, sistema de memória, entidades de rede de comunicação e de terminal, terminal, e, método de realização de um processo de controle de admissão durante uma operação de retomada do controle de recurso de rádio? |
| WO2017135779A1 (ko) | 2016-02-05 | 2017-08-10 | 엘지전자 주식회사 | 무선 통신 시스템에서 rrc 연결 재개를 수행하는 방법 및 장치 |
| US10470218B2 (en) | 2016-05-16 | 2019-11-05 | Cisco Technology, Inc. | System and method for optimized idle and active state transitions of user equipment in a network environment |
| EP3322254A1 (en) | 2016-11-11 | 2018-05-16 | Nokia Technologies Oy | Connection control for dual connectivity and interworking in wireless networks |
| US10028254B2 (en) * | 2016-12-13 | 2018-07-17 | Qualcomm Incorporated | Techniques for improved decoding of system information blocks |
| KR102582554B1 (ko) * | 2017-01-03 | 2023-09-25 | 삼성전자 주식회사 | 차세대 이동 통신 시스템에서 light connection을 지원하는 방법 및 장치 |
| ES2900501T3 (es) * | 2017-01-05 | 2022-03-17 | Nec Corp | Estación base, terminal inalámbrica, y métodos y medios legibles por ordenador no transitorios para los mismos |
| EP3806575A1 (en) | 2017-01-16 | 2021-04-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Tracking area update in rrc_inactive |
| US10624150B2 (en) | 2017-01-30 | 2020-04-14 | FG Innovation Company Limited | Radio resource control connection resume method of wireless communication system |
| CN110546975B (zh) * | 2017-03-17 | 2021-06-04 | 三星电子株式会社 | 无线电接入网络通知区域更新失败 |
| US11184785B2 (en) | 2017-03-17 | 2021-11-23 | Qualcomm Incorporated | Radio measurement and configuration |
| WO2019233119A1 (en) * | 2018-06-06 | 2019-12-12 | Huawei Technologies Co., Ltd. | System and method for supporting measurements and mobility in a wireless communications system |
| EP3609289A1 (en) | 2018-08-10 | 2020-02-12 | Nokia Technologies Oy | Combined rrc inactive resume, rrc rna & nas registration procedure |
-
2019
- 2019-06-27 JP JP2021510942A patent/JP7145319B2/ja active Active
- 2019-06-27 EP EP19737268.3A patent/EP3677089B1/en active Active
- 2019-06-27 CN CN201980062426.0A patent/CN112740824B/zh active Active
- 2019-06-27 ES ES19737268T patent/ES2888407T3/es active Active
- 2019-06-27 ES ES22171190T patent/ES2961827T3/es active Active
- 2019-06-27 HU HUE19737268A patent/HUE054234T2/hu unknown
- 2019-06-27 EP EP20202556.5A patent/EP3826422B1/en active Active
- 2019-06-27 EP EP22171190.6A patent/EP4096344B1/en active Active
- 2019-06-27 PL PL19737268T patent/PL3677089T3/pl unknown
- 2019-06-27 DK DK20202556.5T patent/DK3826422T3/da active
- 2019-06-27 WO PCT/SE2019/050627 patent/WO2020067944A1/en unknown
- 2019-06-27 US US16/489,434 patent/US11924693B2/en active Active
- 2019-06-27 PT PT202025565T patent/PT3826422T/pt unknown
- 2019-06-27 BR BR112021004810-3A patent/BR112021004810A2/pt unknown
-
2021
- 2021-03-31 CO CONC2021/0004048A patent/CO2021004048A2/es unknown
-
2022
- 2022-02-03 US US17/591,994 patent/US11937131B2/en active Active
-
2023
- 2023-12-07 US US18/531,793 patent/US20240137817A1/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| PT3826422T (pt) | 2022-07-05 |
| US11937131B2 (en) | 2024-03-19 |
| EP3826422A1 (en) | 2021-05-26 |
| US11924693B2 (en) | 2024-03-05 |
| JP7145319B2 (ja) | 2022-09-30 |
| CN112740824A (zh) | 2021-04-30 |
| JP2022500898A (ja) | 2022-01-04 |
| CN112740824B (zh) | 2024-06-04 |
| EP3677089A1 (en) | 2020-07-08 |
| EP4096344A1 (en) | 2022-11-30 |
| US20220159518A1 (en) | 2022-05-19 |
| BR112021004810A2 (pt) | 2021-06-01 |
| EP4096344C0 (en) | 2023-08-23 |
| ES2888407T3 (es) | 2022-01-04 |
| US20240137817A1 (en) | 2024-04-25 |
| EP3826422B1 (en) | 2022-06-08 |
| US20200314700A1 (en) | 2020-10-01 |
| HUE054234T2 (hu) | 2021-08-30 |
| CO2021004048A2 (es) | 2021-04-30 |
| EP4096344B1 (en) | 2023-08-23 |
| PL3677089T3 (pl) | 2021-08-02 |
| WO2020067944A1 (en) | 2020-04-02 |
| EP3677089B1 (en) | 2021-01-13 |
| DK3826422T3 (da) | 2022-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2961827T3 (es) | Solicitud de reanudación seguida por liberación y redirección | |
| US11375471B2 (en) | Method for performing service request procedure and apparatus therefor in wireless communication system | |
| US10917868B2 (en) | Method for notifying of mobility event in wireless communication system and device therefor | |
| US11246172B2 (en) | Method for selecting session and service continuity mode in wireless communication system and device therefor | |
| US20220141904A1 (en) | A Master Node, a Secondary Node, a User Equipment and Methods Therein for Handling of a Secondary Cell Group (SCG) | |
| US11284468B2 (en) | Suspending/resuming measurements in RRC inactive state | |
| US10582522B2 (en) | Data transmission and reception method and device of terminal in wireless communication system | |
| KR20200003195A (ko) | 무선 통신 시스템에서 단말의 등록 방법 및 이를 위한 장치 | |
| ES2969548T3 (es) | Contexto de seguridad en un sistema de comunicación inalámbrica | |
| ES2963419T3 (es) | Verificación de la seguridad cuando se reanuda una conexión de RRC | |
| JP2021525467A (ja) | 統合アクセスおよびバックホールモビリティ | |
| US11937168B2 (en) | Method and apparatus for session management | |
| KR20230008697A (ko) | 비-3gpp 핸드오버 준비 | |
| US20220256407A1 (en) | Handling of ue in cm-connected state with rrc inactive state | |
| WO2017166291A1 (zh) | 一种通信方法、终端、基站和移动性管理设备 | |
| EP4335179A2 (en) | Managing ue measurements in an idle or inactive state |