ES2892499T3 - Procedimiento y aparato para liberar una configuración de recursos de enlace ascendente preconfigurados en un sistema de comunicación inalámbrica - Google Patents

Abstract

Un procedimiento de un equipo de usuario, denominado también en lo sucesivo UE, comprendiendo el procedimiento: recibir una configuración de un recurso de enlace ascendente preconfigurado, denominado también en lo sucesivo PUR, cuando el UE está en un estado RRC_CONNECTED (1805); entrar en un estado RRC_IDLE desde el estado RRC_CONNECTED (1810); realizar una primera transmisión usando el PUR cuando el UE está en el estado RRC_IDLE (1815); entrar de nuevo al estado RRC_CONNECTED desde el estado RRC_IDLE (1820); suspender la configuración cuando el UE está de nuevo en el estado RRC_CONNECTED, en el que el UE no realiza transmisiones usando el PUR si la configuración está suspendida (1825); reanudar la configuración cuando el UE vuelve a entrar al estado RRC_IDLE desde el estado RRC_CONNECTED (1830), y realizar una segunda transmisión usando el PUR cuando el UE está de nuevo en el estado RRC_IDLE (1835), estando caracterizado el procedimiento por que además comprende liberar la configuración si el UE recibe una indicación en una información del sistema que indica que una célula de servicio no admite el PUR o que indica que el soporte del PUR está desactivado.

Description

DESCRIPCIÓN

Procedimiento y aparato para liberar una configuración de recursos de enlace ascendente preconfigurados en un sistema de comunicación inalámbrica

Esta divulgación se refiere, en general, a redes de comunicación inalámbrica y, más en particular, a un procedimiento y aparato para liberar una configuración de recursos de enlace ascendente preconfigurados en un sistema de comunicación inalámbrica.

Con el rápido aumento de la demanda de comunicación de grandes cantidades de datos hacia y desde dispositivos de comunicación móvil, las redes de comunicación de voz móviles tradicionales están evolucionando hacia redes que se comunican con paquetes de datos de protocolo de Internet (IP). Dicha comunicación de paquetes de datos IP puede proporcionar a los usuarios de dispositivos de comunicación móvil servicios de comunicación de voz sobre IP, multimedia, multidifusión y bajo demanda.

Una estructura de red ejemplar es una red de acceso por radio terrestre universal evolucionada (E-UTRAN). El sistema E-UTRAN puede proporcionar un alto rendimiento de datos para realizar los servicios multimedia y de voz sobre IP mencionados anteriormente. La organización de normas 3GPP está analizando actualmente una nueva tecnología de radio de próxima generación (por ejemplo, 5G). En consecuencia, se están presentando cambios en el cuerpo actual de la norma 3GPP y se está considerando que evolucione y finalice la norma 3GPP.

Los documentos R2-1816993, R1-1812940 y R1-1812929 de 3GPP divulgan transmisiones de UL sobre recursos dedicados preconfigurados en un modo inactivo.

SUMARIO

Un procedimiento y un equipo de usuario de acuerdo con la invención se definen en las reivindicaciones independientes. Las reivindicaciones dependientes definen modos de realización preferentes de las mismas. BREVE DESCRIPCIÓN DE LOS DIBUJOS

La figura 1 muestra un diagrama de un sistema de comunicación inalámbrica de acuerdo con un modo de realización ejemplar.

La figura 2 es un diagrama de bloques de un sistema transmisor (también conocido como red de acceso) y de un sistema receptor (también conocido como equipo de usuario o UE) de acuerdo con un modo de realización ejemplar.

La figura 3 es un diagrama de bloques funcional de un sistema de comunicación de acuerdo con un modo de realización ejemplar.

La figura 4 es un diagrama de bloques funcional del código de programa de la figura 3 de acuerdo con un modo de realización ejemplar.

La figura 5 es una reproducción de la figura 7.3b-1, que muestra una EDT para optimizaciones de EPS CloT de plano de control, tomada de la especificación 3GPP TS 36.300 V15.3.0.

La figura 6 es una reproducción de la figura 7.3b-2, que muestra una EDT para optimizaciones de EPS CloT de plano de usuario, tomada de la especificación 3GPP Ts 36.300 V15.3.0.

La figura 7 es una reproducción de la figura 10.1.4-1, que ilustra una temporización de WUS, tomada de la especificación 3GPP TS 36.300 V15.3.0.

La figura 8 es una reproducción de la figura 10.1.5.1-1, que ilustra un procedimiento de acceso aleatorio basado en contienda, tomada de la especificación 3GPP TS 36.300 V15.3.0.

La figura 9 es una reproducción de la figura 5.3.3.1-1, que ilustra un establecimiento satisfactorio de una conexión RRC, tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 10 es una reproducción de la figura 5.3.3.1-2, que ilustra el establecimiento de una conexión RRC rechazada por red, tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 11 es una reproducción de la figura 5.3.3.1-3, que ilustra la reanudación de una conexión RRC (conexión RRC suspendida o RRC_INACTIVE), o el retroceso de UP-EDT para la reanudación de la conexión RRC, con éxito, tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 12 es una reproducción de la figura 5.3.3.1-4, que ilustra la reanudación de una conexión RRC (conexión RRC suspendida o RRC_INACTIVE), o el retroceso de UP-EDT para el establecimiento de una conexión RRC, con éxito, de la especificación 3GPP TS 36.321 V15.3.0.

La figura 13 es una reproducción de la figura 5.3.3.1-5, que ilustra la reanudación de una conexión RRC o UP-EDT, el rechazo de red (conexión RRC suspendida o RRC_INACTIVE) o la liberación (conexión RRC suspendida), tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 14 es una reproducción de la figura 5.3.3.1-6, que ilustra la reanudación de una conexión RRC (RRCINACTIVE), la liberación o suspensión de red o UP-EDT, con éxito, tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 15 es una reproducción de la figura 5.3.3.1-7 CP-EDT, con éxito, tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 16 es una reproducción de la figura 5.3.3.1-8, que ilustra el retroceso de CP-EDT para el establecimiento de una conexión RRC, con éxito, tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 17 es una reproducción de la figura 5.3.3.1-9, que ilustra una CP-EDT, rechazo de red, tomada de la especificación 3GPP TS 36.321 V15.3.0.

La figura 18 es un diagrama de flujo para un modo de realización ejemplar desde la perspectiva de un equipo de usuario (UE).

DESCRIPCIÓN DETALLADA

Los sistemas y dispositivos de comunicación inalámbrica ejemplares descritos a continuación emplean un sistema de comunicación inalámbrica, que admite un servicio de radiodifusión. Los sistemas de comunicación inalámbrica están ampliamente implantados para proporcionar diversos tipos de comunicación, tales como voz, datos, etc. Estos sistemas pueden estar basados en acceso múltiple por división de código (CDMA), acceso múltiple por división de tiempo (TDMA), acceso múltiple por división ortogonal de frecuencia (OFDMA), acceso inalámbrico de LTE (Evolución a Largo Plazo) de 3GPP, LTE-A o LTE-Avanzada (Evolución Avanzada a Largo Plazo) de 3GPP, UMB (Banda Ancha Ultramóvil) de 3GPP2, WiMax, acceso inalámbrico de NR (Nueva Radio) de 3GPP para 5G o algunas otras técnicas de modulación.

En particular, los dispositivos de sistemas de comunicación inalámbrica ejemplares descritos a continuación pueden diseñarse para admitir una o más normas, tal como la norma ofrecida por un consorcio denominado "Proyecto de Colaboración de Tercera Generación" al que se hace referencia en el presente documento como 3GPP, que incluye: TS 36.300 V15.3.0, "E-UTRA and E-UTRAN, Overall description, Stage 2'; TS 36.321 V15.3.0, "E-UTRA, MAC protocol specification"; nota del presidente de RANI #94; nota del presidente RANI #94bis; nota del presidente de RANI #95; y TS 36.331 V15.3.0, "E-UTRA, RRC protocol'.

La figura 1 muestra un sistema de comunicación inalámbrica de acceso múltiple de acuerdo con un modo de realización de la invención. Una red de acceso 100 (AN) incluye grupos de múltiples antenas, uno que incluye la 104 y la 106, otro que incluye la 108 y la 110, y uno adicional que incluye la 112 y la 114. En la figura 1 solo se muestran dos antenas para cada grupo de antenas; sin embargo, se puede utilizar un número mayor o menor de antenas para cada grupo de antenas. Un terminal de acceso (AT) 116 se comunica con las antenas 112 y 114, donde las antenas 112 y 114 transmiten información al terminal de acceso 116 a través de un enlace directo 120 y reciben información desde el terminal de acceso 116 a través de un enlace inverso 118. Un terminal de acceso (AT) 122 se comunica con las antenas 106 y 108, donde las antenas 106 y 108 transmiten información al terminal de acceso (AT) 122 a través de un enlace directo 126 y reciben información desde el terminal de acceso (AT) 122 a través de un enlace inverso 124. En un sistema FDD, los enlaces de comunicación 118, 120, 124 y 126 pueden usar diferentes frecuencias para la comunicación. Por ejemplo, el enlace directo 120 puede usar una frecuencia diferente a la usada por un enlace inverso 118.

Cada grupo de antenas, y/o el área en la que están diseñadas para comunicarse, se denomina a menudo sector de la red de acceso. En el modo de realización, cada grupo de antenas está diseñado para comunicarse con terminales de acceso en un sector de las áreas cubiertas por la red de acceso 100.

En la comunicación a través de los enlaces directos 120 y 126, las antenas transmisoras de la red de acceso 100 pueden utilizar conformación de haz para mejorar la relación de señal a ruido de los enlaces directos para los diferentes terminales de acceso 116 y 122. Asimismo, una red de acceso que usa conformación de haz para transmitir a terminales de acceso dispersados aleatoriamente por toda su cobertura causa menos interferencia en los terminales de acceso de células vecinas que una red de acceso que transmite a través de una única antena a todos sus terminales de acceso.

Una red de acceso (AN) puede ser una estación fija o una estación base usada para comunicarse con los terminales y también puede denominarse punto de acceso, nodo B, estación base, estación base mejorada, nodo B evolucionado (eNB), nodo de red, red, o recibir alguna otra denominación. Un terminal de acceso (AT) también puede denominarse equipo de usuario (UE), dispositivo de comunicación inalámbrica, terminal, terminal de acceso o recibir alguna otra denominación.

La figura 2 es un diagrama de bloques simplificado de un modo de realización de un sistema transmisor 210 (también conocido como la red de acceso) y un sistema receptor 250 (también conocido como terminal de acceso (AT) o equipo de usuario (UE)) en un sistema MIMO 200. En el sistema transmisor 210 se proporcionan datos de tráfico para un número de flujos de datos desde una fuente de datos 212 a un procesador de datos de transmisión (TX) 214.

Preferentemente, cada flujo de datos se transmite a través de una antena transmisora respectiva. El procesador de datos de TX 214 da formato, codifica e intercala los datos de tráfico para cada flujo de datos basándose en un esquema de codificación particular seleccionado para que ese flujo de datos proporcione datos codificados.

Los datos codificados para cada flujo de datos se pueden multiplexar con datos piloto usando técnicas de OFDM. Los datos piloto son típicamente un patrón de datos conocido que se procesa de una manera conocida y que se puede usar en el sistema receptor para estimar la respuesta de canal. Los datos codificados y piloto multiplexados para cada flujo de datos se modulan entonces (es decir, se correlacionan con símbolos) en base a un esquema de modulación particular (por ejemplo, BPSK, QPSK, M-PSK o M-QAM) seleccionado para ese flujo de datos para proporcionar símbolos de modulación. La velocidad de transferencia de datos, la codificación y la modulación para cada flujo de datos se pueden determinar mediante instrucciones realizadas por el procesador 230.

Los símbolos de modulación para todos los flujos de datos se proporcionan a continuación a un procesador MIMO de TX 220, que puede procesar adicionalmente los símbolos de modulación (por ejemplo, para OFDM). El procesador MIMO de TX 220 proporciona a continuación N^t flujos de símbolos de modulación a N^t transmisores (TMTR) 222a a 222t. En determinados modos de realización, el procesador de MIMO de TX 220 aplica ponderaciones de conformación de haz a los símbolos de los flujos de datos y a la antena desde la cual se está transmitiendo el símbolo.

Cada transmisor 222 recibe y procesa un respectivo flujo de símbolos para proporcionar una o más señales analógicas, y acondiciona adicionalmente (por ejemplo, amplifica, filtra y eleva en frecuencia) las señales analógicas para proporcionar una señal modulada adecuada para su transmisión a través del canal MIMO. N^t señales moduladas de los transmisores 222a a 222t se transmiten a continuación desde N^t antenas 224a a 224t, respectivamente.

En el sistema receptor 250, las señales moduladas transmitidas se reciben por N^r antenas 252a a 252r, y la señal recibida desde cada antena 252 se proporciona a un receptor (RCVR) respectivo 254a a 254r. Cada receptor 254 acondiciona (por ejemplo, filtra, amplifica y reduce en frecuencia) una señal recibida respectiva, digitaliza la señal acondicionada para proporcionar muestras y procesa adicionalmente las muestras para proporcionar un correspondiente flujo de símbolos "recibido".

Un procesador de datos de RX 260 recibe y procesa a continuación los N^r flujos de símbolos recibidos desde N^r receptores 254 basándose en una técnica particular de procesamiento de receptor para proporcionar N^t flujos de símbolos "detectados". A continuación, el procesador de datos de RX 260 demodula, desintercala y decodifica cada flujo de símbolos detectado para recuperar los datos de tráfico para el flujo de datos. El procesamiento realizado por el procesador de datos de RX 260 es complementario al realizado por el procesador de MIMO de TX 220 y el procesador de datos de TX 214 en el sistema transmisor 210.

Un procesador 270 determina periódicamente qué matriz de precodificación va a usar (analizado más adelante). El procesador 270 formula un mensaje de enlace inverso que comprende una parte de índice de matriz y una parte de valor de rango.

El mensaje de enlace inverso puede comprender diversos tipos de información con respecto al enlace de comunicación y/o al flujo de datos recibido. A continuación, el mensaje de enlace inverso se procesa por un procesador de datos de TX 238, que también recibe datos de tráfico para un número de flujos de datos desde una fuente de datos 236, se modula por un modulador 280, se acondiciona por los transmisores 254a a 254r y se transmite de vuelta al sistema transmisor 210.

En el sistema transmisor 210, las señales moduladas del sistema receptor 250 se reciben mediante antenas 224, se acondicionan mediante receptores 222, se demodulan mediante un demodulador 240 y se procesan mediante un procesador de datos de RX 242 para extraer el mensaje de enlace inverso transmitido por el sistema receptor 250. A continuación, el procesador 230 determina qué matriz de precodificación va a usar para determinar las ponderaciones de conformación de haz y después procesa el mensaje extraído.

Haciendo referencia a la figura 3, esta figura muestra un diagrama de bloques funcional simplificado alternativo de un dispositivo de comunicación de acuerdo con un modo de realización de la invención. Como se muestra en la figura 3, el dispositivo de comunicación 300 en un sistema de comunicación inalámbrica se puede utilizar para realizar los UE (o AT) 116 y 122 de la figura 1 o la estación base (o AN) 100 de la figura 1, y el sistema de comunicación inalámbrica es preferentemente el sistema LTE o el sistema NR. El dispositivo de comunicación 300 puede incluir un dispositivo de entrada 302, un dispositivo de salida 304, un circuito de control 306, una unidad central de procesamiento (CPU) 308, una memoria 310, un código de programa 312 y un transceptor 314. El circuito de control 306 ejecuta el código de programa 312 en la memoria 310 a través de la CPU 308, controlando así una operación del dispositivo de comunicaciones 300. El dispositivo de comunicaciones 300 puede recibir señales introducidas por un usuario a través del dispositivo de entrada 302, tal como un teclado o un teclado numérico, y puede emitir imágenes y sonidos a través del dispositivo de salida 304, tal como un monitor o altavoces. El transceptor 314 se usa para recibir y transmitir señales inalámbricas, suministrando las señales recibidas al circuito de control 306 y emitiendo las señales generadas por el circuito de control 306 de forma inalámbrica. El dispositivo de comunicación 300 en un sistema de comunicación inalámbrica también se puede utilizar para realizar el A n 100 de la figura 1.

La figura 4 es un diagrama de bloques simplificado del código de programa 312 que se muestra en la figura 3 de acuerdo con un modo de realización de la invención. En este modo de realización, el código de programa 312 incluye una capa de aplicación 400, una porción de capa 3402 y una porción de capa 2404, y está vinculado a una porción de capa 1406. La porción de capa 3402 realiza, en general, el control de recursos radioeléctricos. La porción de capa 2 404 realiza, en general, el control de enlace. La porción de capa 1406 realiza, en general, conexiones físicas TS 36.300 V15.3.0s.

La transmisión temprana de datos (EDT) y la señal de activación (WUS) se introducen en la versión 15 de LTE. Algunos textos relacionados con EDT y WUS se citan a continuación en las especificaciones 3GPP TS 36.300 V15.3.0 y 3GPP TS 36.331 V15.3.0. La especificación 3GPP TS 36.300 V15.3.0 divulga lo siguiente:

7.3b EDT

7.3b.1 General

La EDT permite una transmisión de datos de enlace ascendente seguida opcionalmente de una transmisión de datos de enlace descendente durante el procedimiento de acceso aleatorio.

La EDT se activa cuando las capas superiores han solicitado el establecimiento o la reanudación de una conexión RRC para datos de origen móvil (es decir, sin señalización o SMS) y el tamaño de los datos de enlace ascendente es menor que o igual al tamaño de TB indicado en la información del sistema. La EDT no se usa para datos sobre el plano de control cuando se usan las optimizaciones de EPS CIoT en el plano de usuario.

La EDT solo se aplica a los UE BL, a los UE con cobertura mejorada y a los UE NB-IoT.

7.3b.2 EDT para optimizaciones de EPS CloT en el plano de control

La EDT para optimizaciones de EPS CIoT en el plano de control, como se define en la especificación TS 24.301 [20], se caracteriza por lo siguiente:

- los datos de usuario de enlace ascendente se transmiten en un mensaje NAS concatenado en el mensaje RRCEarlyDataRequest de UL en CCCH;

- los datos de usuario de enlace descendente se transmiten opcionalmente en un mensaje NAS concatenado en un mensaje RRCEarlyDataComplete de DL en CCCH;

- no hay transición a RRC_CONNECTED.

El procedimiento EDT para las optimizaciones de EPS CloT en el plano de control se ilustra en la figura 7.3b-1. Figura 5 (reproducción de la figura 7.3b-1: EDT para optimizaciones de EPS CIoT en el plano de control) 0. Tras la solicitud de establecimiento de conexión para datos de origen móvil desde las capas superiores, el UE inicia el procedimiento de transmisión temprana de datos y selecciona un preámbulo de acceso aleatorio configurado para EDT.

1. El UE envía un mensaje RRCEarlyDataRequest concatenando los datos de usuario en CCCH.

2. El eNB inicia el procedimiento de mensajes de UE inicial S1-AP para reenviar el mensaje NAS y establecer la conexión S1. El eNB puede indicar en este procedimiento que esta conexión se activa para EDT.

3. La MME solicita a la S-GW que reactive las portadoras de EPS para el UE.

4. La MME envía los datos de enlace ascendente a la S-GW.

5. Si los datos de enlace descendente están disponibles, la S-GW envía los datos de enlace descendente a la MME.

6. Si se reciben datos de enlace descendente desde la S-GW, la MME reenvía los datos al eNB por medio del procedimiento de transporte NAS de DL y también puede indicar si se esperan más datos. De lo contrario, la MME puede activar el procedimiento de indicación de establecimiento de conexión y también indicar si se esperan más datos.

7. Si no se esperan más datos, el eNB puede enviar el mensaje RRCEarlyDataComplete en CCCH para mantener el UE en RRC_IDLE. Si se recibieron datos de enlace descendente en la etapa 6, se concatenan en el mensaje RRCEarlyDataComplete.

8. Se libera la conexión S1 y se desactivan las portadoras EPS.

NOTA: Si la MME o el eNB deciden hacer pasar el UE al modo RRC_CONNECTED, se envía el mensaje RRCConnectionSetup en la etapa 7 para volver al procedimiento de establecimiento de conexión RRC heredado; el eNB descartará la PDU NAS de longitud cero recibida en msg5.

7.3b.3 EDT para optimizaciones de EPS CIoT en el plano de usuario

La EDT para optimizaciones de EPS CIoT en el plano de usuario, como se define en la especificación TS 24.301 [20], se caracteriza por lo siguiente:

- se ha proporcionado al UE un NextHopChainingCount en el mensaje RRCConnectionRelease con indicación de suspensión;

- los datos de usuario de enlace ascendente se transmiten en DTCH multiplexados con el mensaje UL RRCConnectionResumeRequest en CCCH;

- los datos de usuario de enlace descendente se transmiten opcionalmente en DTCH multiplexados con el mensaje RRCConnectionRelease de DL en DCCH;

- la breve reanudación de MAC-I se reutiliza como el testigo de autenticación para el mensaje RRCConnectionResumeRequest y se calcula usando la clave de integridad de la conexión anterior;

- los datos de usuario en el enlace ascendente y el enlace descendente están cifrados. las claves se obtienen usando el NextHopChainingCount proporcionado en el mensaje RRCConnectionRelease de la conexión RRC anterior;

- el mensaje RRCConnectionRelease está cifrado y protegido en cuanto a su integridad usando las claves recién obtenidas;

- no hay transición a RRC_CONNECTED.

El procedimiento EDT para las optimizaciones de EPS CIoT en el plano de usuario se ilustra en la figura 7.3b-2. Figura 6 (reproducción de la figura 7.3b-2: EDT para optimizaciones de EPS CIoT en el plano de usuario) 0. Tras la solicitud de reanudación de conexión para datos de origen móvil desde las capas superiores, el UE inicia el procedimiento de transmisión temprana de datos y selecciona un preámbulo de acceso aleatorio configurado para EDT.

1. El UE envía una RRCConnectionResumeRequest al eNB, que incluye su ID de reanudación, la causa del establecimiento y un testigo de autenticación. El UE reanuda todos los SRB y DRB, obtiene nuevas claves de seguridad usando el NextHopChainingCount proporcionado en el mensaje RRCConnectionRelease de la conexión anterior y restablece la seguridad de AS. Los datos de usuario se cifran y transmiten en DTCH multiplexados con el mensaje RRCConnectionResumeRequest en CCCH.

2. El eNB inicia el procedimiento de reanudación de contexto S1-AP para reanudar la conexión S1 y reactivar las portadoras S1-U.

3. La MME solicita a la S-GW que reactive las portadoras S1-U para el UE.

4. La MME confirma al eNB la reanudación del contexto de UE.

5. Los datos del enlace ascendente se envían a la S-GW.

6. Si los datos de enlace descendente están disponibles, la S-GW envía los datos de enlace descendente al eNB.

7. Si no se esperan más datos de la S-GW, el eNB puede iniciar la suspensión de la conexión S1 y la desactivación de las portadoras S1-U.

8. El eNB envía el mensaje RRCConnectionRelease para mantener el UE en RRC_IDLE. El mensaje incluye releaseCause establecido como rrc-Suspend, resumeID, NextHopChainingCount y drb-ContinueROHC, que son almacenados por el UE. Si se recibieron datos de enlace descendente en la etapa 6, se envían cifrados en DTCH multiplexados con el mensaje RRCConnectionRelease en DCCH.

NOTA: Si la MME o el eNB decide que el UE pase al modo RRC_CONNECTED, se envía el mensaje RRCConnectionResume en la etapa 7 para volver al procedimiento de reanudación de conexión RRC. En ese caso, el mensaje RRCConnectionResume está cifrado y protegido en cuanto a su integridad con las claves obtenidas en la etapa 1, y el UE ignora el NextHopChainingCount incluido en el mensaje RRCConnectionResume. Los datos de enlace descendente se pueden transmitir en DTCH multiplexados con el mensaje RRCConnectionResume.

10.1 Intra-E-UTRAN

10.1.4 Radiolocalización y establecimiento en el plano C

Grupos de radiolocalización (donde se pueden direccionar múltiples UE) se utilizan en PDCCH:

- una identidad precisa de UE se encuentra en PCH;

- DRX configurable por medio de BCCH y NAS, para DRX NB-IoT configurable solo por medio de BCCH;

- solo una subtrama asignada por intervalo de radiolocalización por UE;

- la red puede dividir los UE en diferentes ocasiones de radiolocalización en el tiempo;

- no hay agrupación dentro de una ocasión de radiolocalización;

- un RNTI de radiolocalización para PCH.

Cuando se usa DRX extendida (eDRX) en modo inactivo, se aplica lo siguiente:

- el ciclo DRX se extiende hasta y más allá de 10,24 s en modo inactivo, con un valor máximo de 2621,44 s (43,69 minutos); Para NB-IoT, el valor máximo del ciclo DRX es de 10485,76 s (2,91 horas);

- el hiper-SFN (H-SFN) es difundido por la célula y se incrementa en uno cuando el SFN se reajusta;

- una hipertrama de radiolocalización (PH) se refiere al H-SFN en el que el UE comienza a supervisar la DRX de radiolocalización durante una ventana de tiempo de radiolocalización (PTW) usada en ECM-IDLE. La PH se determina en base a una fórmula que es conocida por la MME, el UE y el eNB en función del ciclo de eDRX y la identidad de UE;

- durante la PTW, el UE supervisa la radiolocalización durante la duración de la PTW (según lo configurado por NAS) o hasta que un mensaje de radiolocalización incluya la identidad NAS del UE recibida para el UE, lo que ocurra primero. Los posibles desfases iniciales para la PTW se distribuyen uniformemente dentro de la PH y se definen en la especificación TS 36.304 [11];

- la MME usa las fórmulas definidas en la especificación TS 36.304[11] para determinar la PH así como el comienzo de la PTW y envía la solicitud de radiolocalización S1 justo antes de que se produzca el inicio de la PTW o durante la PTW para evitar almacenar mensajes de radiolocalización en el eNB;

- es posible que los requisitos de ETWS, CMAS, PWS no se cumplan cuando un UE está en eDRX. Para EAB, si el UE admite SIB14, cuando está en DRX extendida, adquiere SIB14 antes de establecer la conexión RRC; - cuando el ciclo de eDRX es más largo que el período de modificación de la información del sistema, el UE verifica que la información almacenada del sistema sigue siendo válida antes de establecer una conexión RRC. El mensaje de radiolocalización se puede utilizar para la notificación de cambios en la información del sistema, cuando incluye systemlnfoModification-eDRX, para un UE configurado con un ciclo de eDRX más largo que el período de modificación de la información del sistema.

Los UE NB-IoT, los UE BL o los UE con cobertura mejorada pueden usar WUS, cuando están configurados en la célula, para reducir el consumo de energía relacionado con la supervisión de la radiolocalización.

Cuando se utiliza WUS en modo inactivo, se aplica lo siguiente:

- la WUS se usa para indicar que el UE supervisará el MPDCCH o el NPDCCH para recibir la radiolocalización en esa célula;

- para un UE no configurado con DRX extendida, la WUS está asociada a una ocasión de radiolocalización (N = 1);

- para un UE configurado con DRX extendida, la WUS puede asociarse a una o múltiples ocasiones de radiolocalización (N > 1) en una PTW;

- si el UE detecta la WUS, el UE supervisará las siguientes N ocasiones de radiolocalización a menos que haya recibido un mensaje de radiolocalización;

- la operación de radiolocalización en la MME no tiene constancia del uso de la WUS en el eNB.

La temporización entre la WUS y la ocasión de radiolocalización (PO) se ilustra en la figura 10.1.4-1. El UE puede esperar repeticiones de WUS durante la "duración máxima de WUS configurada", pero la transmisión de WUS real puede ser más corta, por ejemplo, para un UE con buena cobertura. El UE no supervisa la WUS durante una "separación" distinta de cero.

Figura 7 (reproducción de la figura 10.1.4-1: Ilustración de temporización de WUS)

Para NB-IoT, un UE en RRC_IDLE recibe radiolocalización en la portadora de anclaje o en una portadora de no anclaje en base a la información del sistema.

10.1.5 Procedimiento de acceso aleatorio

El procedimiento de acceso aleatorio se caracteriza por:

- Procedimiento común para FDD y TDD;

- un procedimiento configurado independientemente del tamaño de célula y del número de células de servicio durante CA;

el procedimiento de acceso aleatorio se realiza para los siguientes eventos relacionados con la PCell:

- acceso inicial a partir de RRC_IDLE;

- procedimiento de restablecimiento de la conexión RRC, según se define en la especificación TS 24.301 [20]; -traspaso, excepto para NB-IoT o cuando se configura HO sin RACH;

- llegada de datos de DL durante RRC_CONNECTED que requiere un procedimiento de acceso aleatorio:

- por ejemplo, cuando el estado de sincronización de UL es "no sincronizado".

- llegada de datos de UL durante RRC_CONNECTED que requiere un procedimiento de acceso aleatorio:

- por ejemplo, cuando el estado de sincronización de UL es "no sincronizado" o no hay recursos de PUCCH para SR disponibles.

- Para fines de posicionamiento durante RRC_CONNECTED que requiere un procedimiento de acceso aleatorio: - por ejemplo, cuando se necesita un avance de temporización para el posicionamiento del UE.

El procedimiento de acceso aleatorio también se realiza en una SCell para establecer la alineación de tiempo para el sTAG correspondiente.

Para E-UTRA conectado a 5GC, el procedimiento de acceso aleatorio también se realiza para la transición desde RRC_INACTIVE.

En DC, el procedimiento de acceso aleatorio también se realiza en al menos una PSCell tras la adición/modificación de SCG, si así se indica, o tras la llegada de datos de DL/UL durante RRC_CONNECTED que requiere el procedimiento de acceso aleatorio. El procedimiento de acceso aleatorio iniciado por UE se realiza solo en las PSCell para SCG.

Además, el procedimiento de acceso aleatorio adopta dos formas distintas:

- basado en contienda (aplicable a los seis eventos, pero el sexto evento para el posicionamiento solo puede aplicarse a NB-IoT);

- no basado en contienda (aplicable solo a traspaso, llegada de datos de DL, posicionamiento y obtención de alineación de avance de temporización para un sTAG).

La transmisión de DL/UL normal puede tener lugar después del procedimiento de acceso aleatorio.

Un RN admite tanto el acceso aleatorio basado en contienda como el no basado en contienda. Cuando un RN realiza el procedimiento de acceso aleatorio, suspende cualquier configuración de subtrama de RN actual, lo que significa que ignora temporalmente la configuración de la subtrama de RN. La configuración de subtrama de RN se reanuda cuando se completa con éxito el procedimiento de acceso aleatorio.

Para NB-IoT, el procedimiento de acceso aleatorio se realiza en la portadora de anclaje o en una portadora de no anclaje en base a la información del sistema.

10.1.5.1 Procedimiento de acceso aleatorio basado en contienda

El procedimiento de acceso aleatorio basado en contienda se esboza en la figura 10.1.5.1-1 descrita a continuación:

Figura 8 (reproducción de la figura 10.1.5.1-1: Procedimiento de acceso aleatorio basado en contienda) Las cuatro etapas de los procedimientos de acceso aleatorio basados en contienda son:

1) Preámbulo de acceso aleatorio en RACH en enlace ascendente:

- Hay dos grupos posibles definidos y uno es opcional. Si ambos grupos están configurados, el tamaño del mensaje 3 y la pérdida de trayecto se usan para determinar de qué grupo se selecciona un preámbulo. El grupo al que pertenece un preámbulo proporciona una indicación del tamaño del mensaje 3 y de las condiciones de radio en el UE. La información del grupo de preámbulos junto con los umbrales necesarios se difunden en la información del sistema.

2) Respuesta de acceso aleatorio generada por MAC en DL-SCH:

- semisíncrona (dentro de una ventana flexible cuyo tamaño es uno o más TTI) con el mensaje 1;

- no HARQ;

- dirigida a RA-RNTI en PDCCH;

- transmite al menos un identificador de preámbulo de RA, información de alineación de temporización para el pTAG, concesión de UL inicial y asignación de C-RNTI temporal (que puede, o no, hacerse permanente tras la resolución de contienda);

- destinada a un número variable de UE en un mensaje DL-SCH.

3) Primera transmisión de UL planificada en UL-SCH:

- usa HARQ;

- el tamaño de los bloques de transporte depende de la concesión de UL transmitida en la etapa 2.

- Para un acceso inicial:

- transmite la solicitud de conexión RRC generada por la capa RRC y transmitida por medio de CCCH;

-transmite al menos un identificador de UE NAS pero ningún mensaje NAS;

- TM RLC: sin segmentación.

- Para el procedimiento de restablecimiento de la conexión RRC:

- transmite la solicitud de restablecimiento de conexión RRC generada por la capa RRC y transmitida por medio de CCCH;

- TM RLC: sin segmentación;

- no contiene ningún mensaje NAS.

- Después del traspaso, en la célula de destino:

- Transmite la confirmación de traspaso de RRC cifrada y protegida en su integridad generada por la capa RRC y transmitida por medio de DCCH;

- transmite el C-RNTI del UE (que se asignó por medio del comando de traspaso);

- incluye una notificación de estado de búfer de enlace ascendente cuando es posible.

- Para otros eventos:

-transmite al menos el C-RNTI del UE;

- En el procedimiento para reanudar la conexión RRC:

- transmite la solicitud de reanudación de conexión RRC generada por la capa RRC y transmitida por medio de CCCH;

-transmite un ID de reanudación para reanudar la conexión RRC;

- Para NB-IoT:

- En el procedimiento para configurar la conexión RRC:

- se puede indicar una indicación de la cantidad de datos para transmisiones posteriores en SRB o DRB.

- Para EDT para optimizaciones de EPS CloT en el plano de control:

- transmite la solicitud de datos temprana de RRC generada por la capa RRC y transmitida por medio de CCCH; -transmite el identificador de UE NAS y datos de usuario concatenados en un mensaje NAS.

- Para EDT para optimizaciones de EPS CloT en el plano de usuario:

- transmite la solicitud de reanudación de RRC generada por la capa RRC y transmitida por medio de CCCH; -transmite un ID de reanudación para reanudar la conexión RRC.

- transmite datos de usuario cifrados transmitidos por medio de DTCH.

4) Resolución de contienda en DL:

- se utilizará la resolución temprana de contienda, es decir, el eNB no espera la respuesta de NAS antes de resolver la contienda;

- para NB-IoT, en el acceso inicial, el procedimiento de reanudación de conexión RRC y el procedimiento de restablecimiento de conexión RRC, el eNB puede transmitir una PDU MAC que contiene el elemento de control MAC de identidad de resolución de contienda de UE sin mensaje de respuesta RRC; NOTA: En la versión 13, los UE NB-IoT no admiten la PDU MAC que contiene el elemento de control MAC de identidad de resolución de contienda de UE sin mensaje de respuesta de RRC para acceso inicial, el procedimiento de reanudación de conexión RRC y el procedimiento de restablecimiento de conexión RRC.

- no sincronizada con el mensaje 3;

- se admite HARQ;

- Direccionada hacia:

- el C-RNTI temporal en el PDCCH para el acceso inicial y después del fallo del enlace radioeléctrico;

- el C-RNTI en PDCCH para UE en RRC_CONNECTED.

- La retroalimentación de HARQ es transmitida solo por el UE que detecta su propia identidad de UE, como se proporciona en el mensaje 3, reflejada en el mensaje de resolución de contienda;

- para el acceso inicial, el procedimiento de restablecimiento de conexión RRC y la EDT para las optimizaciones de EPS CloT en el plano de control, no se usa segmentación (RLC-TM).

El C-RNTI temporal pasa a ser C-RNTI para un UE que detecta el éxito de RA y aún no tiene un C-RNTI; es descartado por otros. Un UE que detecta el éxito de RA y ya tiene un C-RNTI, reanuda el uso de su C-RNTI. Cuando se configura CA, las tres primeras etapas de los procedimientos de acceso aleatorio basados en contienda se producen en la PCell, mientras que la PCell puede planificar de manera cruzada la resolución de contienda (etapa 4).

Cuando se configura DC, las tres primeras etapas de los procedimientos de acceso aleatorio basados en contienda se producen en la PCell en MCG y en la PSCell en s Cg . Cuando CA se configura en SCG, las tres primeras etapas de los procedimientos de acceso aleatorio basados en contienda se producen en la PSCell, mientras que la PSCell puede planificar de manera cruzada la resolución de contienda (etapa 4).

La especificación 3GPP TS 36.331 V15.3.0 divulga lo siguiente:

5.3 Control de conexión

5.3.3 Establecimiento de conexión RRC

5.3.3.1 General

Figura 9 (reproducción de la figura 5.3.3.1-1: Establecimiento de conexión RRC, con éxito)

Figura 10 (reproducción de la figura 5.3.3.1-2: Establecimiento de conexión RRC, rechazo de red)

Figura 11 (reproducción de la figura 5.3.3.1-3: Reanudación de conexión RRC (conexión RRC suspendida o RRC_INACTIVE), o retroceso de UP-EDT para reanudar conexión RRC, con éxito)

Figura 12 (reproducción de la figura 5.3.3.1-4: Reanudación de conexión RRC (conexión RRC suspendida o RRC_INACTIVE), o retroceso de UP-EDT para establecer conexión RRC, con éxito)

Figura 13 (reproducción de la figura 5.3.3.1-5: Reanudación de conexión RRC o UP-EDT, rechazo de red (conexión RRC suspendida o RRC_INACTIVE) o liberación (conexión RRC suspendida))

Figura 14 (reproducción de la figura 5.3.3.1-6: Reanudación de conexión RRC (RRC_INACTIVE), liberación o suspensión de red o UP-EDT, con éxito)

Figura 15 (reproducción de la figura 5.3.3.1-7: CP-EDT, con éxito)

Figura 16 (reproducción de la figura 5.3.3.1-8: Retroceso de CP-EDT al establecimiento de conexión RRC, con éxito)

Figura 17 (reproducción de la figura 5.3.3.1-9: CP-EDT, rechazo de red)

El propósito de este procedimiento es establecer una conexión RRC, reanudar una conexión RRC suspendida, hacer pasar el UE de RRC_INACTIVE a RRC_CONNECTED o realizar una EDT. El establecimiento de la conexión RRC implica el establecimiento de SRP1 (y SRP1bis para NB-IoT). El procedimiento también se usa para transferir la información/mensaje dedicados de NAS inicial desde el UE a la E-UTRAN.

E-UTRAN aplica el procedimiento como sigue:

- al establecer una conexión RRC:

- establecer SRB1 y, para NB-IoT, SRBlbis;

- al reanudar una conexión RRC desde una conexión RRC suspendida o desde RRC_INACTIVE:

- restaurar la configuración de AS a partir de un contexto almacenado, incluida la reanudación de SRB y DRB; - al realizar EDT.

5.3.3.1b Condiciones para iniciar una EDT

Un UE BL, un UE en CE o un UE NB-IoT puede iniciar una EDT cuando se cumplen todas las condiciones siguientes:

1> para CP-EDT, las capas superiores solicitan el establecimiento de una conexión RRC, el UE admite CP-EDT y SystemInformationBlockType2 (SystemInformationBlockType2-NB en NB-IoT) incluye cp-EDT, o

1> para UP-EDT, las capas superiores solicitan la reanudación de una conexión RRC, el UE admite UP-EDT, SystemInformationBlockType2 (SystemInformationBlockType2-NB en NB-IoT) incluye up-EDT, y el UE tiene un valor almacenado del nextHopChainingCount proporcionado en el mensaje RRCConnectionRelease con indicación de suspensión durante el procedimiento de suspensión anterior;

1> la solicitud de establecimiento o reanudación es para llamadas de origen móvil y la causa del establecimiento es mo-Data o mo-ExceptionData o delayTolerantAccess;

1> SystemInformationBlockType2 (SystemInformationBlockType2-NB en NB-IoT) incluye edt-Parameters;

1> se espera que el tamaño de la PDU MAC resultante, incluidos los datos de UL totales, sea menor que o igual al TBS señalizado en edt-TBS como se indica en la especificación TS 36.321 [6, 5.1.1];

1> No se ha recibido indicación de retroceso de EDT desde las capas inferiores para este procedimiento de establecimiento o reanudación;

NOTA 1: Las capas superiores solicitan o reanudan una conexión RRC. La interacción con NAS depende de la implementación del UE. NOTA 2: Depende de la implementación del UE la forma en que el UE determina si el tamaño de los datos de UL es adecuado para EDT.

5.3.3.2 Inicio

El UE inicia el procedimiento cuando las capas superiores solicitan el establecimiento o la reanudación de una conexión RRC mientras el UE está en RRC_IDLE o cuando las capas superiores solicitan la reanudación de una conexión RRC o la capa RRC solicita la reanudación de una conexión RRC para, por ejemplo, RNAU o recepción de radiolocalización de RAN mientras el UE está en RRC_INACTIVE.

A excepción de NB-IoT, al inicio del procedimiento, si el UE está conectado a EPC, el UE deberá:

1> si SystemInformationBlockType2 incluye ac-BarringPerPLMN-List y ac-BarringPerPLMN-List contiene una entrada AC-BarringPerPLMN con el plmn-Identitylndex correspondiente a la PLMN seleccionada por las capas superiores (véase la especificación t S 23.122 [11], TS 24.301 [35]):

2> seleccionar la entrada AC-BarringPerPLMN con el plmn-Identitylndex correspondiente a la PLMN seleccionada por las capas superiores;

2> en el resto de este procedimiento, usar la entrada AC-BarringPerPLMN seleccionada (es decir, presencia o ausencia de parámetros de prohibición de acceso en esta entrada) independientemente de los parámetros de prohibición de acceso comunes incluidos en SystemInformationBlockType2;

1> si no

2> en el resto de este procedimiento, usar los parámetros de prohibición de acceso comunes (es decir, presencia o ausencia de estos parámetros) incluidos en SystemInformationBlockType2;

1> si SystemInformationBlockType2 contiene ac-BarringPerPLMN-List y ac-BarringPerPLMN-List contiene una entrada ACDC-BarringPerPLMN con el plmn-IdentityIndex correspondiente a la PLMN seleccionada por las capas superiores (véase la especificación TS 23.122 [11], TS 24.301 [35]):

2> seleccionar la entrada ACDC-BarringPerPLMN con el plmn-IdentityIndex correspondiente a la PLMN seleccionada por las capas superiores;

2> en el resto de este procedimiento, usar la entrada ACDC-BarringPerPLAIN seleccionada para la comprobación de prohibición de ACDC (es decir, presencia o ausencia de parámetros de prohibición de acceso en esta entrada) independientemente de los parámetros acdc-BarringForCommon incluidos en SystemInformationBlockType2;

1> si no:

2> en el resto de este procedimiento, usar el acdc-BarringForCommon (es decir, la presencia o ausencia de estos parámetros) incluido en SystemInformationBlockType2 para la comprobación de prohibición de ACDC;

1> si las capas superiores indican que la conexión RRC está sujeta a EAB (véase la especificación TS 24.301 [35]):

2> si el resultado de la comprobación EAB, como se especifica en 5.3.3.12, es que el acceso a la célula está prohibido:

3> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que EAB es aplicable, tras lo cual finaliza el procedimiento;

1> si las capas superiores indican que la conexión RRC está sujeta a ACDC (véase la especificación TS 24.301 [35]), SystemInformationBlockType2 contiene BarringPerACDC-CategoryList y acdc-HPLMNonly indica que ACDC es aplicable para el UE:

2> si BarringPerACDC-CategoryList contiene una entrada BarringPerACDC-Category correspondiente a la categoría ACDC seleccionada por capas superiores:

3> seleccionar la entrada BarringPerACDC-Category correspondiente a la categoría ACDC seleccionada por capas superiores;

2> si no:

3> seleccionar la última entrada BarringPerACDC-Category en BarringPerACDC-CategoryList,

2> detener el temporizador T308, si se está ejecutando;

2> realizar la comprobación de prohibición de acceso como se especifica en 5.3.3.13, usando T308 como "Tbarring" y acdc-BarringConfig en la categoría BarringPerACDC- como "parámetro de prohibición de ACDC"; 2> si el acceso a la célula está prohibido:

3> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso es aplicable debido a ACDC, tras lo cual finaliza el procedimiento;

1> si no, si el UE está estableciendo la conexión RRC para llamadas de terminación móvil:

2> si el temporizador T302 se está ejecutando:

3> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para llamadas de terminación móvil es aplicable, tras lo cual finaliza el procedimiento;

1> si no, si el UE está estableciendo la conexión RRC para llamadas de emergencia:

2> si SystemInformationBlockType2 incluye ac-BarringInfo:

3> si ac-BarringForEmergency se establece como TRUE:

4> si el UE tiene una o más clases de acceso, como las almacenadas en el USIM, con un valor en el intervalo 11..15, que es válido para que el UE lo use de acuerdo con las especificaciones TS 22.011[10] y TS 23.122 [11]: NOTA 1: Las AC 12, 13, 14 solo son válidas para su uso en el país de origen y las AC 11, 15 solo son válidas para su uso en HPLMN/EHPLMN

5> si ac-BarringInfo incluye ac-BarringForMO-Data, y para todas estas clases de acceso para el UE, el bit correspondiente en ac-BarringForSpecialAC contenido en ac-BarringForMO-Data se establece en uno:

6> considerar el acceso a la célula como prohibido;

4> si no:

5> considerar el acceso a la célula como prohibido;

2> si el acceso a la célula está prohibido:

3> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión, tras lo cual finaliza el procedimiento;

1> si no, si el UE está estableciendo la conexión RRC para llamadas de origen móvil:

2> realizar la comprobación de prohibición de acceso como se especifica en 5,3/3/11, utilizando T303 como "Tbarring" y ac-BarringForMO-Data como "parámetro de prohibición de CA";

2> si el acceso a la célula está prohibido:

3> si SystemInformationBlockType2 incluye ac-BarringForCSFB o el UE no admite retroceso de CS:

4> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para llamadas de origen móvil es aplicable, tras lo cual finaliza el procedimiento;

3> si no (SystemInformationBlockType2 no incluye ac-BarringForCSFB y el UE admite retroceso de CS):

4> si el temporizador T306 no se está ejecutando, iniciar T306 con el valor de temporizador de T303;

4> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para llamadas de origen móvil y el retroceso de CS de origen móvil es aplicable, tras lo cual finaliza el procedimiento;

1> si no, si el UE está estableciendo la conexión RRC para señalización de origen móvil:

2> realizar la comprobación de prohibición de acceso como se especifica en 5,3/3/11, usando T305 como "Tbarring" y ac-BarringForMO-Signalling como "parámetro de prohibición de CA";

2> si el acceso a la célula está prohibido:

3> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para señalización de origen móvil es aplicable, tras lo cual finaliza el procedimiento;

1> si no, si el UE está estableciendo la conexión RRC para retroceso de CS de origen móvil:

2> si SystemInformationBlockType2 incluye ac-BarringForCSFB:

3> realizar la comprobación de prohibición de acceso como se especifica en 5,3/3/11, usando T306 como "Tbarring" y ac-BarringForCSFB como "parámetro de prohibición de CÁ';

3> si el acceso a la célula está prohibido:

4> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para el retroceso de CS de origen móvil es aplicable, debido a ac-BarringForCSFB, tras lo cual finaliza el procedimiento;

2> si no:

3> realizar la comprobación de prohibición de acceso como se especifica en 5,3/3/11, utilizando T306 como "Tbarring" y ac-BarringForMO-Data como "parámetro de prohibición de CA";

3> si el acceso a la célula está prohibido:

4> si el temporizador T303 no se está ejecutando, iniciar T303 con el valor de temporizador de T306;

4> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para retroceso de CS de origen móvil y llamadas de origen móvil es aplicable, debido a ac-BarringForMO-Data, tras lo cual finaliza el procedimiento;

1> si no, si el UE está estableciendo la conexión RRC para voz MMTEL de origen móvil, vídeo MMTEL de origen móvil, SMSolP de origen móvil o SMS de origen móvil:

2> si el UE está estableciendo la conexión RRC para voz MMTEL de origen móvil y SystemInformationBlockType2 incluye ac-BarringSkipForMMTELVoice; o

2> si el UE está estableciendo la conexión RRC para vídeo MMTEL de origen móvil y SystemInformationBlockType2 incluye ac-BarringSkipForMMTELVideo; o

2> si el UE está estableciendo la conexión RRC para SMSolP o SMS de origen móvil y SystemInformationBlockType2 incluye ac-BarringSkipForSMS: 3> considerar el acceso a la célula como no prohibido;

2> si no:

3> si establishmentCause recibido desde capas superiores se establece como mo-Signalling (incluido el caso en que mo-Signalling sea reemplazado por highPriorityAccess de acuerdo con la especificación 3GPP TS 24.301 [35] o por mo-VoiceCall de acuerdo con la subcláusula 5.3.3.3):

4> realizar la comprobación de prohibición de acceso como se especifica en 5,3/3/11, usando T305 como "Tbarring" y ac-BarringForMO-Signalling como "parámetro de prohibición de CA";

4> si el acceso a la célula está prohibido:

5> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para señalización de origen móvil es aplicable, tras lo cual finaliza el procedimiento;

3> si establishmentCause recibido desde capas superiores se establece como mo-Data (incluido el caso en que mo-Data sea reemplazado por highPriorityAccess de acuerdo con la especificación 3GPP TS 24.301 [35] o por mo-VoiceCall de acuerdo con la subcláusula 5.3.3.3):

4> realizar la comprobación de prohibición de acceso como se especifica en 5,3/3/11, utilizando T303 como "Tbarring" y ac-BarringForMO-Data como "parámetro de prohibición de CA";

4> si el acceso a la célula está prohibido:

5> si SystemInformationBlockType2 incluye ac-BarringForCSFB o el UE no admite retroceso de CS:

6> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para llamadas de origen móvil es aplicable, tras lo cual finaliza el procedimiento;

5> si no (SystemInformationBlockType2 no incluye ac-BarringForCSFB y el UE admite retroceso de CS):

6> si el temporizador T306 no se está ejecutando, iniciar T306 con el valor de temporizador de T303;

6> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso para llamadas de origen móvil y el retroceso de CS de origen móvil es aplicable, tras lo cual finaliza el procedimiento;

Una vez iniciado el procedimiento, si el UE está conectado a 5GC, el UE deberá:

1> si las capas superiores proporcionan una categoría de acceso y una o más identidades de acceso al solicitar el establecimiento de una conexión RRC:

2> realizar el procedimiento de control de acceso unificado como se especifica en 5.3.16 usando la categoría de acceso y las identidades de acceso proporcionadas por capas superiores;

3> si se prohíbe el intento de acceso, el procedimiento finaliza;

1> si las capas superiores proporcionan una categoría de acceso y una o más identidades de acceso al solicitar la reanudación de una conexión RRC:

2> realizar el procedimiento de control de acceso unificado como se especifica en 5.3.16 usando la categoría de acceso y las identidades de acceso proporcionadas por capas superiores;

3> si se prohíbe el intento de acceso, el procedimiento finaliza;

1> si la reanudación de la conexión RRC se activa debido a una RNAU:

2> si hay un servicio de emergencia en curso:

3> seleccionar '2' como categoría de acceso;

2> si no:

3> seleccionar [la categoría de acceso específica de RAN normalizada] como categoría de acceso;

Nota del editor: El valor a usar para la categoría de acceso específica de RAN normalizada debe ser confirmado por SA1.

2> realizar el procedimiento de control de acceso unificado como se especifica en 5.3.16 usando la categoría de acceso seleccionada y una o más identidades de acceso proporcionadas por capas superiores;

3> si el intento de acceso está prohibido:

4> establecer la variable pendingRnaUpdate como 'TRUE';

4> el procedimiento finaliza;

1> si la reanudación de la conexión RRC se activa como respuesta a la radiolocalización de NG-RAN:

2> seleccionar '0' como categoría de acceso;

2> realizar el procedimiento de control de acceso unificado como se especifica en 5.3.16 usando la categoría de acceso seleccionada y una o más identidades de acceso proporcionadas por capas superiores;

3> si se prohíbe el intento de acceso, el procedimiento finaliza;

A excepción de NB-IoT, al iniciar el procedimiento, si está conectado a EPC o 5GC, el UE deberá:

1> si el UE está reanudando una conexión RRC desde una conexión RRC suspendida o desde RRC_INACTIVE: 2> si el UE está reanudando una conexión RRC desde una conexión RRC suspendida:

3> si el UE se configuró con EN-DC:

4> realizar la liberación de EN-DC, como se indica en la especificación TS 38.331 [82, 5.3.5.10];

2> liberar la(s) SCell MCG, si están configuradas, de acuerdo con 5.3.10.3a;

2> liberar powerPrefIndicationConfig, si está configurado, y detener el temporizador T340, si se está ejecutando; 2> liberar reportProximityConfig y poner a cero cualquier temporizador de notificación de estado de proximidad asociado;

2> liberar getLocationConfig, si está configurado;

2> liberar idc-Config, si está configurado;

2> liberar sps-AssistanceInfoReport, si está configurado;

2> liberar MeasSubframePatternPCell, si está configurado;

2> liberar toda la configuración SCG, si está configurada, excepto la configuración DRB (según lo configurado por drb-ToAddModListSCG);

2> liberar naics-Info para PCell, si está configurado;

2> liberar la configuración LWA, si está configurada, como se describe en 5.6.14.3;

2> liberar la configuración LWIP, si está configurada, como se describe en 5.6.17.3;

2> liberar bw-PreferenceIndicationTimer, si está configurado, y detener el temporizador T341, si se está ejecutando;

2> liberar delayBudgetReportingConfig, si está configurado, y detener el temporizador T342, si se está ejecutando; 2> liberar ailc-BitConfig, si está configurado;

2> liberar upIinkDataCompression, si está configurado;

1> aplicar la configuración de canal físico predeterminada como se especifica en 9.2.4;

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

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

1> aplicar la configuración CCCH como se especifica en 9.1.1.2;

1> aplicar timeAlignmentTimerCommon incluido en SystemInformationBlockType2;

1> iniciar el temporizador T300;

1> si el UE está reanudando una conexión RRC desde una conexión RRC suspendida o desde RRC_INACTIVE: 2> detener T380 si el UE se está reanudando desde RRC_INACTIVE;

2> iniciar la transmisión del mensaje RRCConnectionResumeRequest de acuerdo con 5.3.3.3 a;

1> si no:

2> si está almacenado, descartar el contexto AS de UE, resumeldentity e I-RNTI;

2> si el UE está iniciando CP-EDT de acuerdo con las condiciones en 5.3.3.1b:

3> iniciar la transmisión del mensaje RRCEarlyDataRequest de acuerdo con 5.3.3.3b;

2> si no:

3> iniciar la transmisión del mensaje RRCConnectionRequest de acuerdo con 5.3.3.3;

NOTA 2: Al iniciar el procedimiento de establecimiento de conexión, no se requiere que el UE se asegure de mantener actualizada la información de sistema aplicable solo para los UE en el estado RRC_IDLE o los UE en RRC_INACTIVE. Sin embargo, el UE necesita realizar la adquisición de información del sistema tras la reselección de célula.

Para NB-IoT, al inicio del procedimiento, el UE deberá:

1> si el UE está estableciendo o reanudando la conexión RRC para datos de excepción de origen móvil; o 1> si el UE está estableciendo o reanudando la conexión RRC para datos de origen móvil; o

1> si el UE está estableciendo o reanudando la conexión RRC para acceso tolerante al retardo; o

1> si el UE está estableciendo o reanudando la conexión RRC para señalización de origen móvil;

2> realizar comprobación de prohibición de acceso como se especifica en 5.3.3.14;

2> si el acceso a la célula está prohibido:

3> informar a las capas superiores acerca del fallo en el establecimiento de la conexión RRC o del fallo en la reanudación de la conexión RRC con indicación de suspensión y que la prohibición de acceso es aplicable, tras lo cual finaliza el procedimiento;

1> aplicar la configuración de canal físico predeterminada como se especifica en 9.2.4;

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

1> aplicar la configuración CCCH como se especifica en 9.1.1.2;

1> iniciar el temporizador T300;

1> si el UE está estableciendo una conexión RRC:

2> si el UE está iniciando CP-EDT de acuerdo con las condiciones en 5.3.3.1b:

3> iniciar la transmisión del mensaje RRCEarlyDataRequest de acuerdo con 5.3.3.3b;

2> si no:

3> iniciar la transmisión del mensaje RRCConnectionRequest de acuerdo con 5.3.3.3;

1> si no, si el UE está reanudando una conexión RRC:

2> iniciar la transmisión del mensaje RRCConnectionResumeRequest de acuerdo con 5.3.3.3 a;

NOTA 3: Al iniciar el procedimiento de establecimiento o reanudación de conexión, no se requiere que el UE se asegure de mantener actualizada la información de sistema aplicable solo para los UE en el estado RRC_IDLE. Sin embargo, el UE necesita realizar la adquisición de información del sistema tras la reselección de célula. NOTA 4: Para EDT, al iniciar el procedimiento de establecimiento o reanudación de la conexión, depende de la implementación del UE si continuar con las mediciones relacionadas con la reselección de célula, así como con la evaluación de la reselección de célula y, si se cumplen las condiciones para la reselección de célula, si se debe realizar la reselección de célula como se especifica en 5.3.3.5.

5.3.3.3a Acciones relacionadas con la transmisión del mensaje RRCConnectionResumeRequest

Si el UE está reanudando la conexión RRC desde una conexión RRC suspendida, el UE establecerá el contenido del mensaje RRCConnectionResumeRequest como sigue:

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

1> si el UE está iniciando UP-EDT de acuerdo con las condiciones en 5.3.3.1b; o

1> si el campo useFulIResumeID está señalizado en SystemInformationBlockType2:

2> establecer resumeID como el valor de resumeldentity almacenado;

1> si no:

2> configurar truncatedResumeID para incluir bits en la posición de bit 9 a 20 y 29 a 40 desde la izquierda en el valor de resumeldentity almacenado.

1> si el UE admite la causa de establecimiento mo-VoiceCall y el UE está reanudando la conexión RRC para voz MMTEL de origen móvil y SystemInformationBlockType2 incluye voiceServiceCauseIndication y la causa de establecimiento recibida de las capas superiores no se establece en highPriorityAccess:

2> establecer resumeCause como mo-VoiceCall;

1> si no, si el UE admite la causa de establecimiento mo-VoiceCall para vídeo MMTEL de origen móvil y el UE está reanudando la conexión RRC para vídeo MMTEL de origen móvil y SystemInformationBlockType2 incluye videoServiceCauseIndication y la causa de establecimiento recibida desde las capas superiores no se establece como highPriorityAccess:

2> establecer resumeCause como mo-VoiceCall;

1> si no:

2> establecer resumeCause de acuerdo con la información recibida desde capas superiores;

> establecer shortResumeMAC-I con el valor de los 16 bits menos significativos del MAC-I calculado:

2> sobre ASN.1 codificado según la sección 8 (es decir, un múltiplo de 8 bits) VarShortResumeMAC-Input (o VarShortResumeMAC-Input-NB en NB-IoT);

2> con la clave KRRCint y el algoritmo de protección de integridad configurado previamente; y

2> con todos los bits de entrada para COUNT, BEARER y DIRECTION establecidos como unos binarios;

1> si el UE es un UE NB-IoT:

2> si el UE admite notificación de calidad de canal DL y cqi-Reporting está presente en SystemInformationBlockType2-NB:

3> configurar cqi-NPDCCH para que incluya los últimos resultados de las mediciones de calidad de canal de enlace descendente de la célula de servicio como se indica en la especificación TS 36.133 [16];

NOTA 0: Las mediciones de calidad de canal de enlace descendente pueden usar el período de medición T1 o T2, como se define en TS 36.133 [16]. En caso de que se use el período T2, las interacciones RRC-MAC se dejan a la implementación del UE.

2> establecer earlyContentionResolution como TRUE;

1> restaurar la configuración RRC y el contexto de seguridad desde el contexto AS de UE almacenado;

1> si el UE está iniciando UP-EDT de acuerdo con las condiciones en 5.3.3.1b:

2> restaurar el estado de PDCP y restablecer las entidades de PDCP para todos los SRB y todos los DRB; 2> si se ha proporcionado drb-ContinueROHC en el mensaje de liberación de conexión RRC inmediatamente anterior, y el UE solicita reanudar la conexión RRC en la misma célula:

3> indicar a las capas inferiores que se usa el contexto AS de UE almacenado y que drb-ContinueROHC está configurado;

3> continuar el contexto del protocolo de compresión de cabecera para los DRB configurados con el protocolo de compresión de cabecera;

2> si no:

3> indicar a las capas inferiores que se usa el contexto AS de UE almacenado;

3> restablecer el contexto de protocolo de compresión de cabecera para los DRB configurados con el protocolo de compresión de cabecera;

2> reanudar todos los SRB y todos los DRB;

2> obtener la clave KeNB en base a la clave K^asme a la que está asociada la KeNB actual, usando el valor almacenado de nextHopChainingCount, como se indica en la especificación TS 33.401 [32];

2> obtener la clave KRRCint asociada al algoritmo de integridad configurado previamente, como se indica en la especificación TS 33.401 [32];

2> obtener la clave KRRCenc y la clave KUPenc asociadas al algoritmo de cifrado configurado previamente, como se indica en la especificación TS 33.401 [32];

2> configurar capas inferiores para reanudar la protección de integridad usando el algoritmo configurado previamente y la clave KRRCint obtenida en esta subcláusula para todos los mensajes subsiguientes recibidos y enviados por el UE;

2> configurar capas inferiores para reanudar el cifrado y aplicar el algoritmo de cifrado y la clave KRRCenc obtenida en esta subcláusula a todos los mensajes subsiguientes recibidos y enviados por el UE;

2> configurar capas inferiores para reanudar el cifrado y aplicar el algoritmo de cifrado y la clave KUPenc obtenida en esta subcláusula inmediatamente a los datos de usuario enviados y recibidos por el UE;

2> configurar las capas inferiores para que usen EDT;

1> si no:

2> si SRB1 se configuró con PDCP NR:

3> para SRB1, liberar la entidad PDCP NR y establecer una entidad PDCP E-UTRA con la configuración de seguridad (MCG) actual;

NOTA 1: El UE aplica los algoritmos de protección de integridad y cifrado de LTE que son equivalentes a los algoritmos de seguridad NR configurados previamente.

2> si no:

3> para SRB1, restaurar el estado PDCP y restablecer la entidad PDCP;

Si el UE está reanudando la conexión RRC desde RRC_INACTIVE, el UE establecerá el contenido del mensaje RRCConnectionResumeRequest como sigue:

2> si el campo useFullResumeID está señalizado en SystemInformationBlockType2:

3> establecer fullI-RNTI al valor fulll-RNTI almacenado provisto en suspensión;

2> si no:

3> establecer shortI-RNTI al valor shortI-RNTI almacenado proporcionado en suspensión;

2> establecer resumeCause de acuerdo con la información recibida de las capas superiores o de la capa AS; NOTA 1a: si la reanudación es activada por capas superiores y la capa AS simultáneamente, configurar resumeCause de acuerdo con la información recibida de capas superiores.

2> establecer shortResumeMAC-I con el valor de los 16 bits menos significativos del MAC-I calculado:

3> sobre ASN.1 codificado según la sección 8 (es decir, un múltiplo de 8 bits) VarINACTIVE-MAC-Input;

3> con la clave KRRCint y el algoritmo de protección de integridad configurado previamente; y

3> con todos los bits de entrada para COUNT, BEARER y DIRECTION establecidos como unos binarios;

2> restaurar la configuración RRC y el contexto de seguridad desde el contexto AS de UE almacenado excepto la capa física y la configuración MAC;

2> actualizar la clave KeNB en base a la KeNB actual o el NH, usando el valor nextHopChainingCount almacenado, como se indica en la especificación TS 33.501 [86];

2> obtener la clave KRRCenc, la clave KRRCint y la clave KUPenc;

2> configurar capas inferiores para reanudar la protección de integridad para todos los SRB excepto SRB0 usando el algoritmo previamente configurado y la clave KRRCint inmediatamente, es decir, la protección de integridad se aplicará a todos los mensajes subsiguientes recibidos y enviados por el UE;

2> configurar capas inferiores para reanudar el cifrado para todas las portadoras de radio excepto SRB0 y aplicar el algoritmo de cifrado previamente configurado, la clave KRRCenc y la clave KUPenc, es decir, la configuración de cifrado se aplicará a todos los mensajes subsiguientes recibidos y enviados por el UE;

2> aplicar la configuración predeterminada para SRB1 como se especifica en 9.2.1.1;

2> aplicar la configuración PDCP NR predeterminada como se indica en la especificación TS 38.331 [82], cláusula 9.2.1.1 para SRB1;

Los siguientes procedimientos se aplican tanto para la conexión RRC suspendida como para RRC_INACTIVE: 2> reanudar s Rb 1;

NOTA 2: Hasta que la conexión se reanude con éxito, la configuración de capa física predeterminada y la configuración principal MAC predeterminada se aplican para la transmisión de SRB0 y SRB1, y SRB1 se usa solo para la transferencia del mensaje RRCConnectionResume.

El UE enviará el mensaje RRCConnectionResumeRequest a las capas inferiores para su transmisión.

El UE continuará con las mediciones relacionadas con la reselección de célula, así como con la evaluación de la reselección de célula. Si se cumplen las condiciones para la reselección de célula, el UE realizará la reselección de célula como se especifica en 5.3.3.5.

5.3.3.3b Acciones relacionadas con la transmisión del mensaje RRCEarlyDataRequest

El UE establecerá el contenido del mensaje RRCEarlyDataRequest como sigue:

1> establecer s-TMSI al valor recibido desde capas superiores;

1> establecer establishmentCause de acuerdo con la información recibida desde capas superiores;

1> si el UE es un UE NB-IoT:

2> si el UE admite notificación de calidad de canal DL y cqi-Reporting está presente en SystemInformationBlockType2-NB:

3> configurar cqi-NPDCCH para que incluya los últimos resultados de las mediciones de calidad de canal de enlace descendente de la célula de servicio como se indica en la especificación TS 36.133 [16];

NOTA: Las mediciones de calidad de canal de enlace descendente pueden usar el período de medición T1 o T2, como se define en TS 36.133 [16]. En caso de que se use el período T2, las interacciones RRC-MAC se dejan a la implementación del UE.

1> configurar dedicatedInfoNAS para incluir la información recibida desde capas superiores;

El UE configurará las capas inferiores para utilizar EDT y enviará el mensaje RRCEarlyDataRequest a las capas inferiores para su transmisión.

5.3.3.3c Acciones de UE al recibir una indicación de retroceso de EDT procedente de capas inferiores

Tras una indicación procedente de capas inferiores de que la EDT está cancelada, el UE deberá:

1> iniciar o reiniciar el temporizador T300;

1> si el retroceso está indicado por capas inferiores en respuesta a RRCEarlyDataRequest:

2> iniciar la transmisión del mensaje RRCConnectionRequest de acuerdo con 5.3.3.3;

1> si no, si el retroceso está indicado por capas inferiores en respuesta a RRCConnectionResumeRequest para EDT y el retroceso no se debe a que la concesión de UL proporcionada en la respuesta de acceso aleatorio no es para EDT:

2> realizar las acciones tras la cancelación de UP-EDT como se especifica en 5.3.3.9a;

2> iniciar la transmisión del mensaje RRCConnectionResumeRequest de acuerdo con 5.3.3.3 a;

5.3.3.4a Recepción de RRCConnectionResume por parte del UE

El UE deberá:

1> detener el temporizador T300;

1> excepto si el RRCConnectionResume se recibe en respuesta a un RRCConnectionResumeRequest para EDT: 2> si se reanuda una conexión RRC desde una conexión RRC suspendida:

3> restaurar el estado PDCP y restablecer las entidades PDCP para SRB2, si está configurado con PDCP E-UTRA, y para todos los DRB que están configurados con PDCP E-UTRA;

3> si se incluye drb-ContinueROHC:

4> indicar a las capas inferiores que se usa el contexto AS de UE almacenado y que drb-ContinueROHC está configurado;

4> continuar el contexto del protocolo de compresión de cabecera para los DRB configurados con el protocolo de compresión de cabecera;

3> si no:

4> indicar a las capas inferiores que se usa el contexto AS de UE almacenado;

4> restablecer el contexto de protocolo de compresión de cabecera para los DRB configurados con el protocolo de compresión de cabecera;

3> descartar el contexto AS de UE almacenado y resumeldentity;

2> si no, si el mensaje RRCConnectionResume incluye fullConfig (para reanudar una conexión RRC desde RRC_INACTIVE):

3> realizar el procedimiento de configuración de radio como se especifica en 5.3.5.8;

2> si no (para reanudar una conexión RRC desde RRC_INACTIVE)

3> restaurar el estado PDCP, restablecer el valor COUNT y restablecer las entidades PDCP para SRB2 y todos los DRB;

3> restaurar la configuración de capa física, la configuración MAC, la configuración RLC y la configuración PDCP desde el contexto AS de UE almacenado;

3> si se incluye drb-ContinueROHC:

4> indicar a las capas inferiores que se usa el contexto AS de UE almacenado y que drb-ContinueROHC está configurado;

4> continuar el contexto del protocolo de compresión de cabecera para los DRB configurados con el protocolo de compresión de cabecera;

3> si no:

4> indicar a las capas inferiores que se usa el contexto AS de UE almacenado;

4> restablecer el contexto de protocolo de compresión de cabecera para los DRB configurados con el protocolo de compresión de cabecera;

3> descartar el contexto AS de UE almacenado, el fullI-RNTI y el shortI-RNTI excepto ran-NotificationAreaInfo; 1> realizar el procedimiento de configuración de recursos radioeléctricos de acuerdo con el radioResourceConfigDedicated recibido y como se especifica en 5.3.10;

NOTA: Cuando se realiza el procedimiento de configuración de recursos radioeléctricos, para la configuración de capa física y la configuración principal de MAC, la configuración RRC restaurada a partir del contexto AS de UE almacenado se usa como base para la reconfiguración.

1> si el mensaje RRCConnectionResume recibido incluye el sk-Counter:

2> realizar el procedimiento de actualización de claves como se indica en la especificación TS 38.331 [82, 5.3.5.8]; 1> si el mensaje RRCConnectionResume recibido incluye nr-RadioBearerConfig1:

2> realizar la configuración de portadora de radio como se indica en la especificación TS 38.331 [82, 5.3.5.6]; 1> si el mensaje RRCConnectionResume recibido incluye nr-RadioBearerConfig2:

2> realizar la configuración de portadora de radio como se indica en la especificación TS 38.331 [82, 5.3.5.6]; 1> excepto si el RRCConnectionResume se recibe en respuesta a un RRCConnectionResumeRequest para EDT: 2> reanudar SRB2 y todos los DRB, si los hubiera, incluidos los RB configurados con PDCP NR;

1> si está almacenada, descartar la información de prioridad de reselección de célula proporcionada por idleModeMobilityControlInfo o heredada de otra RAT;

1> si está almacenado, descartar el desfase dedicado proporcionado por redirectedCarrierOffsetDedicated; 1> si el mensaje RRCConnectionResume incluye MeasConfig:

2> realizar el procedimiento de configuración de medición como se especifica en 5.5.2;

1> detener el temporizador T302, si se está ejecutando;

1> detener el temporizador T303, si se está ejecutando;

1> detener el temporizador T305, si se está ejecutando;

1> detener el temporizador T306, si se está ejecutando;

1> detener el temporizador T308, si se está ejecutando;

1> realizar las acciones especificadas en 5.3.3.7;

1> detener el temporizador T320, si se está ejecutando;

1> detener el temporizador T350, si se está ejecutando;

1> realizar las acciones especificadas en 5.6.12.4;

1> detener el temporizador T360, si se está ejecutando;

1> detener el temporizador T322, si se está ejecutando;

1> si el RRCConnectionResume se recibe en respuesta a un RRCConnectionResumeRequest para EDT:

2> ignorar el valornextHopChainingCount indicado en el mensaje RRCConnectionResume;

1> si no:

2> si se reanuda una conexión RRC desde una conexión RRC suspendida:

3> actualizar la clave KeNB en base a la clave Kasme a la que está asociada la KeNB actual, usando el valor nextHopChainingCount indicado en el mensaje RRCConnectionResume, como se indica en la especificación TS 33.401 [32];

3> almacenar el valor nextHopChainingCount;

3> obtener la clave KRRCint asociada al algoritmo de integridad configurado previamente, como se indica en la especificación TS 33.401 [32];

3> solicitar a capas inferiores que verifiquen la protección de integridad del mensaje RRCConnectionResume, usando el algoritmo configurado previamente y la clave KRRCint;

2> si falla la comprobación de protección de integridad del mensaje RRCConnectionResume:

3> realizar las acciones al salir de RRC_CONNECTED o RRC_INACTIVE como se especifica en 5.3.12, siendo 'otra' la causa de liberación para la reanudación desde una conexión RRC suspendida, siendo 'fallo de reanudación de RRC' la causa de liberación para la reanudación desde RRC_INACTIVE, tras lo cual el procedimiento termina; 2> si se reanuda una conexión RRC desde una conexión RRC suspendida:

3> obtener la clave KRRCenc y la clave KUPenc asociadas al algoritmo de cifrado configurado previamente, como se indica en la especificación TS 33.401 [32];

3> configurar capas inferiores para reanudar la protección de integridad usando el algoritmo previamente configurado y la clave KRRCint inmediatamente, es decir, la protección de integridad se aplicará a todos los mensajes subsiguientes recibidos y enviados por el UE;

3> configurar capas inferiores para reanudar el cifrado y aplicar el algoritmo de cifrado, la clave KRRCenc y la clave KUPenc, es decir, la configuración de cifrado se aplicará a todos los mensajes subsiguientes recibidos y enviados por el UE;

1> entrar en RRC_CONNECTED;

1> indicar a las capas superiores que se ha reanudado la conexión RRC suspendida;

1> detener el procedimiento de reselección de célula;

1> considerar que la célula actual es PCell;

1> establecer el contenido del mensaje RRCConnectionResumeComplete como sigue:

2> establecer selectedPLMN-Identity como la PLMN seleccionada por capas superiores (véase la especificación TS 23.122 [11], TS 24.301 [35]) de las PLMN incluidas en plmn-IdentityList en SystemInformationBlockType1; 2> configurar dedicatedInfoNAS para incluir la información recibida desde capas superiores;

3> si el UE dispone de información sobre la trayectoria de vuelo:

4> incluir flightPathInfoAvailable;

2> excepto para NB-IoT:

3> si se reanuda una conexión RRC desde una conexión RRC suspendida:

4> si el UE tiene información de fallo de enlace radioeléctrico o de fallo de traspaso disponible en VarRLF-Report y si la RPLMN está incluida en plmn-IdentityList almacenada en VarRLF-Report:

5> incluir rlf-InfoAvailable;

4> si el UE tiene mediciones registradas de MBSFN disponibles para E-UTRA y si la RPLMN está incluida en plmn-IdentityList almacenada en VarLogMeasReport:

5> incluir logMeasAvailableMBSFN;

4> si no, si el UE tiene mediciones registradas disponibles para E-UTRA y si la RPLMN está incluida en plmn-IdentityList almacenada en VarLogMeasReport:

5> incluir logMeasAvailable;

4> si el UE tiene mediciones registradas de Bluetooth disponibles y si la RPLMN está incluida en plmn-IdentityList almacenada en VarLogMeasReport:

5> incluir logMeasAvailableBT;

4> si el UE tiene mediciones registradas de WLAN disponibles y si la RPLMN está incluida en plmn-IdentityList almacenada en VarLogMeasReport:

5> incluir logMeasAvailableWLAN;

4> si el UE tiene información de fallo de establecimiento de conexión disponible en VarConnEstFailReport y si la RPLMN es igual a plmn-Identity almacenada en VarConnEstFailReport:

5> incluir connEstFailInfoAvailable;

4> incluir mobilityState y ponerlo en el estado de movilidad (como se indica en la especificación TS 36.304 [4]) del UE justo antes de entrar en el estado RRC_CONNECTED;

3> si el UE admite el almacenamiento de información de historial de movilidad y el UE tiene información de historial de movilidad disponible en VarMobilityHistoryReport:

4> incluir MobilityHistoryAvail;

3> si SIB2 contiene idleModeMeasurements, y el UE tiene información de medición de modo IDLE disponible en VarMeasIdleReport:

4> incluir idleMeasAvailable;

4> detener T331 (si se está ejecutando);

2> para NB-IoT:

3> si el UE admite notificación de mediciones de modo inactivo de célula de servicio y servingCellMeasInfo está presente en SystemInformationBlockType2-NB:

4> configurar MeasResultServCell para incluir las mediciones de la célula de servicio;

NOTA: El UE incluye los últimos resultados de las mediciones de célula de servicio usadas para la evaluación de selección/reselección de célula, que se realizan de acuerdo con los requisitos de rendimiento como se indica en la especificación TS 36.133 [16].

1> enviar el mensaje RRCConnectionResumeComplete a capas inferiores para su transmisión;

1> el procedimiento finaliza.

5.3.3.4b Recepción de RRCEarlyDataComplete por parte del UE

El UE deberá:

1> si está almacenada, descartar la información de prioridad de reselección de célula proporcionada por idleModeMobilityControlInfo o heredada de otra RAT;

1> si está almacenado, descartar el desfase dedicado proporcionado por redirectedCarrierOffsetDedicated; 1> detener el temporizador T300;

1> detener el temporizador T302, si se está ejecutando;

1> detener el temporizador T303, si se está ejecutando;

1> detener el temporizador T305, si se está ejecutando;

1> detener el temporizador T306, si se está ejecutando;

1> detener el temporizador T308, si se está ejecutando;

1> realizar las acciones especificadas en 5.3.3.7;

1> detener el temporizador T320, si se está ejecutando;

1> detener el temporizador T322, si se está ejecutando;

1> reenviar dedicatedInfoNAS, si se recibe, a las capas superiores;

1> restablecer MAC y liberar la configuración MAC;

1> si el mensaje RRCEarlyDataComplete incluye redirectedCarrierInfo indicando redireccionamiento a geran; y 1> si las capas superiores indican que la redirección a GERAN sin seguridad AS no está permitida:

2> realizar las acciones al salir de RRC_CONNECTED como se indica en 5.3.12, siendo 'otra' la causa de liberación, tras lo cual finaliza el procedimiento;

1> si el mensaje RRCEarlyDataComplete incluye idleModeMobilityControlInfo:

2> almacenar la información de prioridad de reselección de célula proporcionada por idleModeMobilityControlInfo; 2> si se incluye el t320:

3> iniciar el temporizador T320, donde el valor del temporizador está establecido de acuerdo con el valor de t320; 1> si no:

2> aplicar la información de prioridad de reselección de célula difundida en la información del sistema;

1> para NB-IoT, si el mensaje RRCEarlyDataComplete incluye redirectedCarrierInfo:

2> si el redirectedCarrierOffsetDedicated está incluido en el redirectedCarrierInfo:

3> almacenar el desfase dedicado para la frecuencia en redirectedCarrierInfo;

3> iniciar el temporizador T322, donde el valor del temporizador está establecido de acuerdo con el valor de T322 en redirectedCarrierInfo;

1> si extendedWaitTime está presente; y

1> si el UE admite el acceso tolerante al retardo o el UE es un UE NB-IoT:

2> reenviar extendedWaitTime a capas superiores;

1> indicar la liberación de la conexión RRC a capas superiores junto con la causa de liberación 'otra', tras lo cual finaliza el procedimiento;

5.3.3.8 Recepción de RRCConnectionReject por parte del UE

El UE deberá:

1> detener el temporizador T300;

1> restablecer MAC;

1> excepto para NB-IoT, iniciar el temporizador T302, con el valor del temporizador establecido a waitTime; 1> si el UE es un UE NB-IoT; o

1> si extendedWaitTime está presente y el UE admite el acceso tolerante al retardo:

2> reenviar extendedWaitTime a capas superiores;

1> si se incluye deprioritisationReq y el UE admite rechazo de conexión RRC con despriorización:

2> iniciar o reiniciar el temporizador T325 con el valor del temporizador establecido a deprioritisationTimer señalizado;

2> almacenar deprioritisationReq hasta la expiración de T325;

NOTA: El UE almacena la solicitud de despriorización independientemente de cualquier asignación de prioridad absoluta de reselección de célula (mediante señalización dedicada o común) e independientemente de las conexiones RRC en E-UTRAN u otras RAT a menos que se especifique lo contrario.

1> si se recibe RRCConnectionReject en respuesta a una RRCConnectionResumeRequest enviada para reanudar una conexión RRC suspendida:

2> si rrc-SuspendIndication no está presente:

3> liberar todos los recursos radioeléctricos, incluida la liberación de la entidad RLC, la configuración MAC y la entidad PDCP asociada para todos los RB establecidos o suspendidos;

3> descartar el contexto AS de UE almacenado y resumeldentity;

3> informar a las capas superiores sobre la imposibilidad de reanudar la conexión RRC sin indicación de suspensión y que la prohibición de acceso para llamadas de origen móvil, la señalización de origen móvil, el acceso de terminación móvil y, excepto para NB-IoT para retroceso de CS de origen móvil, es aplicable, tras lo cual el procedimiento termina;

2> si no:

3> si se recibe RRCConnectionReject en respuesta a una RRCConnectionResumeRequest para EDT:

4> realizar las acciones tras la cancelación de UP-EDT como se especifica en 5.3.3.9a;

3> si no:

4> suspender SRB1;

3> informar a las capas superiores sobre la imposibilidad de reanudar la conexión RRC con indicación de suspensión y que la prohibición de acceso para llamadas de origen móvil, la señalización de origen móvil, el acceso de terminación móvil y excepto para NB-IoT, para retroceso de CS de origen móvil, es aplicable, tras lo cual el procedimiento termina;

1> si no, si RRCConnectionReject se recibe en respuesta a una RRCConnectionResumeRequest enviada durante RRC_INACTIVE:

2> establecer la variable pendingRnaUpdate como 'FALSE';

2> si se recibe RRCConnectionReject en respuesta a una solicitud procedente de capas superiores:

3> informar a la capa superior que la prohibición de acceso es aplicable a todas las categorías de acceso excepto a las categorías '0' y '2';

2> si se recibe RRCConnectionReject en respuesta a una RRCConnectionResumeRequest:

3> si la reanudación es activada por capas superiores:

4> informar a las capas superiores acerca del fallo al reanudar la conexión RRC;

3> si la reanudación es activada por RRC:

4> establecer la variable pendingRnaUpdate como 'TRUE';

3> descartar el contexto de seguridad que incluye la clave KRRCenc, la clave KRRCint, la clave KüPint y la clave KüPenc; 3> suspender SRB1, tras lo cual finaliza el procedimiento;

Nota del editor: 'Manejo de FS del temporizador T380 en caso de rechazo, por ejemplo, detener, reiniciar, etc. 2> El UE seguirá supervisando la radiolocalización de RAN y CN mientras el temporizador T302 se está ejecutando.

1> si no:

2> liberar la configuración MAC;

2> informar a las capas superiores sobre la imposibilidad de establecer la conexión RRC y que la prohibición de acceso para llamadas de origen móvil, la señalización de origen móvil, el acceso de terminación móvil y excepto para NB-IoT, para retroceso de CS de origen móvil, es aplicable, tras lo cual el procedimiento termina;

5.3.3.9a Cancelación de UP-EDT

El UE deberá:

1> eliminar las claves KeNB, KRRCint, KRRCenc y KüPenc obtenidas de acuerdo con 5.3.3.3a;

1> restablecer las entidades RLC para todos los SRB y DRB;

1> suspender todos los SRB y DRB excepto SRB0;

1> configurar capas inferiores para suspender la protección de integridad y el cifrado.

5.3.3.16 Fallo de comprobación de integridad de capas inferiores mientras T300 se está ejecutando para UP-EDT El UE deberá:

1> al recibir una indicación de fallo de comprobación de integridad procedente de capas inferiores en relación con SRP1 o SRB2 mientras T300 se está ejecutando para UP-EDT:

2> descartar el contexto AS de UE almacenado y resumeldentity;

2> realizar las acciones al salir de RRC_CONNECTED como se indica en 5.3.12, siendo 'otra' la causa de liberación;

5.3.8.3 Recepción de RRCConnectionRelease por parte del UE

El UE deberá:

1> excepto para NB-IoT, los UE BL o los UE en CE, retrasar las siguientes acciones definidas en esta subcláusula 60 ms desde el momento en que se recibió el mensaje RRCConnectionRelease u, opcionalmente, cuando las capas inferiores indiquen que se ha acusado con éxito la recepción del mensaje RRCConnectionRelease, lo que se produzca primero;

1> para los UE BL o los UE en CE, retrasar las siguientes acciones definidas en esta subcláusula 1,25 segundos desde el momento en que se recibió el mensaje RRCConnectionRelease u, opcionalmente, cuando las capas inferiores indiquen que se ha acusado con éxito la recepción del mensaje RRCConnectionRelease, lo que se produzca primero;

1> para NB-IoT, retrasar las siguientes acciones definidas en esta subcláusula 10 segundos desde el momento en que se recibió el mensaje RRCConnectionRelease u, opcionalmente, cuando las capas inferiores indiquen que se ha acusado con éxito la recepción del mensaje RRCConnectionRelease, lo que se produzca primero. NOTA: Para los UE BL, los UE en CE y NB-IoT, cuando la notificación de STATUS, como se define en la especificación TS 36.322 [7], no se ha activado y el UE ha enviado retroalimentación de HARQ positiva (ACK), como se define en la especificación TS 36.321 [6], se puede considerar que las capas inferiores han indicado que se ha acusado recibo con éxito del mensaje RRCConnectionRelease.

1> si el mensaje RRCConnectionRelease se recibe en respuesta a una RRCConnectionResumeRequest para EDT:

2> descartar el contexto AS de UE almacenado y resumeldentity;

2> detener el temporizador T300;

2> detener el temporizador T302, si se está ejecutando;

2> detener el temporizador T303, si se está ejecutando;

2> detener el temporizador T305, si se está ejecutando;

2> detener el temporizador T306, si se está ejecutando;

2> detener el temporizador T308, si se está ejecutando;

2> realizar las acciones especificadas en 5.3.3.7;

2> detener el temporizador T320, si se está ejecutando;

2> detener el temporizador T322, si se está ejecutando;

1> si el mensaje RRCConnectionRelease incluye redirectedCarrierlnfo que indica redirección a geran; o 1> si el mensaje RRCConnectionRelease incluye idleModeMobilityControlInfo que incluye freqPriorityListGERAN: 2> si no se ha activado la seguridad AS; y

2> si las capas superiores indican que la redirección a GERAN sin seguridad AS no está permitida o si el UE está conectado a 5GC:

3> ignorar el contenido de RRCConnectionRelease;

3> realizar las acciones al salir de RRC_CONNECTED o RRC_INACTIVE como se indica en 5.3.12, siendo 'otra' la causa de liberación, tras lo cual finaliza el procedimiento;

1> si no se ha activado la seguridad AS:

2> ignorar el contenido de redirectedCarrierInfo, si está incluido e indica la redirección a nr;

2> ignorar el contenido de idleModeMobilityControlInfo, si está incluido e incluye freqPriorítyListNR;

2> si el UE ignora el contenido de redirectedCarrierInfo o de idleModeMobilityControlInfo:

3> realizar las acciones al salir de RRC_CONNECTED como se indica en 5.3.12, siendo 'otra' la causa de liberación, tras lo cual finaliza el procedimiento;

1> si el mensaje RRCConnectionRelease incluye redirectedCarrierInfo que indica la redirección a eutra y si el UE está conectado a 5GC:

2> si se incluye cn-Type:

3> el cn-Type recibido se proporciona a capas superiores;

NOTA 1: Depende de la implementación del UE el tratar el caso en que la célula E-UTRA seleccionada después de la redirección no admite el tipo de red central especificado por cn-Type.

1> si el mensaje RRCConnectionRelease incluye idleModeMobilityControlInfo:

2> almacenar la información de prioridad de reselección de célula proporcionada por idleModeMobilityControlInfo; 2> si se incluye el t320:

3> iniciar el temporizador T320, donde el valor del temporizador está establecido de acuerdo con el valor de t320; 1> si no:

2> aplicar la información de prioridad de reselección de célula difundida en la información del sistema;

1> si el mensaje RRCConnectionRelease incluye measIdleConfig:

2> borrar VarMeasIdleConfig y VarMeasIdleReport;

2> almacenar la mensIdleDuration recibida en VarMeasIdleReport;

2> iniciar T331 con el valor de MeasIdleDuration;

2> si MeasIdleConfig contiene MeasIdleCarrierListEUTRA:

3> almacenar mensIdleCarrierListEUTRA recibido en VarMeasIdleConfig;

2> si no:

3> almacenar en VarMeasIdleConfig el valor de MeasIdleCarrierListEUTRA recibido en SIB5;

2> comenzar a realizar mediciones en modo inactivo como se especifica en 5.6.20;

1> para NB-IoT, si el mensaje RRCConnectionRelease incluye redirectedCarrierInfo:

2> si el redirectedCarrierOffsetDedicated está incluido en el redirectedCarrierInfo:

3> almacenar el desfase dedicado para la frecuencia en redirectedCarrierInfo;

3> iniciar el temporizador T322, donde el valor del temporizador está establecido de acuerdo con el valor de T322 en redirectedCarrierInfo;

1> si releaseCause recibido en el mensaje RRCConnectionRelease indica loadBalancingTAURequired:

2> realizar las acciones al salir de RRC_CONNECTED como se especifica en 5.3.12, con la causa de liberación 'se requiere TAU de equilibrio de carga';

1> si no, si releaseCause recibido en el mensaje RRCConnectionRelease indica cs-FallbackHighPriority:

2> realizar las acciones al salir de RRC_CONNECTED como se especifica en 5.3.12, con la causa de liberación 'Alta prioridad de retroceso de CS';

1> si no:

2> si extendedWaitTime está presente; y

2> si el UE admite el acceso tolerante al retardo o el UE es un UE NB-IoT:

3> reenviar extendedWaitTime a capas superiores;

2> si ExtendedWaitTime-CPdata está presente y el UE NB-IoT solo admite la optimización EPS CIoT en el plano de control:

3> reenviar ExtendedWaitTime-CPdata a capas superiores;

2> si releaseCause recibido en el mensaje RRCConnectionRelease indica rrc-Suspend:

3> si se incluye rrc-InactiveConfig:

4> realizar las acciones entrar en RRC_INACTIVE como se especifica en 5.3.8.7;

3> si no:

4> realizar las acciones al salir de RRC_CONNECTED como se indica en 5.3.12, siendo 'suspensión de RRC' la causa de liberación;

2> si no:

3> realizar las acciones al salir de RRC_CONNECTED o RRC_INACTIVE como se especifica en 5.3.12, siendo 'otra' la causa de liberación;

La transmisión en recursos de enlace ascendente preconfigurados (PUR) se analiza en 3GPP RANI. Algunos acuerdos hechos por RANI se citan a continuación de la nota del presidente de 3GPP RANI #94, nota del presidente de 3GPP RANI #94bis, nota del presidente de 3GPP RANI #95. La nota del presidente de 3GPP RANI #94 proporciona lo siguiente:

Acuerdo

Los recursos de UL preconfigurados basados en modo inactivo son compatibles con los UE en posesión de una TA válida

• FFS: Mecanismo de validación para TA

• FFS: Cómo se adquieren los recursos de UL preconfigurados

Acuerdo

Para la transmisión en recursos de UL preconfigurados, el UE puede usar la TA más reciente del que se puede confirmar su validez

Acuerdo

Estudiar recursos compartidos y dedicados para recursos de UL preconfigurados. Si se admiten tanto los recursos compartidos como los dedicados, hay que procurar que el diseño de ambos tipos de recursos sea común.

Acuerdo

Se deben estudiar procedimientos HARQ para la transmisión en recursos de UL preconfigurados y se deben considerar los siguientes aspectos:

• Si se admite HARQ;

o Si se admite, detalles del diseño de HARQ, incluido el número de procesos HARQ;

• Si ACK/NACK es necesario

Se deben considerar mecanismos de retroceso, por ejemplo, retroceso a procedimientos RACH/EDT heredados. La nota del presidente de 3GPP RAN1 #94bis proporciona lo siguiente:

Acuerdo

En modo inactivo, el UE considerará al menos uno o más de los siguientes atributos al validar TA (se permite la combinación de múltiples atributos):

• Cambios en célula de servicio (la célula de servicio se refiere a la célula en la que está ubicado el UE)

• Temporizador de alineación de tiempo para el modo inactivo

• Cambios en RSRP de célula de servicio (la célula de servicio se refiere a la célula en la que está ubicado el UE) • FFS Otros atributos:

o Cambio en RSRP de célula vecina

o TDOA de >= 2 eNB

o Historial de TA

o Diferenciación de UE basada en suscripción

o Otros no excluidos (por ejemplo, atributos que deben tenerse en cuenta para los UE de alta movilidad) Cabe señalar que el consumo de energía del UE debe tenerse en cuenta para los atributos FFS

Acuerdo

Un recurso de UL preconfigurado dedicado se define como un recurso PUSCH usado por un único UE - El recurso PUSCH es un recurso de tiempo-frecuencia

- Un PUR dedicado es un recurso de UL preconfigurado compartido libre de contienda (PUR CFS) que se define como un recurso PUSCH usado simultáneamente por más de un UE

- Un recurso PUSCH es al menos un recurso de tiempo-frecuencia

- Un PUR CFS es un recurso de UL preconfigurado compartido basado en contienda (PUR CBS) que se define como un recurso PUSCH usado simultáneamente por más de un UE

- Un recurso PUSCH es al menos un recurso de tiempo-frecuencia

- Un PUR CBS está basado en contienda (un PUR CBS puede requerir resolución de contienda)

Acuerdo

En modo inactivo, se admite HARQ para la transmisión en PUR dedicado

• Se admite un solo proceso HARQ,

o FFS si se admite más de un proceso HARQ

• FFS: El diseño del espacio de búsqueda MPDCCH correspondiente

Acuerdo

En modo inactivo, se admite PUR dedicado.

• El soporte para PUR CFS es FFS.

• El soporte para PUR CBS es FFS.

Acuerdo

Para la transmisión UL en un recurso preconfigurado se admite el mecanismo de retroceso para procedimientos RACH/EDT.

Acuerdo

Para la transmisión en recursos UL preconfigurados, un UE inactivo de RRC puede usar la última TA que pasó los criterios de validación

Acuerdo

Los recursos de UL preconfigurados para la transmisión de datos se indican mediante señalización RRC. Se admite al menos señalización RRC específica de UE.

Acuerdo

La configuración de recursos incluye al menos lo siguiente

• Recursos en el dominio de tiempo, incluida(s) la(s) periodicidad(es)

• Recursos en el dominio de frecuencia

• TBS/MCS

Acuerdo

Un recurso de UL preconfigurado dedicado se define como un recurso NPUSCH usado por un único UE

• Un recurso NPUSCH es un recurso de tiempo-frecuencia

• Un PUR dedicado es un recurso de UL preconfigurado compartido libre de contienda (PUR CFS) que se define como un recurso NPUSCH usado simultáneamente por más de un UE

• Un recurso NPUSCH es al menos un recurso de tiempo-frecuencia

• Un PUR CFS es un recurso de UL preconfigurado compartido basado en contienda (PUR CBS) que se define como un recurso NPUSCH usado simultáneamente por más de un UE

• Un recurso NPUSCH es al menos un recurso de tiempo-frecuencia

• Un PUR CBS está basado en contienda (un PUR CBS puede requerir resolución de contienda)

La nota del presidente de 3GPP RANI #95 proporciona lo siguiente:

Mejoras adicionales de MTC

Acuerdo

Para un PUR dedicado en modo inactivo, el UE puede omitir las transmisiones de UL.

- FFS: Mecanismo de liberación de recursos

- FFS: Admitir o no el mecanismo para inhabilitar la omisión mediante un eNB

Acuerdo

Si la concesión de múltiples TB no está habilitada, una asignación de PUR dedicada se asocia a un solo TB y un solo proceso HARQ

- FFS: si la concesión de múltiples TB está habilitada/admitida

Acuerdo

En modo inactivo, se admiten al menos los siguientes atributos de validación de TA:

- Cambios en célula de servicio (la célula de servicio se refiere a la célula en la que está ubicado el UE) - Temporizador de alineación de tiempo para el modo inactivo

- Cambios en RSRP de célula de servicio (la célula de servicio se refiere a la célula en la que está ubicado el UE) o En base a la definición de medición de RSRP en la especificación Rel-15 TS 36.214 existente

Incluir en LS a RAN2, RAN4 a considerar en su funcionamiento.

Acuerdo

El UE puede configurarse para utilizar al menos estos atributos de validación de TA:

- Temporizador de alineación de tiempo para el modo inactivo

- Cambios en RSRP de célula de servicio

- Nota: la configuración admitirá la inhabilitación de los atributos de validación de TA

Incluir en LS a RAN2, RAN4

Para un estudio adicional:

Atributos de validación de TA:

- Diferenciación de UE basada en suscripción (o indicación estacionaria mantenida en suscripción)

- Indicación específica de célula donde TA es válida dentro de esa célula

Acuerdo

Incluir en LS a RAN2, RAN4:

RAN1 supone que un UE que pase de EDT/conectado al modo inactivo puede usar la TA válida que se usó mientras estaba en EDT/modo conectado.

Acuerdo

Para un PUR dedicado en modo inactivo, la concesión de UL para la retransmisión de HARQ se transmite en el espacio de búsqueda de MPDCCH

- FFS: Detalles acerca del espacio de búsqueda (por ejemplo, USS, CSS)

Acuerdo

Para un PUR dedicado en modo inactivo, tras la decodificación satisfactoria por parte de un eNB de una transmisión PUR, el UE puede esperar un ACK explícito

FFS: si se envía ACK en MPDCCH (capa 1) y/o PDSCH (capa 2/3), incluir en LS a RAN2, RAN4.

Acuerdo

Para un PUR dedicado en modo inactivo, tras la decodificación fallida por parte de un eNB de una transmisión PUR, el UE puede esperar

- una concesión de UL para retransmisión en el MPDCCH, o

- FFS: una NACK, o

- FFS: sin ACK explícita

Incluir en LS a RAN2, RAN4.

Mejoras adicionales para NB-IoT

Acuerdo

En modo inactivo, se admiten al menos los siguientes atributos de validación de TA:

- Cambios en célula de servicio (la célula de servicio se refiere a la célula en la que está ubicado el UE) - Temporizador de alineación de tiempo para el modo inactivo

- Cambios en NRSRP de célula de servicio (la célula de servicio se refiere a la célula en la que está ubicado el UE) o En base a la definición de medición de NRSRP en la especificación Rel-15 TS 36.214 existente

Enviar LS a RAN2, RAN4 a considerar en su funcionamiento. Todos los acuerdos con 'incluir en LS a RAN2, RAN4' para NB-IoT y eMTC deben capturarse en este LS. El LS está respaldado en R1-1813778

Acuerdo

El UE puede configurarse para utilizar al menos estos atributos de validación de TA:

- Temporizador de alineación de tiempo para el modo inactivo

- Cambios en NRSRP de célula de servicio

- Nota: la configuración admitirá la inhabilitación de los atributos de validación de TA

Incluir en LS a RAN2, RAN4.

Para un estudio adicional:

Atributos de validación de TA:

- Diferenciación de UE basada en suscripción (o indicación estacionaria mantenida en suscripción)

- Indicación específica de célula donde TA es válida dentro de esa célula

Acuerdo

Incluir en LS a RAN2, RAN4:

RAN1 supone que un UE que pase de EDT/conectado al modo inactivo puede usar la TA válida que se usó mientras estaba en EDT/modo conectado.

Acuerdo

Para un PUR dedicado en modo inactivo, el UE puede omitir las transmisiones de UL.

- FFS: Mecanismo de liberación de recursos

- FFS: Admitir o no el mecanismo para inhabilitar la omisión mediante un eNB

Acuerdo

En modo inactivo, solo se admite un proceso HARQ para un PUR dedicado

Acuerdo

Para un PUR dedicado en modo inactivo, la concesión de UL para la retransmisión de HARQ se transmite en el espacio de búsqueda

- FFS: Detalles acerca del espacio de búsqueda (por ejemplo, USS, CSS)

En los párrafos siguientes, "los UE de comunicaciones de tipo máquina (MTC)" podrían incluir "UE de ancho de banda reducido y de baja complejidad (BL)" y/o "UE con cobertura mejorada (UE en EC)".

En la versión 15 de LTE, para mejorar la eficacia de transmisión y reducir el consumo de energía para los UE de MTC y los UE de NB-IoT, se introduce la transmisión temprana de datos (EDT). Una EDT podría aplicarse a los UE de MTC y los UE de Internet de las cosas de banda estrecha (NB-IoT). Una EDT podría activarse en un estado RRC_IDLE. Después de que se activa una EDT, los datos de usuario de enlace ascendente (UL) (por ejemplo, datos de origen móvil) se incluyen en Msg3 durante un procedimiento de acceso aleatorio, y la red (NW) puede incluir datos de usuario de enlace descendente (DL) en Msg4 durante el procedimiento de acceso aleatorio. Una ventaja de una EDT es que los datos de usuario de enlace ascendente (UL) podrían transmitirse sin necesidad de entrar en un estado RRC_CONNECTED. También es posible que la EDT retroceda al procedimiento heredado de establecimiento/reanudación de conexión RRC, y los datos de usuario de UL pueden transmitirse después de que el UE entre en el estado RRC_CONNECTED.

Hay dos tipos de EDT:

• Los datos de usuario de UL de CP-EDT (EDT para optimizaciones de EPS de CIoT en el plano de control) se transmiten en un mensaje NAS concatenado en el mensaje RRCEarlyDataRequest de UL en el canal de control común (CCCH). RRCEarlyDataRequest se incluye en Msg3 durante un procedimiento de acceso aleatorio.

Los datos de usuario de enlace descendente (DL) pueden transmitirse opcionalmente en un mensaje de estrato de no acceso (NAS) concatenado en un mensaje RRCEarlyDataComplete de DL en CCCH. RRCEarlyDataComplete se incluye en Msg4 durante el procedimiento de acceso aleatorio.

Si la entidad de gestión de movilidad (MME) o el nodo B evolucionado (eNB) decide que el UE pase al modo RRC_CONNECTED, se envía el mensaje RRCConnectionSetup en Msg4 para retroceder al procedimiento heredado de establecimiento de conexión RRC.

• UP-EDT (EDT para optimizaciones de EPS de CIoT en el plano de usuario)

Los datos de usuario de UL se transmiten en un canal de tráfico dedicado (DTCH) multiplexado con un mensaje RRCConnectionResumeRequest de UL en CCCH. En este caso, tanto la unidad de datos de servicio DTCH (SDU) como la SDU CCCH se incluyen en Msg3 durante un procedimiento de acceso aleatorio.

Los datos de usuario de DL pueden transmitirse opcionalmente en un DTCH multiplexado con el mensaje RRCConnectionRelease de DL en un canal de control dedicado (DCCH). En este caso, tanto la SDU DTCH como la SDU DCCH se incluyen en Msg4 durante el procedimiento de acceso aleatorio.

Si la MME o el eNB deciden que el UE pase al modo RRC_CONNECTED, el mensaje RRCConnectionResume (y, opcionalmente, datos de usuario de DL) se envía en Msg4 para retroceder al procedimiento de reanudación de conexión RRC.

En la versión 16 de LTE, con el fin de mejorar aún más la eficacia de transmisión y reducir el consumo de energía en los UE de MTC y los UE de NB-IoT, se introducirán transmisiones en recursos de enlace ascendente (UL) preconfigurados (PUR), lo que se está debatiendo actualmente. De acuerdo con los acuerdos de RANI, el UE podría usar un PUR dedicado (es decir, no compartido entre múltiples UE) en el estado RRC_IDLE si se cumplen algunos criterios. Los criterios incluyen al menos una alineación de tiempo (TA) válida. El mecanismo de validación de una TA aún se está debatiendo y puede incluir, por ejemplo, un temporizador de TA para el modo inactivo. El UE puede considerar que su TA es válida si el temporizador de TA se está ejecutando. La solicitud de repetición automática híbrida (HARQ) es compatible con transmisiones que usan un PUR dedicado para mejorar la fiabilidad, pero los detalles aún se están debatiendo. Además, también se admite el mecanismo de retroceso a los procedimientos de canal de acceso aleatorio (RACH)/EDT, pero los detalles aún se están debatiendo. En los siguientes párrafos, los "UE" podrían incluir UE de MTC y/o UE de NB-IoT.

Todavía no está claro cómo transmisiones que usan un PUR se modelan en el lado del UE. Es posible que la configuración de un PUR se pueda proporcionar en una señalización dedicada al UE cuando el Ue está en un modo conectado RRC (o estado RRC_CONNECTED). El PUR configurado puede ser válido cuando el UE está en un modo inactivo RRC (o estado RRC_IDLE). Es posible que el PUR configurado no requiera una activación de capa inferior. El UE no puede usar el PUR configurado si no hay datos disponibles para la transmisión. El UE puede omitir una transmisión usando un PUR si no hay datos disponibles para la transmisión. El UE no puede generar una unidad de datos de protocolo (PDU) de control de acceso al medio (MAC) para la transmisión usando un PUR si no hay datos disponibles para la transmisión. Para un PUR dedicado, debido a que la NW puede identificar qué UE está realizando una transmisión usando un PUR, no se necesita resolución de contienda. Esto puede incluir dos etapas: (i) la transmisión usando un PUR, y (2) la recepción de la respuesta de NW. La respuesta de NW podría ser una confirmación de si la transmisión se ha recibido con éxito, por ejemplo, una retroalimentación HARQ o una indicación en un mensaje de radiolocalización. La respuesta de NW podría ser una concesión de UL dinámica para la retransmisión. La respuesta de NW podría ser un mensaje de datos de usuario de DL y/o un mensaje de control de recursos radioeléctricos (RRC), por ejemplo, un mensaje RRCEarlyDataComplete. Los datos de usuario de DL y/o el mensaje RRC podrían planificarse mediante una asignación de DL dinámica. La asignación de DL dinámica podría dirigirse a un identificador temporal de red radioeléctrica (RNTI) específico (por ejemplo, Cell-RNTI (C-RNTI) (del UE cuando el UE estuvo por última vez en RRC_CONNECTED), un C-Rn T i temporal o un nuevo RNTI). El RNTI específico podría proporcionarse en la configuración de PUR dedicada. El RNTI específico podría proporcionarse cuando el UE está en estado RRC_CONNECTED. Los datos de usuario de DL y/o el mensaje RRC podrían planificarse mediante un mensaje de radiolocalización dedicado para el UE. Los datos de usuario de DL y/o el mensaje RRC podrían transportarse en un mensaje de radiolocalización (dedicado) para el UE. Si se requiere retransmisión, el UE puede realizar la retransmisión en la siguiente ocasión de PUR o en base a una concesión de UL dinámica recibida en la segunda etapa (en caso de que se admita la concesión de UL dinámica en modo IDLE).

La NW puede configurar un UE con diferentes conjuntos de configuraciones de PUR para facilitar diferentes condiciones de radio en la misma célula de servicio. Por ejemplo, cada conjunto de configuraciones de PUR se configura por nivel de cobertura mejorada (nivel de EC). Un intento de PUR puede producirse cuando el UE transmite una PDU MAC en una ocasión de PUR. La ocasión de PUR puede estar preconfigurada en una configuración de PUR o puede proporcionarse en una concesión de UL dinámica. El UE puede considerar un intento de PUR como fallido si una concesión de UL dinámica para la retransmisión se recibe en respuesta al intento de PUR. El UE puede considerar un intento de PUR como fallido si no se recibe nada dentro de un período de tiempo en respuesta al intento de PUR.

Un UE debería estar provisto de al menos una configuración (o conjunto de configuraciones) de PUR antes de realizar una transmisión utilizando PUR. Una configuración (o conjunto de configuraciones) de PUR puede incluir al menos uno de los siguientes parámetros: tamaño(s) de bloque de transporte (tamaño de TB); esquema(s) de modulación y codificación (MCS); periodicidad en el dominio de tiempo en unidades de horas, segundos, números de hipertrama (HFN), números de trama de sistema (SFN), subtramas, ranuras, símbolos; desfase en el dominio de tiempo en unidades de horas, segundos, HFN, SFN, subtramas, ranuras, símbolos; ubicación/desfase en el dominio de frecuencia; umbral (por ejemplo, umbral de potencia recibida de señal de referencia (RSRP)); número (máximo) de repeticiones por cada intento de transmisión usando PUR; potencia de transmisión (potencia Tx) para cada intento de transmisión usando PUR; o etapa de aumento de potencia. Algunos de los parámetros mencionados anteriormente pueden tener diferentes valores para diferentes conjuntos de configuraciones de PUR. Es posible que algunos de los parámetros mencionados anteriormente no se incluyan en los conjuntos de configuraciones de PUR y se compartan entre múltiples conjuntos de configuraciones de PUR. Por ejemplo, se puede compartir la periodicidad en el dominio de tiempo y no compartirse el número (máximo) de repeticiones. En otro ejemplo, el/los tamaño(s) de TB se comparte(n) y la potencia Tx no se comparte.

En respuesta a la aparición de uno o algunos de los siguientes eventos (cada evento puede ser independiente entre sí), se debe considerar si el UE necesita liberar su(s) conjunto(s) (dedicado(s) y/o compartido(s)) de configuraciones de PUR:

- Entrar en RRC_CONNECTED

El UE podría liberar (todas) sus configuraciones de PUR en respuesta a entrar en RRC_CONNECTED. El UE podría liberar (todas) sus configuraciones de PUR al entrar en RRC_CONNECTED. De forma alternativa, el UE podría guardar (o mantener o almacenar)(todas) sus configuraciones de PUR en respuesta a entrar en RRC_CONNECTED.

Además de mantener (todas) las configuraciones de PUR, de acuerdo con la presente invención, el UE suspende el uso de (todas) sus configuraciones de PUR cuando el UE está en el estado RRC_CONNECTED. En otras palabras, el UE mantiene (todas) las configuraciones de PUR cuando se suspende el uso de la(s) configuración(es) de PUR. La suspensión de una configuración de PUR o de un conjunto de configuraciones de PUR significa que el UE no realiza una transmisión usando un PUR asociado a la configuración de PUR o el conjunto de configuraciones de PUR. El UE reanuda el uso de (todas) las configuraciones de PUR cuando el UE entra de nuevo en el estado RRC_IDLE.

El UE podría entrar en RRC_CONNECTED mediante un procedimiento de establecimiento de conexión RRC. Por ejemplo, el UE entre en RRC_CONNECTED al recibir un mensaje RRCConnectionSetup. De forma alternativa, el UE podría entrar en RRC_CONNECTED mediante un procedimiento de reanudación de conexión RRC. Por ejemplo, el UE entre en RRC_CONNECTED tras la recepción de un mensaje RRCConnectionResume.

Por ejemplo, en respuesta a la recepción de un mensaje RRCConnectionSetup, el UE podría liberar de forma autónoma (todas) sus configuraciones de PUR.

En un ejemplo alternativo, en respuesta a la recepción de un mensaje RRCConnectionSetup, el UE no libera de forma autónoma (todas) sus configuraciones de PUR.

Puede que no sea necesaria una indicación explícita en el mensaje RRCConnectionSetup para decirle al UE que libere su(s) configuración(es) de PUR. De forma alternativa, se podría incluir una indicación en el mensaje RRCConnectionSetup para decirle al UE si debe liberar (todas) las configuraciones de PUR.

Por ejemplo, en respuesta a la recepción de un mensaje RRCConnectionResume, el UE podría liberar de forma autónoma (todas) sus configuraciones de PUR.

En un ejemplo alternativo, en respuesta a la recepción de un mensaje RRCConnectionResume, el UE no libera de forma autónoma (todas) sus configuraciones de PUR.

Puede que no sea necesaria una indicación explícita en el mensaje RRCConnectionResume para decirle al UE que libere la(s) configuración(es) de PUR. De forma alternativa, se podría incluir una indicación en el mensaje RRCConnectionResume para decirle al UE si debe liberar (todas) las configuraciones de PUR.

Por ejemplo, se podría incluir una indicación en un mensaje RRCConnectionRelease para decirle al UE si debe liberar (todas) las configuraciones de PUR.

Por ejemplo, en respuesta a la transmisión de un mensaje RRCConnectionSetupComplete, el UE podría liberar de forma autónoma (todas) sus configuraciones de PUR.

Por ejemplo, en respuesta a la transmisión de un mensaje RRCConnectionResumeComplete, el UE podría liberar de forma autónoma (todas) sus configuraciones de PUR.

- Se cambia la configuración (conjunto de configuraciones) de PUR en uso

El UE puede conmutar o cambiar las configuraciones (conjunto de configuraciones) de PUR actualmente en uso. Por ejemplo, un primer conjunto de configuraciones de PUR está asociado a un primer nivel de EC y un segundo conjunto de configuraciones de PUR está asociado a un segundo nivel de EC. Cuando el nivel de EC actual se cambia del primer nivel de EC al segundo nivel de EC, el conjunto de configuraciones de PUR en uso se cambia del primer conjunto al segundo conjunto. En otro ejemplo, la NW podría enviar un mensaje que incluye una indicación al UE, en el que la indicación indica que el UE debe cambiar el nivel de EC y/o cambiar la configuración (conjunto de configuraciones) de PUR del primer conjunto al segundo conjunto. La NW puede enviar el mensaje en respuesta a una recepción satisfactoria de un intento de PUR procedente del UE. La NW puede enviar el mensaje en respuesta a una recepción fallida de un intento de PUR procedente del UE.

En respuesta al cambio/conmutación del conjunto de configuraciones de PUR, el UE podría liberar el primer conjunto de configuraciones de PUR. De forma alternativa, en respuesta a cambiar/conmutar el conjunto de configuraciones de PUR, el UE podría suspender el primer conjunto de configuraciones de PUR. De forma alternativa, en respuesta a cambiar/conmutar el conjunto de configuraciones de PUR, el UE podría mantener el primer conjunto de configuraciones de PUR.

El cambio de las configuraciones de PUR puede deberse a que un intento de PUR falló en el primer nivel de EC. De forma alternativa, el cambio de configuraciones de PUR puede deberse a que se ha alcanzado el número máximo de intentos de PUR en el primer nivel de EC. De forma alternativa, el cambio de las configuraciones de PUR puede deberse a que un intento fallido de PUR que usa el primer conjunto de configuraciones de PUR. De forma alternativa, el cambio de las configuraciones de PUR puede deberse a que se ha alcanzado el número máximo de intentos de PUR usando el primer conjunto de configuraciones de PUR. De forma alternativa, el cambio de las configuraciones de PUR puede deberse a que la RSRP medida más reciente se encuentra dentro del intervalo de RSRP para el segundo nivel de EC. De forma alternativa, el cambio de las configuraciones de PUR puede deberse a que la RSRP medida más reciente se encuentra dentro del intervalo de RSRP para el segundo conjunto de configuraciones de PUR. De forma alternativa, el cambio de las configuraciones de PUR puede deberse a la indicación de NW, como se describe anteriormente.

Además de mantener el primer conjunto de configuraciones de PUR, el UE puede suspender el uso del primer conjunto de configuraciones de PUR. La suspensión de un conjunto de configuraciones de PUR podría significar que el UE no realiza una transmisión usando el PUR asociado al conjunto de configuraciones de PUR. El UE podría reanudar el uso del primer conjunto de configuraciones de PUR cuando el nivel de EC actual se cambia de nuevo al primer nivel de EC.

- La alineación de tiempo (TA) de enlace ascendente se vuelve no válida (por ejemplo, el temporizador de avance de temporización (TAT) expira, la célula de servicio cambia)

El UE podría liberar una configuración de PUR o un conjunto de configuraciones de PUR en respuesta a que la TA asociada a la configuración de PUR o al conjunto de configuraciones de PUR se vuelva no válida. De forma alternativa, el UE podría mantener la configuración de PUR o el conjunto de configuraciones de PUR en respuesta a que la TA asociada a la configuración de PUR o al conjunto de configuraciones de PUR se vuelva no válida.

Por ejemplo, si la TA para PUR deja de ser válida durante un intento de PUR, el UE libera de forma autónoma (todas) sus configuraciones de PUR. En otro ejemplo, si la TA para PUR deja de ser válida cuando no hay ningún PUR en curso, el UE libera de forma autónoma (todas) sus configuraciones de PUR. De forma alternativa, si la TA para PUR deja de ser válida durante un intento de PUR y/o mientras no hay ningún PUR en curso, el UE mantiene (todas) sus configuraciones de PUR.

La TA asociada a un conjunto de configuraciones de PUR puede dejar de ser válida porque el temporizador de TA asociado al conjunto de configuraciones de PUR expira. La TA asociada a un conjunto de configuraciones de PUR puede dejar de ser válida porque el UE está ubicado en una célula no asociada al conjunto de configuraciones de PUR. La TA asociada a un conjunto de configuraciones de PUR puede dejar de ser válida debido a una condición de radio (por ejemplo, RSRP) de cambios en células en las que se está ubicado, por ejemplo, peor que un umbral para (o en) el conjunto de configuraciones de PUR. La TA asociada a un conjunto de configuraciones de PUR puede dejar de ser válida debido a que el UE queda fuera de cobertura.

Pueden realizarse combinaciones de los ejemplos anteriores. Por ejemplo, el UE mantiene (todas) sus configuraciones de PUR si la TA para PUR deja de ser válida debido a que el temporizador de TA para PUR expira, y el UE libera de forma autónoma (todas) sus configuraciones de PUR si la TA para PUR deja de ser válida debido a cambios en la célula de servicio.

Además de mantener el conjunto de configuraciones de PUR, el UE puede suspender usando el conjunto de configuraciones de PUR. La suspensión de un conjunto de configuraciones de PUR podría significar que el UE no realiza una transmisión usando un PUR asociado al conjunto de configuraciones de PUR. El UE podría reanudar el uso del conjunto de configuraciones de PUR cuando la TA asociada al conjunto de configuraciones de PUR vuelva a ser válida.

- Se inicia el procedimiento RA

El UE podría liberar (todas) sus configuraciones de PUR en respuesta al inicio de un procedimiento RA, por ejemplo, cuando el UE está en RRC_IDLE. De forma alternativa, el UE podría suspender (todas) sus configuraciones de PUR en respuesta al inicio de un procedimiento RA, por ejemplo, cuando el UE está en RRC_IDLE. De forma alternativa, el UE podría mantener (todas) sus configuraciones de PUR en respuesta al inicio de un procedimiento RA, por ejemplo, cuando el UE está en RRC_IDLE.

El procedimiento RA podría ser para un EDT. De forma alternativa, el procedimiento RA no es para un EDT.

El UE puede determinar si liberar o mantener (todas) sus configuraciones de PUR basándose en si el procedimiento RA es para un EDT o no para EDT. Por ejemplo, si el procedimiento RA es para un EDT, el UE podría mantener (todas) sus configuraciones de PUR en respuesta al inicio del procedimiento RA. Si el procedimiento RA no es para EDT, el UE podría liberar (todas) sus configuraciones de p Ur en respuesta al inicio del procedimiento RA.

Por ejemplo, cuando se inicia un procedimiento RA, pero hay un PUR en curso (por ejemplo, el RA se activa debido a que no se cumplen las condiciones de uso de PUR), el UE libera de forma autónoma (todas) sus configuraciones de PUR. De forma alternativa, cuando se inicia un procedimiento RA, pero hay un PUR en curso (por ejemplo, el RA se activa debido a que no se cumplen las condiciones de uso de PUR), el UE mantiene (todas) sus configuraciones de PUR.

Además de mantener (todas) las configuraciones de PUR, el UE puede suspender el uso de (todas) las configuraciones de PUR. La suspensión de un conjunto de configuraciones de PUR podría significar que el UE no realiza una transmisión usando un PUR asociado al conjunto de configuraciones de PUR. El UE podría reanudar el uso del conjunto de configuraciones de PUR en respuesta a la finalización (satisfactoria) del procedimiento RA.

- La liberación de la conexión RRC o datos tempranos completos de RRC se reciben en respuesta a la transmisión mediante PUR

Para completar con éxito una EDT, la NW incluye un mensaje RRCConnectionRelease o RRCEarlyDataComplete en el Msg4 del procedimiento RA para EDT. Si se usa PUR para EDT, la NW también puede incluir un mensaje RRCConnectionRelease o RRCEarlyDataComplete en la respuesta de NW para PUR a fin de indicar la finalización satisfactoria de la EDT. El UE puede determinar si liberar o mantener conjuntos de configuraciones de PUR tras la recepción del mensaje. De forma alternativa, podría haber una indicación en el mensaje, y el UE determina si liberar o mantener el/los conjunto(s) de configuraciones de PUR basándose en la indicación.

Por ejemplo, cuando el UE recibe un mensaje RRCConnectionRelease en respuesta a una transmisión de un mensaje RRCConnectionResumeRequest usando PUR, el UE libera de forma autónoma (todas) sus configuraciones de PUR. De forma alternativa, cuando el UE recibe un mensaje RRCConnectionRelease en respuesta a una transmisión de un mensaje RRCConnectionResumeRequest usando PUR, el UE mantiene (todas) sus configuraciones de PUR.

Por ejemplo, cuando el UE recibe un mensaje RRCEarlyDataComplete en respuesta a una transmisión de un mensaje RRCEarlyDataRequest usando PUR, el UE libera de forma autónoma (todas) sus configuraciones de PUR. De forma alternativa, cuando el UE recibe un mensaje RRCEarlyDataComplete en respuesta a una transmisión de un mensaje RRCEarlyDataRequest usando PUR, el UE mantiene (todas) sus configuraciones de PUR.

Por ejemplo, si el mensaje RRCConnectionRelease o RRCEarlyDataComplete indica que el UE debe liberar (todas) sus configuraciones de PUR, el UE libera (todas) sus configuraciones de PUR. Si el mensaje RRCConnectionRelease o RRCEarlyDataComplete indica que el UE debe mantener (todas) sus configuraciones de PUR, el UE mantiene (todas) sus configuraciones de PUR. Por ejemplo, si el mensaje RRCConnectionRelease o RRCEarlyDataComplete no contiene ninguna configuración de PUR, el UE libera (todas) sus configuraciones de PUR. Por ejemplo, si el mensaje RRCConnectionRelease o RRCEarlyDataComplete no contiene ninguna configuración de PUR, el UE mantiene (todas) sus configuraciones de PUR. Si el mensaje RRCConnectionRelease o RRCEarlyDataComplete contiene al menos una configuración (conjunto de configuraciones) de PUR, el UE se actualiza en consecuencia.

Además de mantener (todas) las configuraciones de PUR, el UE puede suspender el uso de (todas) las configuraciones de PUR. La suspensión de un conjunto de configuraciones de PUR podría significar que el UE no realiza una transmisión usando un PUR asociado al conjunto de configuraciones de PUR. El UE podría reanudar el uso del conjunto de configuraciones de PUR si el UE recibe una indicación de la NW que indica que el UE podría usar el conjunto de configuraciones de PUR.

- Se recibe respuesta de NW para PUR

La respuesta de NW para un PUR podría ser la respuesta para una (re)transmisión usando el PUR. La respuesta de NW para un PUR podría ser la respuesta para una retransmisión planificada por una concesión de UL dinámica para un PUR.

Después de que el UE transmita datos de UL usando una configuración (un conjunto de configuraciones) de PUR, pero los datos UL no contienen ningún mensaje RRC, la respuesta de NW podría ser una Información de control de enlace descendente (DCI) (por ejemplo, una retroalimentación HARQ), una concesión de UL dinámica para retransmisión, o un mensaje d L que contiene un elemento de control MAC. El UE puede determinar si liberar o mantener la configuración (conjunto de configuraciones) de PUR tras la recepción de la respuesta de NW o determinar si liberar o mantener la configuración (conjunto de configuraciones) de PUR basándose en el contenido de la respuesta de NW.

Por ejemplo, si se recibe un DCI que indica "ACK", el UE mantiene el conjunto de configuraciones de PUR. Por ejemplo, si se recibe un DCI que indica "NACK", el UE mantiene el conjunto de configuraciones de PUR. Por ejemplo, si se recibe un DCI que indica "NACK", el UE libera el conjunto de configuraciones de PUR. Por ejemplo, si no se recibe ninguna respuesta de NW dentro de un período de tiempo, el UE mantiene el conjunto de configuraciones de PUR. Por ejemplo, si no se recibe ninguna respuesta de NW dentro de un período de tiempo, el UE libera el conjunto de configuraciones de PUR. Por ejemplo, si se recibe una concesión de UL dinámica para la retransmisión, el UE mantiene el conjunto de configuraciones de PUR. Por ejemplo, si se recibe una concesión de UL dinámica para la retransmisión, el UE libera el conjunto de configuraciones de PUR. Por ejemplo, si se recibe una concesión de UL dinámica para la retransmisión, el UE actualiza el conjunto de configuraciones de PUR basándose en la concesión de UL dinámica.

Por ejemplo, si se recibe un mensaje de DL en respuesta a la transmisión usando PUR y el mensaje no contiene información relacionada con TA (por ejemplo, comando de avance de temporización), el UE libera de forma autónoma el conjunto de configuraciones de PUR o libera (todas) sus configuraciones de PUR. De forma alternativa, si se recibe un mensaje de DL en respuesta a la transmisión usando un PUR y el mensaje no contiene información relacionada con TA (por ejemplo, comando de avance de temporización), el UE mantiene (todas) sus configuraciones de PUR.

Además de mantener (todas) las configuraciones de PUR, el UE puede suspender el uso de (todas) las configuraciones de PUR. La suspensión de un conjunto de configuraciones de PUR podría significar que el UE no realiza una transmisión usando un PUR asociado al conjunto de configuraciones de PUR. El UE podría reanudar el uso del conjunto de configuraciones de PUR si el UE recibe una indicación de la NW que indica que el UE podría usar el conjunto de configuraciones de PUR.

- Recepción de señalización relacionada con radiolocalización

En el estado RRC_IDLE, el UE supervisa las ocasiones de radiolocalización para recibir mensajes de radiolocalización. Es posible que algunos mensajes de radiolocalización no contengan información relacionada con los ID de UE. Es posible que algunos mensajes de radiolocalización contengan información relacionada con los ID de UE. Además, si se configura una señalización de activación (WUS), el UE supervisa las ocasiones de WUS para recibir una WUS. Si se configura una WUS basada en grupo, el UE supervisa las ocasiones de WUS basada en grupo para recibir una WUS basada en grupo. El UE puede determinar si liberar o mantener conjuntos de configuraciones de PUR al recibir mensajes de radiolocalización o WUS (basadas en grupos) o determinar si liberar o mantener conjuntos de configuraciones de PUR basándose en los mensajes de radiolocalización recibidos o WUS (basadas en grupos).

Por ejemplo, el UE libera (todas) sus configuraciones de PUR en respuesta a la recepción de un canal físico de control de enlace descendente (PDCCH) dirigido a un identificador temporal de red radioeléctrica de radiolocalización (P-RNTI) con una indicación en el PDCCH. Por ejemplo, el UE libera (todas) sus configuraciones de PUR en respuesta a la recepción de un mensaje de radiolocalización que contiene información relacionada con ID de UE para el UE. En otro ejemplo, el UE libera (todas) sus configuraciones de PUR en respuesta a la recepción de mensajes de radiolocalización que contienen una indicación independientemente de si el mensaje de radiolocalización contiene información relacionada con ID de UE. En otro ejemplo, el UE libera (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS. En otro ejemplo, el UE libera (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS basada en grupo. En otro ejemplo, el UE libera (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS que contiene una indicación. En otro ejemplo, el UE libera (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS basada en grupo que contiene una indicación.

Por ejemplo, el UE mantiene (todas) sus configuraciones de PUR en respuesta a la recepción de un PDCCH dirigido a P-RNTI con una indicación en el PDCCH. Por ejemplo, el UE mantiene (todas) sus configuraciones de PUR en respuesta a la recepción de un mensaje de radiolocalización que contiene información relacionada con ID de UE para el UE. En otro ejemplo, el UE mantiene (todas) sus configuraciones de PUR en respuesta a la recepción de mensajes de radiolocalización que contienen una indicación independientemente de si el mensaje de radiolocalización contiene información relacionada con ID de UE. En otro ejemplo, el UE mantiene (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS. En otro ejemplo, el UE mantiene (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS basada en grupo. En otro ejemplo, el UE mantiene (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS que contiene una indicación. En otro ejemplo, el UE mantiene (todas) sus configuraciones de PUR en respuesta a la recepción de una WUS basada en grupo que contiene una indicación.

Además de mantener (todas) las configuraciones de PUR, el UE puede suspender el uso de (todas) las configuraciones de PUR. La suspensión de un conjunto de configuraciones de PUR podría significar que el UE no realiza una transmisión usando un PUR asociado al conjunto de configuraciones de PUR. El UE podría reanudar el uso del conjunto de configuraciones de PUR si el UE recibe una indicación de la NW.

Pueden realizarse combinaciones de los ejemplos anteriores. Por ejemplo, el UE mantiene (todas) sus configuraciones de PUR si el UE recibe un mensaje de radiolocalización sin una indicación, y el UE libera (todas) sus configuraciones de PUR si el UE recibe un mensaje de radiolocalización, y el mensaje de radiolocalización contiene una indicación.

En los ejemplos divulgados anteriormente, la indicación podría indicar que el UE debería liberar (todas) las configuraciones de PUR. De forma alternativa, la indicación podría indicar que el UE debería mantener (todas) las configuraciones de PUR. En otro ejemplo, la indicación podría indicar que el UE debería liberar el/los conjunto(s) de configuraciones de PUR asociado(s) a un determinado nivel de EC o una determinada condición de radio. En otro ejemplo, la indicación podría indicar que el UE debería mantener el/los conjunto(s) de configuraciones de PUR ^{asociado(s) a un determinado nivel de} eC o una determinada condición de radio.

- Indicado en información del sistema (por ejemplo, el soporte de PUR se activa/desactiva)

Algunos de los parámetros o información de un PUR se difunden en la información de sistema (SI). El UE adquiere la(s) SI, por ejemplo, al volver a seleccionar una célula o al recibir una notificación de que la información del sistema ^{ha cambiado. El} Ue determina si liberar o mantener el/los conjunto(s) de configuraciones de PUR tras la adquisición de la(s) SI o determina si liberar o mantener el/los conjunto(s) de configuraciones de PUR basándose en el contenido de la(s) SI.

En la presente invención, se incluye una indicación en la(s) SI. La indicación podría incluirse en un SystemlnformationBlockTypel-BR y/o en un SystemlnformationBlockType1-NB. En otro ejemplo, la indicación podría incluirse en SystemInformationBlockType2 y/o en SystemInformationBlockType2-NB. En otro ejemplo, la indicación podría incluirse en otro(s) SIB. En la presente invención, el UE libera (todas) sus configuraciones de PUR si la indicación indica que la célula de servicio no admite PUR o que el soporte de PUR está desactivado. En otro ejemplo, el UE podría liberar el/los conjunto(s) de configuraciones de PUR asociado(s) a un determinado nivel de EC (o una determinada condición de radio) si la indicación indica que el determinado nivel de EC de la célula de servicio no admite PUR o el soporte de PUR para el determinado nivel de EC está desactivado. En otro ejemplo no cubierto por las reivindicaciones, el UE podría mantener (todas) sus configuraciones de PUR pero no las usa si la indicación indica que la célula de servicio no admite PUR o que el soporte de PUR está desactivado, y el UE podría usar su(s) configuración(es) de PUR más tarde si la indicación indica que la célula de servicio admite PUR o que el soporte de PUR está de nuevo activado. En otro ejemplo, el UE podría mantener el/los conjunto(s) de configuraciones de PUR asociado(s) a un determinado nivel de Ec (o una determinada condición de radio), pero el UE no usa el/los conjunto(s) de configuraciones de PUR si la indicación indica que el determinado nivel de EC de la célula de servicio no admite PUR o el soporte de PUR para el determinado nivel de EC está desactivado, y el UE podría usar el/los conjunto(s) de configuraciones de PUR más tarde si la indicación indica que el determinado nivel de EC de la célula de servicio admite PUR o que el soporte de PUR para el determinado nivel de EC está de nuevo activado. En un ejemplo, basándose en la indicación, el UE puede liberar toda su configuración de PUR inmediatamente después de que el UE adquiera la(s) SI. En otro ejemplo, basándose en la indicación, el UE puede liberar toda su configuración de PUR cuando los datos de UL estén disponibles para su transmisión. La indicación en la información de sistema también puede usarse para indicar que esta célula de servicio admite PUR o que PUR es compatible con esta célula de servicio.

Pueden producirse combinaciones de los eventos anteriores. Por ejemplo, el UE mantiene (todas) sus configuraciones de PUR cuando una TA para PUR deja de ser válida y libera (todas) sus configuraciones de PUR cuando el UE entra en el estado RRC_c On NECTED.

Si el UE libera una configuración (un conjunto de configuraciones) de PUR, el UE no realiza la transmisión de UL usando recursos de UL asociados a la configuración (conjunto de configuraciones) de PUR. Después de que el UE libere al menos una configuración (conjunto de configuraciones) de PUR, el UE puede iniciar un procedimiento RA en respuesta a la recepción de una concesión de UL dinámica para la retransmisión de PUR. Después de que el UE libere al menos una configuración (conjunto de configuraciones) de PUR, el UE puede iniciar inmediatamente un procedimiento RA. Después de que el UE libere al menos una configuración (conjunto de configuraciones) de PUR, el UE puede generar una indicación e incluye la indicación en un Msg3 de un procedimiento RA para indicar a la NW que el UE ha liberado al menos una configuración (conjunto de configuraciones) de PUR. La indicación podría ser un elemento de control MAC. La indicación podría ser un mensaje RRC.

En respuesta a la recepción de la indicación del UE, la NW puede determinar que al menos una configuración (conjunto de configuraciones) de PUR es liberada/o por el UE, y podría asignar a otro UE los recursos de UL asociados. De forma adicional o alternativa, cuando el UE entra en el estado RRC_CONNECTED, la NW puede determinar que al menos una configuración (conjunto de configuraciones) de PUR es liberada/o por el UE, y podría asignar a otro UE los recursos de UL asociados. De forma adicional o alternativa, en respuesta a la transmisión de un mensaje (por ejemplo, retroalimentación HARQ, mensaje de radiolocalización, elemento de control MAC y/o mensaje RRC) al Ue , la NW puede determinar que al menos una configuración (conjunto de configuraciones) de PUR es liberada/o por el UE, y podría asignar a otro UE los recursos de UL asociados.

En los párrafos anteriores, las soluciones o acciones solo podrían aplicarse a PUR basados en contienda, solo a PUR libres de contienda, o tanto a PUR basados en contienda como a libres de contienda. En los párrafos anteriores, el UE realiza las soluciones o acciones en el estado RRC_IDLE o antes de entrar en el estado RRC_CONNECTED.

La figura 18 es un diagrama de flujo 1800 de acuerdo con un modo de realización ejemplar desde la perspectiva de un UE. En la etapa 1805, el UE recibe una configuración de un recurso de enlace ascendente preconfigurado (PUR) cuando el u E está en un primer estado RRC_CONNECTED. En la etapa 1810, el UE entra en un primer estado RRC_IDLE desde el primer estado RRC_CONNECTED. En la etapa 1815, el UE realiza una primera transmisión usando el PUR cuando el UE está en el primer estado RRC_IDLe . En la etapa 1820, el UE entra en un segundo estado RRC_CONNECTED desde el primer estado RRC_IDLE. En la etapa 1825, el UE suspende la configuración cuando el UE está en el segundo estado RRC_CONNECTED. En la etapa 1830, el UE reanuda la configuración cuando el UE entra en un segundo estado RRC_IDLE desde el segundo estado RRC_CONNECTED. En la etapa 1835, el UE realiza una segunda transmisión usando el PUR cuando el UE está en el segundo estado RRC_IDLE.

Preferentemente, el UE mantiene (o retiene) la configuración cuando se suspende la configuración.

En la presente invención, el UE no realiza transmisiones (por ejemplo, la primera transmisión y/o la segunda transmisión) usando el PUR si (o en respuesta a que) la configuración está suspendida.

En la presente invención, el procedimiento incluye además liberar la configuración si (o en respuesta a que) el UE recibe una indicación en una información del sistema para indicar que una célula de servicio no admite el PUR, o liberar la configuración si (o en respuesta a que) el UE recibe una indicación en una información del sistema para indicar que el soporte del PUR está desactivado.

Preferentemente, el procedimiento incluye además liberar la configuración en base a una indicación en un mensaje RRCConnectionRelease. Preferentemente, el procedimiento incluye además liberar la configuración en base a una indicación en un mensaje RRCEarlyDataComplete.

Preferentemente, el procedimiento incluye además liberar la configuración en base a una indicación en un mensaje de radiolocalización. Preferentemente, el procedimiento incluye además liberar la configuración en base a una indicación en una señalización de activación (WUS).

Preferentemente, el UE no realiza las transmisiones usando el PUR si (o en respuesta a que) se libera la configuración.

Preferentemente, el UE omite las transmisiones usando el PUR si (o en respuesta a que) el UE no tiene datos disponibles para las transmisiones.

Preferentemente, la configuración se proporciona al UE en una señalización dedicada, tal como un mensaje RRCConnectionRelease.

Preferentemente, la configuración incluye al menos uno de los siguientes parámetros: un tamaño de bloque de transporte (TBS), un esquema de modulación y codificación (MCS), una periodicidad en el dominio de tiempo, un desfase en el dominio de tiempo, una ubicación/desfase en el dominio de frecuencia, un umbral de potencia de recepción de señal de referencia (RSRP), un número de repeticiones para cada intento de una transmisión usando PUR, una potencia de transmisión para cada intento de transmisión usando PUR y un etapa de aumento de potencia.

Como apreciarán los expertos en la técnica, los diversos modos de realización y/o procedimientos desvelados pueden combinarse para formar nuevos modos de realización y/o procedimientos.

En referencia de nuevo a las figuras 3 y 4, en un modo de realización, el dispositivo 300 incluye un código de programa 312 almacenado en memoria 310. La CPU 308 podría ejecutar código de programa 312 para (i) recibir una configuración de un recurso de enlace ascendente (PUR) preconfigurado cuando el UE está en un primer estado RRC_CONNECTED, (ii) entrar en un primer estado RRC_IDLE desde el primer estado RRC_CONNECTED, (iii) realizar una primera transmisión usando el PUR cuando el UE está en el primer estado RRC_IDLE, (iv) entrar en un segundo estado RRC_CONNECTED desde el primer estado RRC_IDLE, (v) suspender la configuración cuando el UE está en el segundo estado RRC_CONNECTED, (vi) reanudar la configuración cuando el UE entra en un segundo estado RRC_IDLE desde el segundo estado RRC_CONNECTED, (vii) realizar una segunda transmisión usando el PUR cuando el UE está en el segundo estado RRC_IDLE.

Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones y etapas descritas anteriormente u otros descritos en el presente documento.

Los procedimientos divulgados anteriormente permiten que el UE libere configuraciones de PUR si no se necesita PUR y que no libere configuraciones de PUR si todavía se necesita PUR.

En lo que antecede se han descrito diversos aspectos de la divulgación. Debería ser evidente que las enseñanzas del presente documento se pueden expresar en una amplia variedad de formas y que cualquier estructura o función específica, o ambas, que se divulguen en el presente documento son simplemente representativas. En base a las enseñanzas del presente documento, un experto en la técnica debería apreciar que un aspecto divulgado en el presente documento se puede implementar independientemente de cualesquiera otros aspectos, y que dos o más de estos aspectos se pueden combinar de diversas maneras. Por ejemplo, un aparato se puede implementar o un procedimiento se puede llevar a la práctica usando un número cualquiera de los aspectos expuestos en el presente documento. Además, un aparato de este tipo se puede implementar o un procedimiento de este tipo se puede llevar a la práctica usando otra estructura, funcionalidad, o estructura y funcionalidad, además de, o diferente de, uno o más de los aspectos expuestos en el presente documento. Como ejemplo de algunos de los conceptos anteriores, en algunos aspectos pueden establecerse canales concurrentes en base a frecuencias de repetición de impulsos. En algunos aspectos pueden establecerse canales concurrentes en base a los desfases o la posición de los impulsos. En algunos aspectos pueden establecerse canales concurrentes en base a secuencias de salto de tiempo.

Los expertos en la técnica entenderán que la información y las señales se pueden representar usando cualquiera de una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, las instrucciones, los comandos, la información, las señales, los bits, los símbolos y los chips que se pueden haber mencionado a lo largo de la descripción anterior se pueden representar mediante tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticos, o cualquier combinación de los mismos.

Los expertos en la técnica apreciarán además que los diversos bloques lógicos, módulos, procesadores, medios, circuitos y etapas de algoritmo ilustrativos, descritos en relación con los aspectos divulgados en el presente documento pueden implementarse como hardware electrónico (por ejemplo, una implementación digital, una implementación analógica o una combinación de las dos que pueda diseñarse usando codificación de fuente o alguna otra técnica), como diversas formas de código de programa o de diseño que incluyan instrucciones (que pueden denominarse en el presente documento, por comodidad, "software" o "módulo de software") o como combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, en lo que antecede se han descrito, de forma genérica, diversos componentes, bloques, módulos, circuitos y etapas ilustrativos desde el punto de vista de su funcionalidad. Que dicha funcionalidad se implemente como hardware o software depende de las restricciones particulares de aplicación y de diseño impuestas al sistema global. Los expertos en la técnica pueden implementar la funcionalidad descrita de formas variadas para cada aplicación particular, pero no se debe interpretar que dichas decisiones de implementación suponen apartarse del alcance de la presente divulgación.

Además, los diversos bloques lógicos, módulos y circuitos ilustrativos descritos en relación con los aspectos divulgados en el presente documento se pueden implementar dentro de, o realizar mediante, un circuito integrado ("IC"), un terminal de acceso o un punto de acceso. El IC puede comprender un procesador de propósito general, un procesador de señales digitales (DSP), un circuito integrado específico de la aplicación (ASIC), una matriz de puertas programables in situ (FPGA) u otro dispositivo lógico programable, lógica discreta de puertas o transistores, componentes de hardware discretos, componentes eléctricos, componentes ópticos, componentes mecánicos o cualquier combinación de los mismos diseñada para realizar las funciones que se describen en el presente documento, y puede ejecutar códigos o instrucciones que residen dentro del IC, fuera del IC o ambas cosas. Un procesador de propósito general puede ser un microprocesador pero, como alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también se puede implementar como una combinación de dispositivos informáticos, por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP, o cualquier otra configuración de este tipo.

Se debe entender que cualquier orden o jerarquía de etapas específicos en cualquier proceso divulgado es un ejemplo de enfoque de muestra. En base a las preferencias de diseño, se entiende que el orden o jerarquía de etapas específicos en los procesos se pueden reorganizar sin apartarse del alcance de la presente divulgación. Las reivindicaciones de procedimiento adjuntas presentan elementos de las diversas etapas en un orden de muestra y no se pretenden limitar al orden o la jerarquía específicos presentados.

Las etapas de un procedimiento o algoritmo descrito en relación con los aspectos divulgados en el presente documento se pueden materializar directamente en hardware, en un módulo de software ejecutado por un procesador o en una combinación de ambas cosas. Un módulo de software (por ejemplo, que incluye instrucciones ejecutables y datos relacionados) y otros datos pueden residir en una memoria de datos, tal como una memoria RAM, una memoria flash, una memoria ROM, una memoria EPROM, una memoria EEPROM, registros, un disco duro, un disco extraíble, un CD-ROM o cualquier otra forma de medio de almacenamiento legible por ordenador conocido en la técnica. Un medio de almacenamiento de muestra se puede acoplar a una máquina tal como, por ejemplo, un ordenador/procesador (que en el presente documento se puede denominar, por conveniencia, un "procesador") de modo que el procesador pueda leer información (por ejemplo, código) del y escribir información en el medio de almacenamiento. Un medio de almacenamiento de muestra puede estar integrado en el procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un equipo de usuario. De forma alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un equipo de usuario. Además, en algunos aspectos, cualquier producto de programa informático adecuado puede comprender un medio legible por ordenador que comprende códigos relacionados con uno o más de los aspectos de la divulgación. En algunos aspectos, un producto de programa informático puede incluir materiales de embalaje.

Aunque la invención se ha descrito en relación con diversos aspectos, se entenderá que la invención admite otras modificaciones. Esta solicitud está destinada a cubrir cualquier variación, uso o adaptación de la invención siguiendo, en general, los principios de la invención, e incluyendo dichas desviaciones de la presente divulgación que estén dentro de la práctica conocida y habitual dentro de la técnica a la que pertenece la invención.

Claims (9)

REIVINDICACIONES

1. Un procedimiento de un equipo de usuario, denominado también en lo sucesivo UE, comprendiendo el procedimiento:

recibir una configuración de un recurso de enlace ascendente preconfigurado, denominado también en lo sucesivo PUR, cuando el UE está en un estado RRC_CONNECTED (1805);

entrar en un estado RRC_IDLE desde el estado RRC_COn Ne CTED (1810);

realizar una primera transmisión usando el PUR cuando el UE está en el estado RRC_IDLE (1815);

entrar de nuevo al estado RRC_CONNECTED desde el estado RRC_IDLE (1820);

suspender la configuración cuando el UE está de nuevo en el estado RRC_CONNECTED, en el que el UE no realiza transmisiones usando el PUR si la configuración está suspendida (1825);

reanudar la configuración cuando el UE vuelve a entrar al estado RRC_IDLE desde el estado RRC_CONNECTED (1830), y

realizar una segunda transmisión usando el PUR cuando el UE está de nuevo en el estado RRC_IDLE (1835), estando caracterizado el procedimiento por que además comprende liberar la configuración si el UE recibe una indicación en una información del sistema que indica que una célula de servicio no admite el PUR o que indica que el soporte del PUR está desactivado.

2. El procedimiento de la reivindicación 1, en el que el UE mantiene la configuración cuando la configuración está suspendida.

3. El procedimiento de la reivindicación 1 o 2, que comprende además:

liberar la configuración en base a una indicación en un mensaje RRCConnectionRelease o un mensaje RRCEarlyDataComplete.

4. El procedimiento de una cualquiera de las reivindicaciones 1 a 3, que comprende además:

liberar la configuración en base a una indicación en un mensaje de radiolocalización o una señalización de activación.

5. El procedimiento de una cualquiera de las reivindicaciones 1 a 4, en el que el UE no realiza transmisiones usando el PUR si se libera la configuración.

6. El procedimiento de una cualquiera de las reivindicaciones 1 a 5, en el que el UE omite las transmisiones usando el PUR si el UE no tiene datos disponibles para las transmisiones.

7. El procedimiento de una cualquiera de las reivindicaciones 1 a 6, en el que la configuración se proporciona al UE en una señalización dedicada.

8. El procedimiento de una cualquiera de las reivindicaciones 1 a 7, en el que la configuración incluye al menos uno de los siguientes parámetros: un tamaño de bloque de transporte, un esquema de modulación y codificación, una periodicidad en el dominio de tiempo, un desfase en el dominio de tiempo, una ubicación/desfase en el dominio de frecuencia, un umbral de potencia de recepción de señal de referencia, denominada también en lo sucesivo RSRP, un número de repeticiones para cada intento de una transmisión usando el PUR, una potencia de transmisión para cada intento de transmisión usando el PUR y un etapa de aumento de potencia.

9. Un equipo de usuario, denominado también en lo sucesivo UE, comprendiendo el UE:

un circuito de control (306);

un procesador (308) instalado en el circuito de control (306); y

una memoria (310) instalada en el circuito de control (306) y acoplada al procesador (308);

caracterizado por que el procesador (308) está configurado para ejecutar un código de programa (312) almacenado en la memoria (310) para realizar las etapas de procedimiento definidas en una cualquiera de las reivindicaciones anteriores.