ES2983981T3 - Método y aparato para controlar conmutación involuntaria de parte de ancho de banda, BWP, en un sistema de comunicación inalámbrica - Google Patents

Método y aparato para controlar conmutación involuntaria de parte de ancho de banda, BWP, en un sistema de comunicación inalámbrica Download PDF

Info

Publication number
ES2983981T3
ES2983981T3 ES22194432T ES22194432T ES2983981T3 ES 2983981 T3 ES2983981 T3 ES 2983981T3 ES 22194432 T ES22194432 T ES 22194432T ES 22194432 T ES22194432 T ES 22194432T ES 2983981 T3 ES2983981 T3 ES 2983981T3
Authority
ES
Spain
Prior art keywords
bwp
drx
rrc
pdcch
active
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES22194432T
Other languages
English (en)
Inventor
I-Jen Chen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Asustek Computer Inc
Original Assignee
Asustek Computer Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Asustek Computer Inc filed Critical Asustek Computer Inc
Application granted granted Critical
Publication of ES2983981T3 publication Critical patent/ES2983981T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0091—Signalling for the administration of the divided path, e.g. signalling of configuration information
    • H04L5/0096—Indication of changes in allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0453—Resources in frequency domain, e.g. a carrier in FDMA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/25—Maintenance of established connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H04W76/38—Connection release triggered by timers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Se proporcionan métodos y aparatos para evitar la transición de estado de UE no deseada, y se reduce el riesgo de pérdida de paquetes debido a la transición de estado de UE no deseada. Los métodos y aparatos también se proporcionan para evitar la conmutación de BWP no deseada, y se reduce el riesgo de pérdida de paquetes debido a la conmutación de BWP no deseada. Un dispositivo, por ejemplo, UE, se configura mediante un nodo de red a través de una señalización con una funcionalidad, en donde la funcionalidad está asociada con un temporizador (1012). El dispositivo recibe un paquete, en donde el paquete contiene una o más cargas útiles, y la carga útil se asigna a un canal lógico, en donde el canal lógico se utiliza para el servicio de multidifusión y/o difusión (1014), y el dispositivo inicia o reinicia el temporizador (1016). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método y aparato para controlar conmutación involuntaria de parte de ancho de banda, BWP, en un sistema de comunicación inalámbrica
Esta divulgación se relaciona generalmente con redes de comunicación inalámbrica y, más particularmente, con un método y aparato en un sistema de comunicación inalámbrica para evitar una transición de estado de Equipo de Usuario (UE) involuntaria y/o una conmutación involuntaria de Parte de Ancho de Banda (BWP).
Con el rápido aumento en la demanda para comunicación de grandes cantidades de datos hacia y desde dispositivos de comunicación móviles, 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). Tal comunicación por paquetes de datos de IP puede proporcionar a los usuarios de dispositivos de comunicación móviles servicios de comunicación de voz sobre IP, multimedia, multidifusión y bajo demanda.
Una estructura de red de ejemplo es una Red de Acceso de Radio Terrestre Universal Evolucionada (E-UTRAN). El sistema de E-UTRAN puede proporcionar un alto rendimiento de datos con el fin de realizar los servicios multimedia y de voz sobre IP anotados anteriormente. Una nueva tecnología de radio para la próxima generación (por ejemplo, 5G) está siendo discutida actualmente por la organización de estándares de 3GPP. Por consiguiente, están siendo presentados y considerados cambios al cuerpo actual del estándar de 3GPP para evolucionar y finalizar el estándar de 3GPP.
El documento US 2019/0289504 A1 divulga un método de reselección de celdas para un terminal que no soporta la reselección de celdas con base en prioridad de frecuencia.
El documento US 2019/0132110 A1 divulga una configuración y operación de parte de ancho de banda.
El documento US 2020/0059991 A1 divulga métodos y dispositivos para prevenir el modo inactivo inadvertido para un UE en conectividad de múltiples nodos con un nodo maestro y al menos un nodo secundario.
Los documentos EP 4 152781 A1 y WO 2022/001495 A1, que son la técnica anterior bajo el Art. 54(3) EPC, divulgan un método de soporte de movilidad para servicio de multidifusión así como un método de conmutación de estado, respectivamente.
Resumen
La presente invención está prevista para evitar la conmutación involuntaria de BWP, dando como resultado la reducción del riesgo de pérdida de paquetes debido a una conmutación involuntaria de BWP. Un método y un dispositivo de acuerdo con la invención se definen en las reivindicaciones independientes. Las reivindicaciones dependientes definen realizaciones preferidas de las mismas.
En diversas realizaciones, un dispositivo (por ejemplo, UE) está configurado con al menos una celda de servicio activada, en donde la celda de servicio activada está configurada con una o múltiples BWPs. El dispositivo monitoriza el Canal de Control de Enlace Descendente Físico (PDCCH) en una BWP activa, en donde la BWP activa es una de la BWP configurada, y la BWP activa incluye una BWP de DL activa, en donde la BWP de DL activa está asociada con un temporizador. El dispositivo recibe una información desde el PDCCH, en donde la recepción desde el PDCCH se dirige a un<r>N<t>I de grupo común (GC-RNTI), y la información indica la asignación de enlace descendente o concesión de enlace ascendente en la BWP activa. El dispositivo inicia o reinicia el temporizador asociado con la BWP de DL activa con respecto a la recepción de la asignación de enlace descendente, donde el temporizador es un bwp-InactivityTimer.
Breve descripción de los dibujos
La figura 1 muestra un diagrama de un sistema de comunicación inalámbrica.
La figura 2 es un diagrama de bloques de un sistema transmisor (también conocido como red de acceso) y un sistema receptor (también conocido como equipo de usuario o UE).
La figura 3 es un diagrama de bloques funcional de un dispositivo de comunicación, de acuerdo con realizaciones de la presente invención.
La figura 4 es un diagrama de bloques funcional del código de programa de la figura 3.
La figura 5 es una reproducción de la figura 4.2.2-1 desde 3GPP TS 38.321 V16.3.0, que muestra una visión general de estructura de MAC, ilustrando una posible estructura de la entidad de MAC cuando SCG no está configurado y para cada entidad de MAC durante el traspaso DAPS.
La figura 6 es una reproducción de la figura 4.2.2-2 desde 3GPP TS 38.321 V16.3.0, que muestra una visión general de estructura de MAC con dos entidades de MAC, ilustrando una posible estructura para entidades de MAC cuando se configuran MCG y SCG.
La figura 7 es una reproducción de la figura 4.2.1-1 desde 3GPP TS 38.331 V16.3.1, que ilustra una visión general de la máquina de estados de RRC de UE y transiciones de estado en NR, donde un UE tiene solo un RRC a la vez.
La figura 8 es una reproducción de la figura 5.3.8.1-1 desde 3GPP TS 38.331 V16.3.1, que ilustra la liberación exitosa de conexión de RRC.
La figura 9 es un diagrama de flujo que muestra un método para evitar una transición de estado de UE involuntaria, con el UE, configurado con un dataInactivityTimer, recibiendo una SDU de MAC para un canal lógico de tráfico de MBS, e iniciando o reiniciando el temporizador.
La figura 10 es un diagrama de flujo que muestra un método para evitar una transición de estado de UE involuntaria, con el UE, configurado con un dataInactivityTimer, recibiendo una SDU de MAC para un canal lógico de control de MBS, e iniciando o reiniciando el temporizador.
La figura 11 es un diagrama de flujo que muestra un método para evitar una transición de estado de UE involuntaria, con el UE, configurado con un dataInactivityTimer, recibiendo una señalización para iniciar una sesión de MBS, y aplicando el valor "infinito" al temporizador.
La figura 12 es un diagrama de flujo que muestra un método para evitar una transición de estado de UE involuntaria, con el UE, configurado con monitorización de inactividad de Datos, recibiendo una señalización para iniciar una sesión de MBS, y retirando la configuración de funcionalidad de monitorización de inactividad de Datos.
La figura 13 es un diagrama de flujo que muestra un método para evitar la conmutación involuntaria de BWP, con el UE monitorizando el PDCCH en una Celda de Servicio activada configurada con bwp-InactivityTimer, con el PDCCH dirigido al GC-RNTI indicando que se recibe la asignación de enlace descendente o concesión de enlace ascendente en la BWP activa, e iniciando o reiniciando el temporizador asociado con la BWP de DL activa, de acuerdo con realizaciones de la presente invención.
Descripción detallada
Las realizaciones de las figuras 3 y 13 y su texto asociado son parte de la presente invención y están cubiertas por las reivindicaciones. Todas las otras realizaciones que se divulgan a continuación son simplemente explicativas y no son parte de la invención.
La invención descrita en este documento se puede aplicar a o implementar en sistemas y dispositivos de comunicación inalámbrica de ejemplo que se describen a continuación. Además, la invención se describe principalmente en el contexto del modelo de referencia de arquitectura de 3GPP. Sin embargo, se entiende que con la información divulgada, un experto en la técnica podría adaptar fácilmente para uso e implementar aspectos de la invención en una arquitectura de red de 3GPP2 así como en otras arquitecturas de red.
Los sistemas y dispositivos de comunicación inalámbrica de ejemplo que se describen a continuación emplean un sistema de comunicación inalámbrica, que soporta un servicio de radiodifusión. Los sistemas de comunicación inalámbrica se despliegan ampliamente para proporcionar diversos tipos de comunicación tales como voz, datos, y así sucesivamente. 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 de frecuencia ortogonal (OFDMA), acceso inalámbrico de LTE (Evolución a Largo Plazo) de 3GPP, acceso inalámbrico de LTE-A (Evolución a Largo Plazo Avanzada) de 3GPP, UMB (Banda Ancha Ultra Móvil) de 3GPP2, WiMax, NR (nueva radio) de 3GPP, o algunas otras técnicas de modulación.
En particular, los dispositivos de sistemas de comunicación inalámbrica de ejemplo que se describen a continuación pueden diseñarse para soportar uno o más estándares tales como el estándar ofrecido por un consorcio denominado "Proyecto de Asociación de 3ra Generación" denominado en este documento como 3GPP, que incluye: TS 38.300 V16.4.0, "NR; NR and NG-RAN Overall Description; Stage 2"; TS 38.321 V16.3.0, "NR; Medium Access Control (MAC) protocol specification"; TS 38.331 V16.3.1, "NR; Radio Resource Control (RRC) Protocol specification"; RP-201038, (Ítem de Trabajo Revisado sobre Servicios de multidifusión<y radiodifusión de NR); R2-2008701, (Reporte de reunión de>3<g>P<p TSG RAN2#111-e); Borrador de Reporte>de Reunión RAN2112-e v2; reporte de Acta Final RAN1#102-e v100; reporte de Borrador de Actas RAN1#103-e v020; y R2-2102253, 38.300 Ejecutando CR para MBS en NR, CMCC.
La figura 1 muestra un sistema de comunicación inalámbrica de acceso múltiple de acuerdo con una realización de la invención. Una red de acceso 100 (AN) incluye múltiples grupos de antenas, uno que incluye 104 y 106, otro que incluye 108 y 110, y uno adicional que incluye 112 y 114. En la figura 1, solo se muestran dos antenas para cada grupo de antenas, sin embargo, se pueden utilizar más o menos antenas para cada grupo de antenas. El terminal de acceso (AT) 116 está en comunicación con las antenas 112 y 114, donde las antenas 112 y 114 transmiten información al terminal de acceso 116 a través del enlace directo 120 y reciben información desde AT 116 a través del enlace inverso 118. AT 122 está en comunicación con las antenas 106 y 108, donde las antenas 106 y 108 transmiten información al AT 122 a través del enlace directo 126 y reciben información desde el AT 122 a través del enlace inverso 124. En un sistema de FDD, los enlaces de comunicación 118, 120, 124 y 126 pueden usar diferentes frecuencias para comunicación. Por ejemplo, el enlace directo 120 puede usar una frecuencia diferente a la que se usa por el enlace inverso 118.
Cada grupo de antenas y/o el área en la cual están diseñadas para comunicarse a menudo se denomina como un sector de la red de acceso. En la realización, cada uno de los grupos 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 enlaces directos 120 y 126, las antenas transmisoras de red de acceso 100 pueden utilizar formación de haces con el fin de mejorar la relación de señal a ruido de enlaces directos para los diferentes terminales de acceso 116 y 122. También, una red de acceso que usa formación de haces para transmitir a terminales de acceso dispersos aleatoriamente a través de su cobertura normalmente causa menos interferencia a los terminales de acceso en celdas vecinas que una red de acceso que transmite a través de una única antena a todos sus terminales de acceso.
La AN puede ser una estación fija o estación base usada para comunicarse con los terminales y también puede denominarse como un punto de acceso, un Nodo B, una estación base, una estación base mejorada, un eNodoB, o alguna otra terminología. El AT también puede denominarse Equipo de Usuario (UE), un dispositivo de comunicación inalámbrica, terminal, terminal de acceso o alguna otra terminología.
La figura 2 es un diagrama de bloques simplificado de una 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 de MIMO 200. En el sistema transmisor 210, los datos de tráfico para un número de flujos de datos se proporcionan desde una fuente de datos 212 a un procesador de datos de transmisión (TX) 214.
Preferiblemente, cada flujo de datos se transmite a través de una antena de transmisión respectiva. El procesador de datos de TX 214 formatea, codifica, e intercala los datos de tráfico para cada flujo de datos con base en un esquema de codificación particular seleccionado para ese flujo de datos para proporcionar datos codificados.
Los datos codificados para cada flujo de datos pueden multiplexarse 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 puede usarse en el sistema receptor para estimar la respuesta de canal. Los datos piloto multiplexados y codificados para cada flujo de datos luego se modulan (por ejemplo, mapean por símbolos) con base en 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 tasa de datos, codificación, y modulación para cada flujo de datos pueden determinarse mediante instrucciones realizadas por el procesador 230.
Los símbolos de modulación para todos los flujos de datos luego se proporcionan a un procesador de MIMO de TX 220, que puede procesar además los símbolos de modulación (por ejemplo, para OFDM). El procesador de MIMO de TX 220 proporciona entonces Nt flujos de símbolos de modulación a Nt transmisores (TMTR) 222a hasta 222t. En ciertas realizaciones, el procesador de MIMO de TX 220 aplica pesos de formación de haces a los símbolos de los flujos de datos y a la antena desde la cual está siendo transmitido el símbolo.
Cada transmisor 222 recibe y procesa un flujo de símbolos respectivo para proporcionar una o más señales analógicas, y acondiciona además (por ejemplo, amplifica, filtra, y convierte de manera ascendente) las señales analógicas para proporcionar una señal modulada adecuada para la transmisión a través del canal de MIMO. Las N<t>señales moduladas desde los transmisores 222a hasta 222t se transmiten luego desde N<t>antenas 224a hasta 224t, respectivamente.
En el sistema receptor 250, las señales moduladas transmitidas son recibidas por N<r>antenas 252a hasta 252r y la señal recibida desde cada antena 252 se proporciona a un receptor respectivo (RCVR) 254a hasta 254r. Cada receptor 254 acondiciona (por ejemplo, filtra, amplifica, y convierte de manera descendente) una señal recibida respectiva, digitaliza la señal acondicionada para proporcionar muestras, y procesa además las muestras para proporcionar un flujo de símbolos "recibido" correspondiente.
Luego un procesador de datos de RX 260 recibe y procesa los N<r>flujos de símbolos recibidos desde N<r>receptores 254 con base en una técnica de procesamiento de receptor particular para proporcionar N<t>flujos de símbolos "detectados". El procesador de datos de RX 260 luego desmodula, desintercala, y decodifica cada flujo de símbolos detectado para recuperar los datos de tráfico para el flujo de datos. El procesamiento por el procesador de datos de RX 260 es complementario al que se realiza por el procesador de MIMO de TX 220 y procesador de datos de TX 214 en el sistema transmisor 210.
Un procesador 270 determina periódicamente qué matriz de precodificación usar (se discute a continuación). El procesador 270 formula un mensaje de enlace inverso que comprende una porción de índice de matriz y una porción 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. El mensaje de enlace inverso es luego procesado 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, modulados por un modulador 280, condicionados por los transmisores 254a hasta 254r, y transmitidos de vuelta al sistema transmisor 210.
En el sistema transmisor 210, las señales moduladas desde el sistema receptor 250 son recibidas por antenas 224, acondicionadas por receptores 222, desmoduladas por un desmodulador 240, y procesadas por un procesador de datos de RX 242 para extraer el mensaje de enlace de reserva transmitido por el sistema receptor 250. El procesador 230 luego determina qué matriz de precodificación usar para determinar los pesos de formación de haces luego procesa el mensaje extraído.
La memoria 232 se puede usar para almacenar temporalmente algunos datos almacenados en búfer/computacionales desde 240 o 242 hasta el procesador 230, almacenar algunos datos almacenados en búfer desde 212, o almacenar algunos códigos de programa específicos. Y la Memoria 272 se puede usar para almacenar temporalmente algunos datos almacenados en búfer/computacionales desde 260 hasta el Procesador 270, almacenar algunos datos almacenados en búfer desde 236, o almacenar algunos códigos de programa específicos.
Volviendo a la figura 3, esta figura muestra un diagrama de bloques funcional simplificado alternativo de un dispositivo de comunicación de acuerdo con una 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 UEs (o ATs) 116 y 122 en la figura 1, y el sistema de comunicación inalámbrica es preferiblemente el sistema de 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 de esa manera 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 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 señales recibidas al circuito de control 306, y emitiendo señales generadas por el circuito de control 306 de manera inalámbrica.
La figura 4 es un diagrama de bloques simplificado del código de programa 312 mostrado en la figura 3 de acuerdo con una realización de la invención. En esta 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á acoplado a una porción de Capa 1406. La porción de Capa 3402 generalmente realiza el control de recursos de radio. La porción de Capa 2 404 generalmente realiza el control de enlace. La porción de Capa 1 406 generalmente realiza conexiones físicas.
Para sistemas de LTE, LTE-A, o NR, la porción de Capa 2404 puede incluir una capa de Control de Enlace de Radio (RLC) y una capa de Control de Acceso al Medio (MAC). La porción de Capa 3402 puede incluir una capa de Control de Recursos de Radio (RRC).
Cualesquiera dos o más de dos de los siguientes párrafos, (sub)viñetas, puntos, acciones, o reivindicaciones descritos en cada invención pueden combinarse de manera lógica, razonable, y adecuada para formar un método específico.
Cualquier oración, párrafo, (sub)viñeta, punto, acción, o reivindicación descrita en cada una de la siguiente invención se puede implementar de manera independiente y por separado para formar un método específico. La dependencia, por ejemplo, "con base en", "más específicamente", etc., en la siguiente invención es solo una posible realización que no restringiría el método específico.
El ítem de trabajo sobre Servicios de Multidifusión y Radiodifusión (MBS) de NR se describe en [4]. A continuación se citan varias partes a partir de [4]:
<* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *>Inicio de Cita [4]
************************************
3 Justificación
Entre RAN #78 y RAN #80 tuvo lugar una discusión sobre la evolución de Radiodifusión 5G en RAN, resumiendo los atributos técnicos de la "radiodifusión terrestre" y "multidifusión en modo mixto", lo que llevó a una recomendación de proceder con un estudio sobre la "radiodifusión terrestre" en Rel-16, mientras que se deja la estandarización de multidifusión/radiodifusión en "modo mixto" para futuras entregas. La LTE Rel-16 WI en EN-TV mejorado fue aprobado en RAN #83, con el objetivo de la introducción de nuevas estructuras de marco con nuevos CPs y los diseños relacionados. Los principales atributos de "radiodifusión terrestre" son áreas de transmisión grandes y estática de solo radiodifusión, solo DL que típicamente se logran con despliegues de Torre Alta de Alta Potencia.
No se especifica soporte con funciones de radiodifusión/multidifusión en las dos primeras entregas de NR, es decir Rel-15 y Rel-16. No obstante, hay casos de uso importantes para los cuales la radiodifusión/multidifusión podría proporcionar mejoras sustanciales, especialmente con respecto a la eficiencia de sistema y experiencia de usuario.
En SP-190625 ha sido aprobado un ítem de estudio sobre las mejoras Arquitectónicas para servicios de multidifusión-radiodifusión 5G y está en curso.
El objetivo A del SA2 SI es sobre Habilitar servicios de MBS generales a través de 5GS y los casos de uso identificados que podrían beneficiarse de esta característica incluyen (pero no se limitan a) seguridad pública y misión crítica, aplicaciones V2X, suministro de multidifusión IPv4/IPv6 transparente, IPTV, suministro de software a través de aplicaciones inalámbricas, de comunicaciones grupales e IoT.
Este WI tiene como objetivo proporcionar el soporte en RAN para el Objetivo A, de manera consistente con TR 23.757. El soporte de Objetivo B (por ejemplo, TV lineal, en Vivo, TV inteligente, y contenido gestionado y de OTT, servicios de radio) no está en el alcance de este WI, es decir, no se debe diseñar la parte de RAN del sistema para cumplir el Objetivo B, sin embargo es posible que las soluciones diseñadas para el Objetivo A permitirían una utilización eficiente de recursos de radio para los servicios soportados en el Objetivo B, y el objetivo es compatibilidad hacia adelante hacia el Objetivo B si fuera posible.
En particular, para la seguridad pública y misión crítica, se debe tener en cuenta tanto como sea posible los objetivos de diseño identificados durante el estudio SA6 sobre servicios Mejorados de Misión Crítica (MC) a través del sistema de multidifusión-radiodifusión 5G (SP-190726) como se captura en TR 23.774 y requisitos identificados por SA1 en TS22.261, cláusula 6.13.2, siempre que la complejidad de sistema de RAN sea manejable.
4 Objetivo
4.1 Objetivo del SI o parte central WI o parte de prueba WI
El conjunto de objetivos incluye:
- Especificar funciones básicas de RAN para radiodifusión/multidifusión para UEs en estado RRC_CONNECTED [RAN1, RAN2, RAN3]:
° Especificar un mecanismo de programación de grupo para permitir que los UEs reciban el servicio de Radiodifusión/Multidifusión [RAN1, RAN2]
■ Este objetivo incluye especificar las mejoras necesarias que se requieren para permitir la operación simultánea con recepción unidifusión.
° Especificar el soporte para el cambio dinámico del suministro de servicio de Radiodifusión/Multidifusión entre multidifusión (PTM) y unidifusión (PTP) con continuidad de servicio para un UE dado [RAN2, RAN3] ° Especificar soporte para movilidad básica con continuidad del servicio [RAN2, RAN3]
° Suponiendo que la función de coordinación necesaria (como funciones alojadas por MCE, si hay) reside en el gNB-CU, especificar los cambios requeridos en la arquitectura e interfaces de RAN, considerando los resultados de SA2 SI en Radiodifusión/Multidifusión (SP-190625) [RAN3]
° Especificar los cambios requeridos para mejorar fiabilidad del servicio de Radiodifusión/Multidifusión, por ejemplo, mediante retroalimentación de UL. El nivel de fiabilidad debe basarse en los requisitos de la aplicación/servicio proporcionado [RAN1, RAN2]
° Estudiar el soporte para el control dinámico del área de transmisión Radiodifusión/Multidifusión dentro de un gNB-DU y especificar qué se necesita para habilitarlo, si es necesario [RAN2, RAN3]
- Especificar funciones básicas de RAN para radiodifusión/multidifusión para UEs en estados de RRCJDLE/RRCJNACTIVE [RAN2, RAN1]:
° Especificar los cambios requeridos para permitir la recepción de transmisiones Punto a Multipunto por los UEs en estados de RRCJDLE/RRCJNACTIVE, con el objetivo de mantener la máxima similitud entre estado RRC_CONNECTED y estado RRCJDLE/RRCJNACTIVE para la configuración de la recepción PTM [RAN2, RAN1].
Nota: la posibilidad de recibir transmisiones de Punto a Multipunto por UEs en estados de RRCJDLE/RRCJNACTIVE, sin la necesidad de que esos UEs obtengan de antemano la configuración del portador PTM que transporta el servicio de Radiodifusión/Multidifusión mientras están en estado RRC CONNECTED, está sujeta a verificación de supuestos de suscripción y autorización de servicio durante el WI. Restricciones y supuestos:
Arquitectura: es la de la figura 4.1-1 en TR 23.757 v0.2.0: Arquitectura de MBS de alto nivel, con la restricción adicional de que solo NR en NG-RAN (es decir conectado a 5GC) se considera como RAT. Por consiguiente, además de en NR SA, no debería haber razones que impidan el uso de la característica estandarizada en este WI en caso de configuraciones MR DC en el MCG cuando el MN es un gNB (NE-DC, NR DC).
Capa física: limitar el alcance de este WI a las numerologías, canales físicos (PDCCH/PDSCH) y señales actuales de Rel-15.
FR2: asumir que no hay problemas para proporcionar transmisiones de Multidifusión/Radiodifusión en FR2. Si se necesita cualquier mejora se debe tratar con menor prioridad en comparación con el conjunto mínimo de objetivos anteriores.
Con el fin de facilitar la implementación y despliegue de la característica, el impacto global de implementación debe ser limitado, y la complejidad de u E debe minimizarse (por ejemplo, debe evitarse el impacto de hardware de dispositivo).
SFN proporciona suministro sincronizado de paquetes de plano de usuario por el aire desde diferentes celdas. En este WI no se proporciona soporte estandarizado específicamente para SFN. Cualquier operación SFN es transparente para el U<e>, y cualquier sincronización relacionada se deja a la implementación de red. Se reutiliza la estructura QCL existente (con base en SSB y CSI-RS).
La asignación flexible de recursos entre los servicios de Unidifusión y Radiodifusión/Multidifusión debería ser posible en este WI, pero la asignación de recursos de hasta el 100 % para Radiodifusión/Multidifusión no es un requisito garantizado en este WI.
En este WI no se proporciona soporte del modo Gratuito para aire/recibir solamente.
Cualquier decisión de diseño tomada para este WI en la Entrega 17 no evitará la introducción de las siguientes características en Entregas futuras:
• Soporte estandarizado de SFN en múltiples celdas por encima del nivel de gNB-DU;
• Soporte de modo Gratuito para aire/recibir solamente
• Asignación de recursos hasta 100% al servicio de Radiodifusión/Multidifusión.
Nota: se espera colaboración con SA2 a su debido tiempo.
<* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *>F<I>in de Cita [4]
*************************************
En NR, los procedimientos relacionados con monitorizar PDCCH en P(S)Celda y/o SCelda para programar PDSCH y/o PUSCH en P(S)Celda y/o SCelda se especifican en TS 38.321 [2], y se citan a continuación como un punto de partida para mejora adicional.
<* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *>Inicio de Cita [2]
************************************
3.1 Definiciones
Para los propósitos del presente documento, se aplican los términos y definiciones dados en TR 21.905 [1] y lo siguiente. Un término definido en el presente documento tiene prioridad sobre la definición del mismo término, si hay, en TR21.905 [1].
BWP inactiva: La BWP inactiva es una de las BWPs de enlace descendente configuradas por la red a través de señalización de RRC dedicada. En la BWP inactiva, el UE deja de monitorizar el PDCCH en/para la SCelda, pero continúa realizando mediciones de CSI, Control Automático de Ganancia (AGC) y gestión de haz, si está configurado.
Grupo de DRX: Un grupo de Celdas de Servicio que está configurado por RRC y que tienen el mismo Tiempo Activo de DRX.
Información de HARQ: Información de HARQ para transmisiones de DL-SCH, UL-SCH, o SL-SCH consiste en un Nuevo Indicador de Datos (NDI), tamaño de Bloque de Transporte (TBS), Versión de Redundancia (RV), e ID de proceso de HARQ.
Donante IAB: gNB que proporciona acceso a red a los UEs a través de una red de enlaces de retorno y acceso.
Nodo IAB: nodo de RAN que soporta enlaces de acceso de NR a UEs y enlaces de retorno de NR a nodos progenitores y nodos hijo.
Escuchar Antes de Hablar: Un procedimiento de acuerdo con el cual no se realizan transmisiones si el canal se identifica como que está ocupado, véase TS 37.213 [18].
Msg3: Mensaje transmitido en UL-SCH que contiene una SDU de CE de MAC de C-RNTI o CCCH, enviado desde la capa superior y asociado con la Identidad de Resolución de Competencia del UE, como parte de un procedimiento de Acceso Aleatorio.
Enlace de retorno de NR: enlace de NR usado para el retorno entre un nodo IAB y un donante IAB, y entre nodos IAB en caso de un retorno de múltiples saltos.
Comunicación de enlace lateral de NR: funcionalidad AS que permite al menos la Comunicación V2X como se define en TS 23.287 [19], entre dos o más UEs cercanos, usando tecnología de NR pero sin atravesar ningún nodo de red.
Ocasión de PDCCH: Una duración de tiempo (es decir uno o un número consecutivo de símbolos) durante la cual la entidad de MAC está configurada para monitorizar el PDCCH.
Celda de servicio: Una PCelda, una PSCelda, o una SCelda en TS 38.331 [5].
Información de transmisión de enlace lateral: Información de transmisión de enlace lateral incluida en un SCI para una transmisión de SL-SCH como se especifica en la cláusula 8.3 y 8.4 de TS 38.212 [9] consiste en información de HARQ de Enlace lateral que incluye NDI, RV, ID de proceso de Enlace lateral, indicador de retroalimentación de HARQ habilitado/deshabilitado, información de identificación de Enlace lateral que incluye indicador de tipo de difusión, ID de Capa 1 de Origen e ID de Capa 1 de Destino, y otra información de Enlace lateral que incluye solicitud de CSI, una prioridad, un requisito de rango de comunicación e ID de Zona.
Celda Especial: Para operación de Conectividad Dual el término Celda Especial se refiere a la PCelda del MCG o la PSCelda del SCG dependiendo de si la entidad de MAC está asociada al MCG o al SCG, respectivamente. De lo contrario el término Celda Especial se refiere a la PCelda. Una Celda Especial soporta transmisión de PUCCH y Acceso Aleatorio basado en competencia, y siempre está activada.
Grupo de Avance de Temporización: Un grupo de Celdas de Servicio que está configurado por RRC y que, para las celdas con un UL configurado, usa la misma celda de referencia de temporización y el mismo valor de Avance de Temporización. Un Grupo de Avance de Temporización que contiene la SpCelda de una entidad de MAC se denomina como Grupo de Avance de Temporización Primario (PTAG), mientras que el término Grupo de Avance de Temporización Secundario (STAG) se refiere a otros TAGs.
Comunicación de enlace lateral V2X: funcionalidad AS que permite la comunicación V2X como se define en TS 23.285 [20], entre UEs cercanos, usando tecnología de E-UTRA pero sin atravesar ningún nodo de red. NOTA: Un temporizador está funcionando una vez que se inicia, hasta que se detiene o hasta que expira; de lo contrario no se está funcionando. Se puede iniciar un temporizador si no está funcionando o reiniciarse si está funcionando. Un Temporizador siempre se inicia o reinicia desde su valor inicial. La duración de un temporizador no se actualiza hasta que se detiene o expira (por ejemplo, debido a la conmutación de BWP). Cuando la entidad de MAC aplica un valor cero para un temporizador, el temporizador se iniciará y expirará inmediatamente a menos que se establezca explícitamente otra cosa.
************************************Siguiente Cita [2]
************************************
4.2 Arquitectura de MAC
4.2.1 General
Esta cláusula describe un modelo del MAC es decir no especifica ni restringe implementaciones.
RRC tiene el control de la configuración de MAC.
4.2.2 Entidades de MAC
La entidad de MAC del UE maneja los siguientes canales de transporte:
- Canal de radiodifusión (BCH);
- Canales Compartidos de Enlace Descendente (DL-SCH);
- Canal de Radiolocalización (PCH);
- Canales Compartidos de Enlace Ascendente (UL-SCH);
- Canales de Acceso Aleatorio (RACH).
Cuando el UE está configurado con SCG, se configuran dos entidades de MAC para el UE: una para el MCG y otra para el SCG.
Cuando el UE está configurado con traspaso DAPS, dos entidades de MAC se usan por el UE: una para la celda de origen (entidad de MAC de origen) y otra para la celda objetivo (entidad de MAC objetivo).
Las funciones de las diferentes entidades de MAC en el UE operan de manera independiente a menos que se especifique otra cosa. Los temporizadores y parámetros usados en cada entidad de MAC se configuran de manera independiente a menos que se especifique otra cosa. Las Celdas de Servicio, C-RNTI, portadores de radio, canales lógicos, entidades de capa superior e inferior, LCGs, y entidades de HARQ consideradas por cada entidad de MAC se refieren a aquellas mapeadas a esa entidad de MAC a menos que se especifique otra cosa.
Si la entidad de MAC está configurada con una o más SCeldas, hay múltiples DL-SCH y puede haber múltiples UL-SCH así como múltiples RACH por entidad de MAC; un DL-<s>C<h>, un UL-SCH, y un RACH en la SpCelda, un DL-SCH, cero o un UL-SCH y cero o un RACH para cada SCelda.
Si la entidad de MAC no está configurada con ninguna SCelda, hay un DL-SCH, un UL-SCH, y un RACH por entidad de MAC.
La figura 5 es una reproducción de la figura 4.2.2-1 desde 3GPP TS 38.321 V16.3.0, que muestra una visión general de estructura de MAC, ilustrando una posible estructura de la entidad de MAC cuando SCG no está configurado y para cada entidad de MAC durante el traspaso DAPS.
La figura 6 es una reproducción de la figura 4.2.2-2 desde 3GPP TS 38.321 V16.3.0, que muestra visión general de estructura de<m>A<c>con dos entidades de MAC, ilustrando una posible estructura para entidades de MAC cuando se configuran MCG y SCG.
************************************Siguiente Cita [2]
************************************
4.5 Estructura de canal
4.5.1 General
La subcapa de MAC opera en los canales definidos a continuación; canales de transporte son SAPs entre MAC y la Capa 1, canales lógicos son SAPs entre MAC y RLC.
4.5.2 Canales de transporte
La subcapa de MAC usa los canales de transporte enumerados en la Tabla 4.5.2-1 a continuación.
Tabla 4.5.2-1: Canales de transporte usados por MAC
4.5.3 Canales lógicos
La subcapa de MAC proporciona servicios de transferencia de datos en canales lógicos. Para alojar diferentes tipos de servicios de transferencia de datos, se definen múltiples tipos de canales lógicos es decir cada uno soportando transferencia de un tipo particular de información.
Cada tipo de canal lógico se define por el tipo de información que se transfiere.
La subcapa de MAC proporciona los canales de control y tráfico enumerados en la Tabla 4.5.3-1 a continuación.
Tabla 4.5.3-1: Canales lógicos proporcionados por MAC.
4.5.4 Mapeo de canales de transporte a canales lógicos
4.5.4.1 General
La entidad de MAC es responsable de mapear canales lógicos en canales de transporte. Este mapeo depende de la multiplexación que está configurada por RRC.
4.5.4.2 Mapeo de enlace ascendente
Los canales lógicos de enlace ascendente se pueden mapear como se describe en la Tabla 4.5.4.2-1.
Tabla 4.5.4.2-1: Mapeo de canales de enlace ascendente
4.5.4.3 Mapeo de enlace descendente
Los canales lógicos de enlace descendente se pueden mapear como se describe en la Tabla 4.5.4.3-1.
Tabla 4.5.4.3-1: Mapeo de canales de enlace descendente
************************************Siguiente Cita [2]
************************************
5.3 Transferencia de datos de DL-SCH
5.3.1 Recepción de asignación de DL
Las asignaciones de enlace descendente recibidas en el PDCCH tanto indican que hay una transmisión en un DL-SCH para una entidad de MAC particular como proporcionan la información de HARQ relevante.
Cuando la entidad de MAC tiene un C-RNTI, C-RNTI Temporal, o CS-RNTI, la entidad de MAC deberá para cada ocasión de PDCCH durante la cual monitoriza el PDCCH y para cada Celda de Servicio:
1> si se ha recibido una asignación de enlace descendente para esta ocasión de PDCCH y esta Celda de Servicio en el PDCCH para el C-RNTI de la entidad de MAC, o C-RNTI Temporal:
2> si esta es la primera asignación de enlace descendente para este C-RNTI Temporal:
3> considerar que el NDI ha sido alternado.
2> si la asignación de enlace descendente es para el C-RNTI de la entidad de MAC, y si la asignación de enlace descendente previa indicada a la entidad de HARQ del mismo proceso de HARQ fue ya sea una asignación de enlace descendente recibida para el CS-RNTI de la entidad de MAC o una asignación de enlace descendente configurada:
3> considerar que el NDI se ha alternado independientemente del valor del NDI.
2> indicar la presencia de una asignación de enlace descendente y suministrar la información de HARQ asociada a la entidad de HARQ
1> si no si se ha recibido una asignación de enlace descendente para esta ocasión de PDCCH para esta Celda de Servicio en el PDCCH para el CS-RNTI de la entidad de MAC:
2> si el NDI en la información de HARQ recibida es 1:
3> considerar que el NDI para el proceso de HARQ correspondiente no se ha alternado;
3> indicar la presencia de una asignación de enlace descendente para esta Celda de Servicio y suministrar la información de HARQ asociada a la entidad de HARQ.
2> si el NDI en la información de HARQ recibida es 0:
3> si el contenido de PDCCH indica desactivación de SPS:
4> borrar la asignación de enlace descendente configurada para esta Celda de Servicio (si hay);
4> si el timeAlignmentTimer, asociado con el TAG que contiene la Celda de Servicio en la cual va a ser transmitida la retroalimentación de HARQ, está funcionando:
5> indicar un reconocimiento positivo para la desactivación de SPS a la capa física.
3> si no si el contenido de PDCCH indica activación de SPS:
4> almacenar la asignación de enlace descendente para esta Celda de Servicio y la información de HARQ asociada como asignación de enlace descendente configurada;
4> inicializar o reinicializar la asignación de enlace descendente configurada para que esta Celda de Servicio inicie en la duración de PDSCH asociado y se repita de acuerdo con las reglas en la cláusula 5.8.1;
Para cada Celda de Servicio y cada asignación de enlace descendente configurada, si está configurada y activada, la entidad de MAC deberá:
1> si la duración de PDSCH de la asignación de enlace descendente configurada no se superpone con la duración de PDSCH de una asignación de enlace descendente recibida en el PDCCH para esta Celda de Servicio:
2> instruir a la capa física que reciba, en esta duración de PDSCH, el bloque de transporte en el DL-SCH de acuerdo con la asignación de enlace descendente configurada y que lo suministre a la entidad de HARQ; 2> establecer el ID de Proceso de HARQ en el ID de Proceso de HARQ asociado con esta duración de PDSCH; 2> considerar que se ha alternado el bit de NDI para el proceso de HARQ correspondiente;
2> indicar la presencia de una asignación de enlace descendente configurada y suministrar la información de HARQ almacenada a la entidad de HARQ.
Para asignaciones de enlace descendente configuradas sin harq-ProcID-Offset, el ID de Proceso de HARQ asociado con la ranura donde inicia la transmisión de DL se deriva desde la siguiente ecuación: donde CURRENT_slot = [(SFN * numberOfSlotsPerFrame) número de ranura en el marco] y numberOfSlotsPerFrame se refiere al número de ranuras consecutivas por marco como se especifica en t S 38.211 [8].
Para asignaciones de enlace descendente configuradas con harq-ProcID-Offset, el ID de Proceso de HARQ asociado con la ranura donde inicia la transmisión de DL se deriva desde la siguiente ecuación: donde CURRENT_slot = [(SFN * numberOfSlotsPerFrame) número de ranura en el marco] y numberOfSlotsPerFrame se refiere al número de ranuras consecutivas por marco como se especifica en t S 38.211 [8].
NOTA 1: En caso de SFN no alineado a través de portadores en un grupo de celdas, la SFN de la Celda de Servicio en cuestión se usa para calcular el ID de Proceso de HARQ usado para las asignaciones de enlace descendente configuradas.
NOTA 2: CURRENT_slot se refiere al índice de ranura de la primera ocasión de transmisión de un paquete de asignación de enlace descendente configurada.
Cuando la entidad de MAC necesita leer BCCH, la entidad de MAC puede, con base en la información de programación desde RRC:
1> si se ha recibido una asignación de enlace descendente para esta ocasión de PDCCH en el PDCCH para el SI-RNTI;
2> indicar una asignación de enlace descendente y versión de redundancia para el proceso de HARQ de radiodifusión dedicada a la entidad de HARQ.
5.3.2 Operación de HARQ
5.3.2.1 Entidad de HARQ
La entidad de MAC incluye una entidad de HARQ para cada Celda de Servicio, que mantiene un número de procesos de HARQ paralelos. Cada proceso de HAR<q>está asociado con un identificador de proceso de HARQ. La entidad de HARQ dirige información de HARQ y los TBs asociados recibidos en el DL-SCH a los procesos de HARQ correspondientes (véase cláusula 5.3.2.2).
El número de procesos de HARQ de DL paralelos por entidad de HARQ se especifica en TS 38.214 [7]. El proceso de HARQ de radiodifusión dedicado se usa para BCCH.
El proceso de HARQ soporta un TB cuando la capa física no está configurada para multiplexación espacial de enlace descendente.
El proceso de HARQ soporta uno o dos TBs cuando la capa física está configurada para multiplexación espacial de enlace descendente.
Cuando la entidad de MAC está configurada con pdsch-AggregationFactor > 1, el parámetro pdsch-AggregationFactor proporciona el número de transmisiones de un TB dentro de un paquete de la asignación de enlace descendente. La operación de agrupación depende de la entidad de HARQ para invocar el mismo proceso de HARQ para cada transmisión que es parte del mismo paquete. Después de la transmisión inicial, siguen las retransmisiones de HARQ pdsch-AggregationFactor- 1 dentro de un paquete
La entidad de MAC deberá:
1> si se ha indicado una asignación de enlace descendente:
2> asignar los TBs recibidos desde la capa física y la información de HARQ asociada al proceso de HARQ indicado por la información de HARQ asociada.
1> si se ha indicado una asignación de enlace descendente para el proceso de HARQ de radiodifusión: 2> asignar el TB recibido al proceso de HARQ de radiodifusión.
5.3.2.2 Proceso de HARQ
Cuando tiene lugar una transmisión para el proceso de HARQ, uno o dos (en el caso de multiplexación espacial de enlace descendente) TBs y la información de HARQ asociada se reciben desde la entidad de HARQ. Para cada TB recibido y la información de HARQ asociada, el proceso de HARQ deberá:
1> si el NDI, cuando se proporciona, ha sido alternado en comparación con el valor de la transmisión recibida previa que corresponde a este TB; o
1> si el proceso de HARQ es igual al proceso de radiodifusión, y esta es la primera transmisión recibida para el TB de acuerdo con la programación de información de sistema indicado por RRC; o
1> si esta es la primera transmisión recibida para este TB (es decir no hay NDI previa para este TB):
2> considerar esta transmisión como una transmisión nueva
1> si no:
2> considerar esta transmisión como una retransmisión.
La entidad de MAC deberá entonces:
1> si es una transmisión nueva:
2> intentar decodificar los datos recibidos
1> si no si esta es una retransmisión:
2> si los datos de este TB aún no se han decodificado con éxito:
3> instruir a la capa física que combine los datos recibidos con los datos actualmente en el búfer suave para este TB e intentar decodificar los datos combinados
1> si los datos que la entidad de MAC intentó decodificar fueron decodificados con éxito para este TB; o 1> si los datos para este TB fueron decodificados con éxito antes:
2> si el proceso de HARQ es igual al proceso de radiodifusión:
3> suministrar la PDU de MAC decodificada a las capas superiores.
2> si no si esta es la primera decodificación exitosa de los datos de este TB:
3> suministrar la PDU de MAC decodificada a la entidad de desensamblaje y demultiplexación.
1> si no:
2> instruir a la capa física que reemplace los datos en el búfer suave para este TB con los datos que la entidad de MAC intentó decodificar.
1> si el proceso de HARQ está asociado con una transmisión indicada con un C-RNTI Temporal y la Resolución de Competencia aún no es exitosa (véase cláusula 5.1.5); o
1> si el proceso de HARQ está asociado con una transmisión indicada con un MSGB-RNTI y el procedimiento de Acceso Aleatorio aún no se ha completado con éxito (véase cláusula 5.1.4a); o
1> si el proceso de HARQ es igual al proceso de radiodifusión; o
1> si el timeAlignmentTimer, asociado con el TAG que contiene la Celda de Servicio en la cual va a ser transmitida la retroalimentación de HARQ, está detenido o ha expirado:
2> no instruir a la capa física que genere reconocimientos de los datos en este TB.
1> si no:
2> instruir a la capa física para que genere reconocimientos de los datos en este TB.
La entidad de MAC ignorará el NDI recibido en todas las asignaciones de enlace descendente en el PDCCH para su C-RNTI Temporal cuando se determina si el NDI en PDCCH para su C-RNTI se ha alternado en comparación con el valor de la transmisión previa
NOTA: Si la entidad de MAC recibe una retransmisión con un tamaño de TB diferente del último tamaño de TB señalado para este TB, el comportamiento de UE se deja a la implementación de UE.
5.3.3 Desensamblaje y demultiplexación
La entidad de MAC desensamblará y demultiplexará una PDU de MAC como se define en las cláusulas 6.1.2 y 6.1.5a.
************************************Siguiente Cita [2]
************************************
5.7 Recepción Discontinua (DRX)
La entidad de MAC puede ser configurada por RRC con una funcionalidad de DRX que controla la actividad de monitorización de PDCCH del UE para C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, y AI-RNTI de la entidad de MAC. Cuando se usa la operación de DRX, la entidad de MAC también deberá monitorizar el PDCCH de acuerdo con los requisitos que se encuentran en otras cláusulas de esta especificación. Cuando está en RRC_CONNECTED, si DRX está configurada, para todas las Celdas de Servicio activadas, la entidad de MAC puede monitorizar el PDCCH de manera discontinua usando la operación de DRX especificada en esta cláusula; de lo contrario la entidad de MAC monitorizará el PDCCH como se especifica en Ts 38.213 [6].
NOTA 1: Si el modo de asignación de recursos de Enlace lateral 1 se configura por RRC, no se configura una funcionalidad de DRX.
RRC controla la operación de DRX configurando los siguientes parámetros:
- drx-onDurationTimer: la duración al comienzo de un ciclo de DRX;
- drx-SlotOffset: el retraso antes de iniciar el drx-onDurationTimer;
- drx-InactivityTimer: la duración después de la ocasión de PDCCH en la cual un PDCCH indica una nueva transmisión de UL o DL para la entidad de MAC;
- drx-RetransmissionTimerDL (por proceso de HARQ de DL excepto para el proceso de radiodifusión): la duración máxima hasta que se recibe una retransmisión de DL;
- drx-RetransmissionTimerUL (por proceso de HARQ de UL): la duración máxima hasta que se recibe una concesión para la retransmisión de UL;
- drx-LongCydeStartOffset: el ciclo de DRX Largo y drx-StartOffset que define el submarco donde inicia el ciclo de DRX Largo y Corto;
- drx-ShortCycle (opcional): el ciclo de DRX Corto;
- drx-ShortCycleTimer (opcional): la duración que el UE seguirá el ciclo de DRX Corto;
- drx-HARQ-RTT-TimerDL (por proceso de HARQ de DL excepto para el proceso de radiodifusión): la duración mínima antes de que una asignación de DL para la retransmisión HARQ sea esperada por la entidad de MAC; - drx-HARQ-RTT-TimerUL (por proceso de HARQ de UL): la duración mínima antes de que una concesión de retransmisión de HARQ de UL sea esperada por la entidad de MAC;
- ps-Wakeup (opcional): la configuración para iniciar drx-onDurationTimer asociado en caso de que DCP sea monitorizado pero no detectado;
- ps-TransmitOtherPeriodicCSI (opcional): la configuración para reportar CSI periódica que no es L1-RSRP en PUCCH durante la duración de tiempo indicada por drx-onDurationTimer en caso de que DCP esté configurado pero el drx-onDurationTimer asociado no esté iniciado;
- ps-TransmitPeriodicL1-RSRP (opcional): la configuración para transmitir CSI periódica que es L1-RSRP en PUCCH durante la duración de tiempo indicada por drx-onDurationTimer en caso de que<d>C<p>esté configurado pero el drx-onDurationTimer asociado no esté iniciado.
Las Celdas de Servicio de una entidad de MAC se pueden configurar por RRC en dos grupos de DRX con parámetros de DRX separados. Cuando RRC no configura un grupo de DRX secundario, solo hay un grupo de DRX y todas las Celdas de Servicio pertenecen a ese grupo de DRX. Cuando se configuran dos grupos de DRX, cada Celda de Servicio se asigna de manera única a cualquiera de los dos grupos. Los parámetros de DRX que se configuran por separado para cada grupo de DRX son: drx-onDurationTimer, drx-InactivityTimer. Los parámetros de DRX que son comunes a los grupos de DRX son: drx-SlotOffset, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle (opcional), drx-ShortCycleTimer (opcional), drx HARQ RTT-TimerDL, y drx-HARQ-RTT-TimerUL.
Cuando se configura un ciclo de DRX, el Tiempo Activo para Celdas de Servicio en un grupo de DRX incluye el tiempo mientras:
- drx-onDurationTimer o drx-InactivityTimer configurado para el grupo de DRX está funcionando; o
- drx-RetransmissionTimerDL o drx-RetransmissionTimerUL está funcionando en cualquier Celda de Servicio en el grupo de DRX; o
- está funcionando ra-ContentionResolutionTimer (como se describe en la cláusula 5.1.5) o msgB-Response Window (como se describe en la cláusula 5.1.4a); o
- se envía una Solicitud de Programación en el PUCCH y está pendiente (como se describe en la cláusula 5.4.4); o
- no se ha recibido un PDCCH que indica una nueva transmisión dirigida al C-RNTI de la entidad de MAC después de la recepción exitosa de una Respuesta de Acceso Aleatorio para el Preámbulo de Acceso Aleatorio no seleccionado por la entidad de MAC entre el Preámbulo de Acceso Aleatorio basado en competencia (como se describe en las cláusulas 5.1.4 y 5.1.4a).
Cuando se configura DRX, la entidad de MAC deberá:
1> si se recibe una PDU de MAC en una asignación de enlace descendente configurada:
2> iniciar el drx-HARQ-RTT-TimerDL para el proceso de HARQ correspondiente en el primer símbolo después del final de la transmisión correspondiente que porta la retroalimentación de HARQ de DL;
2> detener el drx-RetransmissionTimerDL para el proceso de HARQ correspondiente.
1> si se transmite una PDU de MAC en una concesión de enlace ascendente configurada y no se recibe indicación de falla de LBT de capas inferiores:
2> iniciar el drx-HARQ-RTT-TimerUL para el proceso de HARQ correspondiente en el primer símbolo después del final de la primera transmisión (dentro de un paquete) de la transmisión de PUSCH correspondiente; 2> detener el drx-RetransmissionTimerUL para el proceso de HARQ correspondiente en la primera transmisión (dentro de un paquete) de la transmisión de PUSC<h>correspondiente
1> si expira un drx-HARQ-RTT-TimerDL:
2> si los datos del proceso de HARQ correspondiente no fueron decodificados con éxito:
3> iniciar el drx-RetransmissionTimerDL para el proceso de HARQ correspondiente en el primer símbolo después de la expiración de drx-HARQRTT-TimerDL.
1> si expira un drx-HARQ-RTT-TimerUL:
2> iniciar el drx-RetransmissionTimerUL para el proceso de HARQ correspondiente en el primer símbolo después de la expiración de drx-HARQ-RTT-TimerUL.
1> si se recibe un CE de MAC de Comando de DRX o un CE de MAC de Comando de DRX Largo:
2> detener drx-onDurationTimer para cada grupo de DRX;
2> detener drx-InactivityTimer para cada grupo de DRX.
1> si expira drx-InactivityTimer para un grupo de DRX:
2> si está configurado el ciclo de DRX Corto:
3> iniciar o reiniciar drx-ShortCycleTimer para este grupo de DRX en el primer símbolo después de la expiración de drx-InactivityTimer;
3> usar el ciclo de DRX Corto para este grupo de DRX
2> si no:
3> usar el ciclo de DRX Largo para este grupo de DRX.
1> si se recibe un CE de MAC de Comando de DRX:
2> si está configurado el ciclo de DRX Corto:
3> iniciar o reiniciar drx-ShortCycleTimer para cada grupo de DRX en el primer símbolo después del final de la recepción de CE de MAC de Comando de DRX;
3> usar el ciclo de DRX Corto para cada grupo de DRX.
2> si no:
3> usar el ciclo de DRX Largo para cada grupo de DRX.
1> si expira drx-ShortCycleTimer para un grupo de DRX:
2> usar el ciclo de DRX Largo para este grupo de DRX.
1> si se recibe un CE de MAC de Comando de DRX Largo:
2> detener drx-ShortCycleTimer para cada grupo de DRX;
2> usar el ciclo de DRX Largo para cada grupo de DRX
1> si el ciclo de DRX Corto se usa para un grupo de DRX, y [(SFN * 10) número de submarco] módulo (drx-ShortCycle) = (drx-StartOffset) módulo (drx-ShortCycle):
2> iniciar el drx-onDurationTimer para este grupo de DRX después de drx-SlotOffset desde el comienzo del submarco.
1> si el ciclo de DRX Largo se usa para un grupo de DRX, y [(SFN * 10) número de submarco] módulo (drx-LongCycle) = drx-StartOffset:
2> si la monitorización de DCP está configurada para la BWP de DL activa como se especifica en TS 38.213 [6], cláusula 10.3:
3> si la indicación de DCP asociada con el ciclo de DRX actual recibida desde la capa inferior indica que se inicia drx-onDurationTimer, como se especifica en TS 38.213 [6]; o
3> si todas las ocasiones de DCP en dominio de tiempo, como se especifica en TS 38.213 [6], asociadas con el ciclo de DRX actual se produjeron en Tiempo Activo considerando concesiones/asignaciones/CE de MAC de Comando de DRX/CE de m Ac de Comando de DRX Largo recibido y Solicitud de Programación enviada hasta 4 ms antes del inicio de la última ocasión de DCP, o durante una brecha de medición, o cuando la entidad de MAC monitoriza una transmisión de PDCCH en el espacio de búsqueda indicado por recoverySearchSpaceId de la SpCelda identificada por el C-RNTI mientras la ra-ResponseWindow está funcionando (como se especifica en la cláusula 5.1.4); o
3> si ps-Wakeup está configurado con el valor verdadero y la indicación de DCP asociada con el ciclo de DRX actual no se ha recibido desde las capas inferiores:
4> iniciar drx-onDurationTimer después de drx-SlotOffset desde el comienzo del submarco.
2> si no:
3> iniciar drx-onDurationTimer para este grupo de DRX después de drx-SlotOffset desde el comienzo del submarco.
NOTA 2: En caso de SFN no alineada a través de portadores en un grupo de celdas, la SFN de la SpCelda se usa para calcular la duración de DRX
1> si un grupo de DRX está en Tiempo Activo:
2> monitorizar el PDCCH en las Celdas de Servicio en este grupo de DRX como se especifica en TS 38.213 [6];
2> si el PDCCH indica una transmisión de DL:
3> iniciar el drx-HARQ-RTT-TimerDL para el proceso de HARQ correspondiente en el primer símbolo después del final de la transmisión correspondiente que porta la retroalimentación de HARQ de DL;
NOTA 3: Cuando la retroalimentación de HARQ se pospone mediante la temporización de PDSCH a HARQ_feedback que indica un valor k1 no numérico, como se especifica en TS 38.213 [6], la oportunidad de transmisión correspondiente para enviar la retroalimentación de HARQ de DL se indica en un PDCCH posterior que solicita la retroalimentación de HARQ-ACK.
3> detener el drx-RetransmissionTimerDL para el proceso de HARQ correspondiente.
3> si el tiempo de PDSCH a HARQ_feedback indica un valor k1 no numérico como se especifica en TS 38.213 [6]:
4> iniciar el drx-RetransmissionTimerDL en el primer símbolo después de la transmisión de PDSCH para el proceso de HARQ correspondiente.
2> si el PDCCH indica una transmisión de UL:
3> iniciar el drx-HARQ-RTT-TimerUL para el proceso de HARQ correspondiente en el primer símbolo después del final de la primera transmisión (dentro de un paquete) de la transmisión de PUSCH correspondiente; 3> detener el drx-RetransmissionTimerUL para el proceso de HARQ correspondiente.
2> si el PDCCH indica una nueva transmisión (DL o UL) en una Celda de Servicio en este grupo de DRX: 3> iniciar o reiniciar drx-InactivityTimer para este grupo de DRX en el primer símbolo después del final de la recepción de PDCCH
2> si un proceso de HARQ recibe información de retroalimentación de enlace descendente y se indica reconocimiento:
3> detener el drx-RetransmissionTimerUL para el proceso de HARQ correspondiente.
1> si la monitorización de DCP está configurada para la BWP de DL activa como se especifica en TS 38.213 [6], cláusula 10.3; y
1> si el símbolo actual n se produce dentro de la duración de drx-onDurationTimer; y
1> si drx-onDurationTimer asociado con el ciclo de DRX actual no se inicia como se especifica en esta cláusula: 2> si la entidad de MAC no estaría en Tiempo Activo considerando concesiones/asignaciones/CE de MAC de Comando de DRX/CE de MAC de Comando de DRX Largo recibido y Solicitud de Programación enviada hasta 4 ms antes del símbolo n cuando se evalúan todas las condiciones de Tiempo Activo de DRX como se especifica en esta cláusula:
3> no transmitir SRS periódico y SRS semipersistente definido en TS 38.214 [7];
3> no reportar CSI semipersistente configurada en PUSCH;
3> si ps-TransmitPeriodicL1-RSRP no está configurado con el valor verdadero:
4> no reportar CSI periódica que sea L1-RSRP en PUCCH.
3> si ps-TransmitOtherPeriodicCSI no está configurado con el valor verdadero:
4> no reportar CSI periódica que no sea L1-RSRP en PUCCH.
1> si no:
2> en el símbolo actual n, si un grupo de DRX no estaría en Tiempo Activo considerando las concesiones/asignaciones programadas en las Celdas de Servicio en este grupo de DRX y CE de MAC de Comando de DRX/CE de MAC de Comando de DRX Largo recibido y Solicitud de Programación enviada hasta 4 ms antes del símbolo n cuando se evalúan todas las condiciones de Tiempo Activo de DRX como se especifica en esta cláusula:
3> no transmitir SRS periódico y SRS semipersistente definido en TS 38.214 [7] en este grupo de DRX; 3> no reportar CSI en PUCCH y CSI semipersistente configurada en PUSCH en este grupo de DRX
2> si enmascaramiento de CSI (csi-Máscara) está configurado por capas superiores:
3> en el símbolo actual n, si drx-onDurationTimer de un grupo de DRX no se estaría funcionando considerando las concesiones/asignaciones programadas en las Celdas de Servicio en este grupo de DRX y CE de MAC de Comando de DRX/CE de MAC de Comando de DRX Largo recibido hasta 4 ms antes del símbolo n cuando se evalúan todas las condiciones de Tiempo Activo de DRX como se especifica en esta cláusula; y
4> no reportar CSI en PUCCH en este grupo de DRX.
NOTA 4: Si un UE multiplexa una CSI configurada en PUCCH con otras UCIs superpuestas de acuerdo con el procedimiento especificado en TS 38.213 [6] cláusula 9.2.5 y esta CSI multiplexada con otras UCIs se reportaría en un recurso de PUCCH fuera del Tiempo Activo de DRX del grupo de DRX en el cual está configurado este PUCCH, depende de la implementación de UE si reportar esta CSI multiplexada con otras UCIs.
Independientemente de si la entidad de MAC está monitorizando PDCCH o no en las Celdas de Servicio en un grupo de DRX, la entidad de MAC transmite retroalimentación de HARQ, CSI aperiódica en PUSCH, y SRS aperiódico definido en TS 38.214 [7] en las Celdas de Servicio en el grupo de DRX cuando tal se espera. La entidad de MAC no necesita monitorizar el PDCCH si no es una ocasión de PDCCH completa (por ejemplo, el Tiempo Activo inicia o termina en medio de una ocasión de PDCCH).
************************************Siguiente Cita [2]
************************************
5.15 Operación de Parte de Ancho de Banda (BWP)
5.15.1 Enlace descendente y enlace ascendente
Además de la cláusula 12 de TS 38.213 [6], esta cláusula especifica los requisitos sobre la operación de BWP. Una Celda de Servicio puede configurarse con una o múltiples BWPs, y el número máximo de BWP por Celda de Servicio se especifica en TS 38.213 [6].
La conmutación de BWP para una Celda de Servicio se usa para activar una BWP inactiva y desactivar una BWP activa a la vez. La conmutación de BWP está controlada por el PDCCH que indica una asignación de enlace descendente o una concesión de enlace ascendente, por el bwp-InactivityTimer, por la señalización de RRC, o por la propia entidad de MAC tras la iniciación del procedimiento de Acceso Aleatorio o tras detección de una falla constante de LBT en SpCelda. Tras la (re)configuración de RRC de firstActiveDownlinkBWP-Id y/o firstActiveUplinkBWP-Id para SpCelda o activación de una SCelda, la BWP de DL y/o BWP de UL indicada por firstActiveDownlinkBWP-Id y/o firstActiveUplinkBWP-Id respectivamente (como se especifica en TS 38.331 [5]) está activo sin recibir PDCCH que indique una asignación de enlace descendente o una concesión de enlace ascendente. La BWP activa para una Celda de Servicio se indica mediante ya sea RRC o PDCCH (como se<especifica en TS 38.213 [6]). Para el espectro no emparejado, una BWP de>D<l se empareja con una BWP de UL, y la conmutación de b>W<p es común tanto para UL como para DL.>
Para cada SCelda se puede configurar una BWP inactiva con dormantBWP-Id mediante señalización de RRC como se describe en TS 38.331 [5]. La entrada o salida de BWP inactiva para SCeldas se hace mediante la conmutación de BWP por SCelda o por grupo de SCelda en inactividad con base en la instrucción desde PDCCH (como se especifica en TS 38.213 [6]). Las configuraciones de grupo de SCelda en inactividad se configuran mediante señalización de RRC como se describe en TS 38.331 [5]. Tras la recepción del PDCCH que indica que se deja la BWP inactiva, se activa la BWP de DL indicada por firstOutsideActiveTimeBWP-Id o<por firstWithinActiveTimeBWP-Id (como se especifica en TS 38.331 [5] y>T<s 38.213 [6]). Tras la recepción del>PDCCH que indica entrar en BWP inactiva, se activa la BWP de DL indicada por dormantBWP-Id (como se especifica en TS 38.331 [5]). No se soporta la configuración de BWP inactiva para SpCelda o SCelda de PUCCH.
Para cada Celda de Servicio activada configurada con una BWP, la entidad de MAC deberá:
1> si se activa una BWP y la BWP de DL activa para la Celda de Servicio no es la BWP inactiva:
2> transmitir en UL-SCH en la BWP;
2> transmitir en RACH en la BWP, si se configuran ocasiones de PRACH;
2> monitorizar el PDCCH en la BWP;
2> transmitir PUCCH en la BWP, si está configurado;
2> reportar CSI para la BWP;
2> transmitir SRS en la BWP, si está configurado;
2> recibir DL-SCH en la BWP;
2> (re)inicializar cualquier concesión de enlace ascendente configurada suspendida de Tipo 1 de concesión configurada en la BWP activa de acuerdo con la configuración almacenada, si hay, e iniciar en el símbolo de acuerdo con las reglas en la cláusula 5.8.2;
2> si lbt-FailureRecoveryConfig está configurado:
3> detener el lbt-FailureDetectionTimer, si está funcionando;
3> establezca LBT COUNTER en 0;
3> monitorizar las indicaciones de falla de LBT desde capas inferiores como se especifica en la cláusula 5.21.2.
1> si una BWP está activada y la BWP de DL activa para la Celda de Servicio es BWP inactiva:
2> detener el bwp-InactivityTimer de esta Celda de Servicio, si está funcionando.
2> no monitorizar el PDCCH en la BWP;
2> no monitorizar el PDCCH para la BWP;
2> no recibir DL-SCH en la BWP;
2> no reportar CSI en la BWP, reportar CSI excepto CSI aperiódica para la BWP;
2> no transmitir SRS en la BWP;
2> no transmitir en UL-SCH en la BWP;
2> no transmitir en RACH en la BWP;
2> no transmitir PUCCH en la BWP.
2> borrar cualquier asignación de enlace descendente configurada y cualquier Tipo 2 de concesión de enlace ascendente configurada asociado con la SCelda respectivamente;
2> suspender cualquier Tipo 1 de concesión de enlace ascendente configurada asociado con la SCelda; 2> si está configurado, realizar la detección de falla de haz y recuperación de falla de haz para la SCelda si se detecta falla de haz
1> si una BWP está desactivada:
2> no transmitir en UL-SCH en la BWP;
2> no transmitir en RACH en la BWP;
2> no monitorizar el PDCCH en la BWP;
2> no transmitir PUCCH en la BWP;
2> no reportar CSI para la BWP;
2> no transmitir SRS en la BWP;
2> no recibir DL-SCH en la BWP;
2> borrar cualquier asignación de enlace descendente configurada y concesión de enlace ascendente configurada de Tipo 2 de concesión configurada en la BWP;
2> suspender cualquier concesión de enlace ascendente configurada de Tipo 1 de concesión configurada en la BWP inactiva.
Tras iniciación del procedimiento de Acceso Aleatorio en una Celda de Servicio, después de la selección del portador para realizar el procedimiento de Acceso Aleatorio como se especifica en la cláusula 5.1.1, la entidad de MAC deberá para el portador seleccionado de esta Celda de Servicio:
1> si las ocasiones de PRACH no están configuradas para el BWP de UL activa:
2> conmutar la BWP de UL activa a la BWP indicada por initialUplinkBWP;
2> si la Celda de Servicio es una SpCelda:
3> conmutar la BWP de DL activa a la BWP indicada por initialDownlinkBWP.
1> si no:
2> si la Celda de Servicio es una SpCelda:
3> si la BWP de DL activa no tiene el mismo bwp-Id que la BWP de UL activa:
4> conmutar la BWP de DL activa a la BWP de DL con el mismo bwp-Id que el BWP de UL activa.
1> detener el bwp-InactivityTimer asociado con la BWP de DL activa de esta Celda de Servicio, si está funcionando.
1> si la Celda de Servicio es SCelda:
2> detener el bwp-InactivityTimer asociado con la BWP de DL activa de SpCelda, si está funcionando.
1> realizar el procedimiento de Acceso Aleatorio en la BWP de DL activa de SpCelda y BWP de UL activa de esta Celda de Servicio.
Si la entidad de MAC recibe un PDCCH para la conmutación de BWP de una Celda de Servicio, la entidad de MAC deberá:
1> si no hay ningún procedimiento de Acceso Aleatorio en curso asociado con esta Celda de Servicio; o 1> si el procedimiento de Acceso Aleatorio en curso asociado con esta Celda de Servicio se completa con éxito tras recepción de este PDCCH dirigido a C-RNTI (como se especifica en las cláusulas 5.1.4, 5.1.4a, y 5.1.5): 2> cancelar, si hay, falla de LBT consistente activada para esta Celda de Servicio;
2> realizar conmutación de BWP a una BWP indicada por el PDCCH.
Si la entidad de MAC recibe un PDCCH para la conmutación de BWP para unas Celdas de Servicio o unos grupos de SCelda en inactividad mientras un procedimiento de Acceso Aleatorio asociado con esa Celda de Servicio está en curso en la entidad de MAC, depende de la implementación de UE si conmutar BWP o ignorar el PDCCH para conmutación de BWP, excepto la recepción de PDCCH para la conmutación de BWP dirigida al C-RNTI para la compleción exitosa de procedimiento de Acceso Aleatorio (como se especifica en las cláusulas 5.1.4, 5.1.4a, y 5.1.5) en cuyo caso el UE realizará la conmutación de BWP a una bW p indicada por el PDCCH. Tras recepción del PDCCH para una conmutación de BWP que no sea una resolución de competencia exitosa, si la entidad de MAC decide realizar una conmutación de BWP, la entidad de MAC detendrá el procedimiento de Acceso Aleatorio en curso e iniciará un procedimiento de Acceso Aleatorio después de realizar la conmutación de BWP; si el MAC decide ignorar el PDCCH para la conmutación de BWP, la entidad de MAC continuará con el procedimiento de Acceso Aleatorio en curso en la Celda de Servicio. Tras recepción de la (re)configuración de RRC para la conmutación de BWP para una Celda de Servicio mientras un procedimiento de Acceso Aleatorio asociado con esa Celda de Servicio está en curso en la entidad de MAC, la entidad de MAC detendrá el procedimiento de Acceso Aleatorio en curso e iniciará un procedimiento de Acceso Aleatorio después realizar la conmutación de BWP Tras recepción de la (re)configuración de RRC para la conmutación de BWP para una Celda de Servicio, cancelar cualquier falla de LBT activada en esta Celda de Servicio.
La entidad de MAC deberá para cada Celda de Servicio activada configurada con bwp-InactivityTimer 1> si el defaultDownlinkBWP-Id está configurado, y la BWP de DL activa no es la BWP indicada por el defaultDownlinkBWP-Id, y la BWP de DL activa no es la BWP indicada por el dormantBWP-Id si está configurado; o
1> si el defaultDownlinkBWP-Id no está configurado, y la BWP de DL activa no es la initialDownlinkBWP, y la BWP de DL activa no es la BWP indicada por el dormantBWP-Id si está configurado:
2> si se recibe un PDCCH dirigido a C-RNTI o CS-RNTI que indica asignación de enlace descendente o concesión de enlace ascendente en la BWP activa; o
2> si se recibe un PDCCH dirigido a C-RNTI o CS-RNTI que indica asignación de enlace descendente o concesión de enlace ascendente para la BWP activa; o
2> si se transmite una PDU de MAC en una concesión de enlace ascendente configurada y no se recibe indicación de falla de LBT desde capas inferiores; o
2> si se recibe una PDU de MAC en una asignación de enlace descendente configurada:
3> si no hay ningún procedimiento de Acceso Aleatorio en curso asociado con esta Celda de Servicio; o 3> si el procedimiento de Acceso Aleatorio en curso asociado con esta Celda de Servicio se completa con éxito tras recepción de este PDCCH dirigido al C-RNTI (como se especifica en las cláusulas 5.1.4, 5.1.4a, y 5.1.5): 4> iniciar o reiniciar el bwp-InactivityTimer asociado con la BWP de DL activa.
2> si expira el bwp-InactivityTimer asociado con la BWP de DL activa:
3> si el defaultDownlinkBWP-Id está configurado:
4> realizar la conmutación de BWP a una BWP indicada por el defaultDownlinkBWP-Id.
3> si no:
4> realizar la conmutación de BWP al initialDownlinkBWP.
NOTA: Si se inicia un procedimiento de Acceso Aleatorio en una SCelda, tanto esta SCelda como la SpCelda están asociadas con este procedimiento de Acceso Aleatorio.
1> si se recibe un PDCCH para conmutación de BWP, y la entidad de MAC conmuta la BWP de DL activa: 2> si el defaultDownlinkBWP-Id está configurado, y la entidad de MAC conmuta a la BWP de DL que no está indicada por el defaultDownlinkBWP-Id y no está indicado por el dormantBWP-Id si está configurado; o 2> si el defaultDownlinkBWP-Id no está configurado, y la entidad de MAC conmuta a la BWP de DL que no es el initialDownlinkBWP y no está indicado por el dormantBWP-Id si está configurado:
3> iniciar o reiniciar el bwp-InactivityTimer asociado con la BWP de DL activa.
<* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *>’ S<i>iguiente Cita [2]
************************************
5.19 Monitorización de inactividad de datos
El UE puede configurarse por RRC con una funcionalidad de monitorización de inactividad de Datos, cuando está en RRC_CONNECTED. RRC controla la operación de inactividad de Datos configurando el temporizador dataInactivityTimer.
Cuando se configura dataInactivityTimer, el UE deberá:
1 > si cualquier entidad de MAC recibe una SDU de MAC para el canal lógico de DTCH, canal lógico de DCCH, o canal lógico de CCCH; o
1> si cualquier entidad de MAC transmite una SDU de MAC para el canal lógico de DTCH, o canal lógico de DCCH:
2> iniciar o reiniciar dataInactivityTimer.
1> si el dataInactivityTimer expira:
2> indicar la expiración del dataInactivityTimer a las capas superiores
************************************Siguiente Cita [2]
************************************
7.1 Valores de RNTI
Los valores de RNTI se presentan en la Tabla 7.1-1.
Tabla 7.1-1: Valores de RNTI.
Tabla 7.1-2: Uso de RNTI.
************************************ Fin de Cita
*************************************
En NR, las descripciones relacionadas con los estados de UE y la transición de estado se especifican en TS 38.331 [3], y se citan a continuación como un punto de partida para mejora adicional.
************************************Inicio de Cita [3]
************************************
4.2.1 Estados de UE y transiciones de estados incluyendo interRAT
Un UE está ya sea en estado RRC_CONNECTED o en estado RRC_INACTIVE cuando se ha establecido una conexión de RRC. Si este no es el caso, es decir no se establece ninguna conexión de RRC, el UE está en estado RRC_IDLE. Los estados de RRC se pueden caracterizar además como sigue:
- RRC_IDLE:
- Una DRX específica de UE se puede configurar por capas superiores;
- Movilidad controlada por UE con base en configuración de red;
- El UE:
- Monitoriza los Mensajes Cortos transmitidos con P-RNTI sobre DCI (véase cláusula 6.5);
- Monitoriza un canal de Radiolocalización para radiolocalización de CN usando 5G-S-TMSI;
- Realiza mediciones de celdas vecinas y (re)selección de celdas;
- Adquiere información del sistema y puede enviar solicitudes de SI (si está configurado).
- Realiza el registro de mediciones disponibles junto con ubicación y tiempo de los UEs configurados con mediciones registradas.
- RRC_INACTIVE:
- Una DRX específica de UE puede configurarse mediante capas superiores o mediante capa de RRC; - Movilidad controlada por UE con base en configuración de red;
- El UE almacena el contexto AS Inactivo de UE;
- Un área de notificación basada en RAN se configura por capa de RRC;
- El UE:
- Monitoriza los Mensajes Cortos transmitidos con P-RNTI sobre DCI (véase cláusula 6.5);
- Monitoriza un canal de Radiolocalización para radiolocalización de CN usando 5G-S-TMSI y radiolocalización de RAN usando fullI-RNTI;
- Realiza mediciones de celdas vecinas y (re)selección de celdas;
- Realiza actualizaciones de área de notificación basada en RAN periódicamente y cuando se mueve fuera del área de notificación basada en RAN configurada;
- Adquiere información del sistema y puede enviar solicitudes de SI (si está configurado).
- Realiza el registro de mediciones disponibles junto con la ubicación y tiempo de los UEs configurados con mediciones registradas.
- RRC_CONNECTED:
- El UE almacena el contexto AS;
- Transferencia de datos de unidifusión hacia/desde UE;
- En capas inferiores, el UE puede configurarse con una DRX específica de UE;
- Para los UEs que soportan CA, uso de una o más SCeldas, agregadas con SpCelda, para ancho de banda aumentado;
- Para UEs que soportan DC, uso de un SCG, agregado con el MCG, para ancho de banda aumentado; - Movilidad controlada por red dentro de NR y hacia/desde E-UTRA;
- El UE:
- Monitoriza los Mensajes Cortos transmitidos con P-RNTI sobre DCI (véase cláusula 6.5), si está configurado; - Monitoriza los canales de control asociados con el canal de datos compartidos para determinar si los datos están programados para él;
- Proporciona información de calidad y retroalimentación de canal;
- Realiza mediciones de celdas vecinas y reporte de mediciones;
- Adquiere información de sistema;
- Realiza mediciones MDT inmediatas junto con reporte de ubicación disponible.
La figura 7 es una reproducción de la figura 4.2.1-1 desde 3GPP TS 38.331 V16.3.1, que ilustra una visión general de la máquina de estados de RRC de UE y las transiciones de estado en NR, donde un UE tiene solo un RRC a la vez.
************************************Siguiente Cita [3]
************************************
5.3.8 Liberación de conexión de RRC
5.3.8.1 General
La figura 8 es una reproducción de la figura 5.3.8.1-1 desde 3GPP TS 38.331 V16.3.1, que ilustra la liberación exitosa de conexión de RRC.
El propósito de este procedimiento es:
- liberar la conexión de RRC, lo cual incluye la liberación de los portadores de radio establecidos así como todos los recursos de radio; o
- suspender la conexión de RRC solo si están configurados SRB2 y al menos un DRB o, para IAB, SRB2, lo cual incluye la suspensión de los portadores de radio establecidos.
5.3.8.2 iniciación
La red inicia el procedimiento de liberación de conexión de RRC para transitar un UE en RRC_CONNECTED a RRC_IDLE; o para transitar un UE en RRC_CONNECTED a RRC_INACTIVE solo si SRB2 y al menos un DRB o, para IAB, SRB2, está configurado en RRC_CONNECTED; o para transitar un UE en r Rc_INACTIVE de vuelta a RRC_INACTIVE cuando el UE intenta reanudar; o para transitar un UE en RRC_INACTIVE a RRC_IDLE cuando el UE intenta reanudar. El procedimiento también se puede usar para liberar y redirigir un UE a otra frecuencia.
5.3.8.3 Recepción del RRCRelease por el UE
El UE deberá:
1> retrasar las siguientes acciones definidas en esta subcláusula 60 ms desde el momento en que fue recibido el mensaje RRCRelease u opcionalmente cuando las capas inferiores indiquen que se ha reconocido con éxito la recepción del mensaje RRCRelease, cualquiera que sea primero;
1 > detener el temporizador T380, si está funcionando;
1 > detener el temporizador T320, si está funcionando;
1> si el temporizador T316 está funcionando;
2> detener el temporizador T316;
2> borrar la información incluida en VarRLF-Report, si hay;
1 > detener el temporizador T350, si está funcionando;
1> si la seguridad AS no está activada:
2> ignorar cualquier campo incluido en el mensaje RRCRelease excepto waitTime;
2> realizar las acciones tras ir a RRC_IDLE como se especifica en 5.3.11 con la causa de liberación 'otra' en la cual finaliza el procedimiento;
1> si el mensaje RRCRelease incluye redirectedCarrierInfo que indica la redirección a eutra:
2> si se incluye cnType:
3> después de la selección de celda, indicar los Tipos de CN disponibles y el cnType recibido en las capas superiores;
NOTA 1: Manejar el caso si la celda de E-UTRA seleccionada después de la redirección no soporta el tipo de red central especificado por cnType, depende de la implementación de UE.
2> si se incluye voiceFallbackIndication:
3> considerar que la liberación de conexión de RRC fue para la alternativa de EPS para voz IMS (véase TS 23.502 [43]);
1> si el mensaje RRCRelease incluye cellReselectionPriorities:
2> almacenar la información de prioridad de reselección de celda proporcionada por cellReselectionPriorities; 2> si el t320 está incluido:
3> iniciar temporizador T320, con el valor de temporizador configurado de acuerdo con el valor de t320; 1> si no:
2> aplicar la información de prioridad de reselección de celda radiodifundida en la información de sistema; 1> si se incluye deprioritisationReq y el UE soporta la liberación de conexión de RRC con despriorización: 2> iniciar o reiniciar el temporizador T325 con el valor de temporizador configurado en el deprioritisationTimer señalado;
2> almacenar la deprioritisationReq hasta que expire T325;
1> si RRCRelease incluye measIdleConfig:
2> si T331 está funcionando:
3> detener el temporizador T331;
3> realizar las acciones como se especifican en 5.7.8.3;
2> si el measIdleConfig está establecido en configuración:
3> almacenar el measIdleDuration recibido en VarMeasIdleConfig;
3> iniciar el temporizador T331 con el valor establecido en measIdleDuration;
3> si el measIdleConfig contiene measIdleCarrierListNR:
4> almacenar el measIdleCarrierListNR recibido en VarMeasIdleConfig;
3> si el measIdleConfig contiene measIdleCarrierListEUTRA:
4> almacenar el measIdleCarrierListEUTRA recibido en VarMeasIdleConfig;
3> si el measIdleConfig contiene validityAreaList:
4> almacenar la validityAreaList recibida en VarMeasIdleConfig;
1> si RRCRelease incluye suspendConfig:
2> aplicar la suspendConfig recibida;
2> retirar todas las entradas dentro de VarConditionalReconfig, si hay;
2> para cada measId, si el reportConfig asociado tiene un reportType establecido en condTriggerConfig: 3> para el reportConfigId asociado:
4> retirar la entrada con el reportConfigId de coincidencia desde el reportConfigList dentro de la VarMeasConfig;
3> si el measObjectId asociado solo está asociado a un reportConfig con reportType establecido en condTriggerConfig:
4> retirar la entrada con el measObjectId de coincidencia desde el measObjectList dentro del VarMeasConfig; 3> retirar la entrada con el measId de coincidencia desde el measIdList dentro del VarMeasConfig;
2> restablecer MAC y liberar la configuración predeterminada de Grupo de Celdas de MAC, si hay;
2> restablecer entidades de RLC para SRB1;
2> si el mensaje RRCRelease con suspendConfig fue recibido en respuesta a un RRCResumeRequest o un RRCResumeRequestl:
3> detener el temporizador T319 si está funcionando;
3> en el contexto AS Inactivo de UE almacenado:
4> reemplazar las claves KgNB y KRRCint con las claves KgNB y KRRCint actuales;
4> reemplazar el C-RNTI con el C-RNTI temporal en la celda en la que el UE ha recibido el mensaje RRCRelease;
4> reemplazar cellIdentity con la cellIdentity de la celda en la que el UE ha recibido el mensaje RRCRelease; 4> reemplazar la identidad de celda física con la identidad de celda física de la celda en la que el UE ha recibido el mensaje RRCRelease;
2> si no:
3> almacenar en el contexto AS Inactivo de UE las claves KgNB y Krrcm actuales, el estado de ROHC, el flujo de QoS almacenado a las reglas de mapeo de DRB, el C-RNTI usado en la PCelda de origen, la cellIdentity y la identidad de celda física de la PCelda de origen, el spCeldaConfigCommon dentro de ReconfigurationWithSync de PSCelda de NR (si está configurado) y todos los demás parámetros configurados excepto:
- parámetros dentro de ReconfigurationWithSync de la PCelda;
- parámetros dentro de ReconfigurationWithSync de la PSCelda de NR, si están configurados;
- parámetros dentro de MobilityControlInfoSCG de la PSCelda de E-UTRA, si están configurados;
- servingCellConfigCommonSIB;
NOTA 2: Las configuraciones relacionadas con comunicación de enlace lateral de NR y la configuración de medición registrada no se almacenan como contexto AS Inactivo de UE, cuando el UE ingresa a RRC_INACTIVE.
2> suspender todos los SRBs y DRBs, excepto SRB0;
2> indicar la suspensión de PDCP a las capas inferiores de todos los DRBs;
2> si el t380 está incluido:
3> iniciar el temporizador T380, con el valor de temporizador establecido en t380;
2> si el mensaje RRCRelease está incluyendo el waitTime:
3> iniciar el temporizador T302 con el valor establecido en waitTime;
3> informar a las capas superiores que la exclusión de acceso es aplicable a todas las categorías de acceso excepto a las categorías '0' y '2';
2> si T390 está funcionando:
3> detener el temporizador T390 para todas las categorías de acceso;
3> realizar las acciones como se especifican en 5.3.14.4;
2> indicar la suspensión de la conexión de RRC a las capas superiores;
2> ingresar RRC_INACTIVE y realizar la selección de celda como se especifica en TS 38.304 [20];
1> si no
2> realizar las acciones tras ir a RRC_IDLE como se especifica en 5.3.11, con la causa de liberación 'otra'.
5.3.8.4 Expiración de T320
El UE deberá:
1> si T320 expira:
2> si está almacenado, descartar la información de prioridad de reselección de celda proporcionada por cellReselectionPriorities o heredada desde otra RAT;
2> aplicar la información de prioridad de reselección de celda radiodifundida en la información de sistema. 5.3.8.5 Acciones de UE tras la expiración de DataInactivityTimer
Tras recibir la expiración de DataInactivityTimer desde capas inferiores mientras está en RRC_CONNECTED, el UE deberá:
1> realizar las acciones tras ir a RRC_IDLE como se especifica en 5.3.11, con la causa de liberación 'Fallo de conexión de RRC'.
************************************ Fin de Cita [3]
*************************************
Los acuerdos de la reunión de 3GPP RAN2 #111-e sobre MBS en [5] se citan a continuación:
************************************ Inicio de Cita [5]
************************************
Acuerdos de RAN2#111-E
^ Centrarse inicialmente en NR SA, TBD en qué medida se pueden soportar otros escenarios NR DC, NE DC. ^ Confirmar Soportará la transmisión de PTM en una celda.
^ Confirmar que, para los servicios de multidifusión, se introducirá soporte para la transmisión de PTP y PTM de tráfico compartido suministrado por 5GC, al menos para el modo conectado (esto no está previsto para excluir otros casos).
^ Para un UE, gNB decide dinámicamente si suministrar datos de multidifusión mediante PTM o PTP (suministro Compartido)
^ FFS qué capas maneja la fiabilidad (en general), en suministro de pedidos/manejo de duplicados, y es FFS cómo funciona en el conmutador de PTP de PTM.
^ Centrarse inicialmente en el escenario de MBS-MBS (es decir suministro compartido), incluyendo tanto PTM como PTP (si es aplicable). Otros escenarios más adelante, TBD.
^ Los requisitos para la movilidad sin pérdidas son TBD. Suponer por ahora que R2 de todos modos discutirá la funcionalidad de continuidad de servicio para una pérdida de datos baja o nula.
^ R2 supone que para la Movilidad de multidifusión de NR Rel-17 en modo Conectado, el traspaso (incluyendo variantes) es la línea base, TBD exactamente qué variantes.
^ R2 espera que pueda haber HARQ con retroalimentación (para PTM) y esto se especifica por R1.
************************************ Fin de Cita [5]
*************************************
Los acuerdos de la reunión de 3GPP RAN2 #112-e sobre MBS en [6] se citan a continuación:
************************************ Inicio de Cita [6]
************************************
Acuerdos de RAN2#112-e
Soporte de sesiones de radiodifusión y multidifusión, estados de RRC y otros aspectos relacionados con SA2 LS
^ Para Rel-17, R2 especifica dos modos:
1: Un modo de suministro para requisitos de alta QoS (fiabilidad, latencia), que va a estar disponible en CONNECTED (posiblemente el UE puede conmutar a otros estados cuando no hay recepción de datos TBD) 2: Un modo de suministro para requisito de QoS "bajo", donde el UE también puede recibir datos en INACTIVE/IDLE (detalles TBD).
R2 supone (para R17) que el modo de suministro 1 se usa solo para sesiones de multidifusión.
R2 supone que el modo de suministro 2 se usa para sesiones de radiodifusión.
La aplicabilidad del modo de suministro 2 a sesiones de multidifusión es FFS.
^ Sin datos: Cuando no hay datos en curso para la sesión de multidifusión, el UE puede permanecer en RRC_CONNECTED. Otros casos FFS
^ depende de SA2 decidir si el mecanismo de activación/desactivación de sesión de multidifusión es soportado o no, y RAN2 discutirá si hay cualquier impacto en RAN2 basado en entradas de SA2.
^ depende de SA2 decidir sobre el soporte del servicio de MBS local, y RAN2 discutirá los impactos en RAN2 con base en las entradas de SA2.
^ En general, se debe proporcionar a la RAN la Información de servicios/grupos de MBS suscritos por el UE (por ejemplo, TMGI) y los requisitos de QOS de un servicio de MBS. Información detallada por ejemplo, para el conmutador PTP de PTM si alguno es FFS.
Arquitectura de capa 2
^ La función de mapeo desde flujos de QoS a RBs de MBS en SDAP es necesaria para MBS de NR. TBD si se necesita cualquier encabezado de SDAP.
^ (Supuesto de trabajo) no se soportan para MBS funciones de SDAP distintas de "mapeo desde flujos de QoS a portadores de radio" y "transferencia de datos de plano de usuario". FFS si soportar flujos de QoS al remapeo de portadores de radio.
^ En general: RAN2 espera el progreso de SA3 para discutir cuestiones de seguridad. TBD si se necesita enviar LS a SA3.
^ RoHC (al menos modo U) se puede configurar para portadores de MBS de NR. Esto se aplica a Mcast, suponer que esto también se aplica a la radiodifusión.
^ RoHC está ubicado en PDCP.
^ La función de reordenamiento y suministro en pedido en PDCP se soporta con MBS de NR.
^ Las siguientes funciones de PDCP también son soportadas para MBS de NR: transferencia de datos; mantenimiento de SNs de PDCP; descarte de duplicados. Otras funciones de PDCP son FFS.
^ AM de RLC es soportado para la transmisión de PTP de MBS de NR.
^ UM de RLC es soportado para la transmisión de PTP de MBS de NR.
^ UM de RLC es soportado para la transmisión de PTM de MBS de NR.
^ TM de RLC no es soportado para la transmisión de PTP de MBS de NR.
^ TM de RLC no es soportado para la transmisión de PTM de MBS de NR.
^ FFS para PTM si se debe soportar la multiplexación/demultiplexación de diferentes canales lógicos en MAC para m Bs de NR.
^ Supuesto de trabajo: RLC-AM para PTM no es soportado (se puede revisar pero significa que los proponentes de RLC-AM para PTM deben demostrar la necesidad, para cambiar esto).
Continuidad de servicio
^ R2 tiene como objetivo soportar el traspaso sin pérdidas para la movilidad de MBS-MBS para el servicio que requiere esto (TBD qué escenario detallado pero al menos PTP-PTP)
^ Con el fin de soportar el traspaso sin pérdidas para los servicios de MBS 5G, al menos la sincronización de SN de PDCP de DL y la continuidad entre la celda de origen y la celda objetivo deben estar garantizadas por el lado de red para realizar. El diseño de un enfoque específico para lograr esto puede involucrarse con el WG RAN3.
^ Desde el lado de red, el gNB de origen puede reenviar los datos al gNB objetivo y el gNB objetivo suministrará los datos de reenvío. Mientras tanto, el SN STATUS TRANSFER debería ampliarse para cubrir el SN de PDCP para datos de MBS; Luego (TBD después o en paralelo) el UE recibe el MBS en la celda objetivo mediante la celda objetivo de acuerdo con la configuración objetivo.
^ Desde el lado de UE, también se puede soportar el reporte de estado de PDCP.
Soporte sin uno/inactivo
^ UE recibe la configuración de MBS (para el modo de radiodifusión/suministro 2) por BCCH y/o MCCH (TBD), y esto se puede recibir en modo sin uso/inactivo. FFS de modo conectado (dependiendo del límite de UE y de dónde se proporciona el servicio etc.). Se usa un mecanismo de notificación para anunciar el cambio de información de Control de MBS.
************************************ Fin de Cita
*************************************
Los acuerdos de la reunión de 3GPP RAN1 #102-e sobre MBS en [7] se citan a continuación:
************************************Inicio de Cita [7]
************************************
Acuerdos:
Para los UEs RRC_CONNECTED, se soporta la retroalimentación de HARQ-ACK para multidifusión y no se necesita ninguna evaluación adicional para justificar esto.
• FFS: Las soluciones detalladas de retroalimentación de HARQ-ACK, por ejemplo, basadas en ACK/NACK, basadas solo en NACK
• FFS: retroalimentación de HARQ-ACK se puede habilitar y/o deshabilitar opcionalmente.
Acuerdos:
Para los UEs RRC_CONNECTED, al menos soportar PDCCH de grupo común con CRC encriptado por un RNTI común para programar un PDSCH de grupo común, donde la encriptación del PDSCH de grupo común se basa en el mismo RNTI común.
• FFS: si soportar PDCCH específico de UE para programar un PDSCH para MBS.
Acuerdos:
Para los UEs RRC_CONNECTED, definir/configurar el recurso de frecuencia común para el PDSCH de grupo común.
• FFS: si reutilizar la estructura de BWP o no
• FFS: la relación entre el recurso de frecuencia común y BWP dedicada de UE, por ejemplo, el recurso de frecuencia común es una BWP específica de MBS, o el recurso de frecuencia común está confinado dentro de la BWP dedicada del UE, etc.
• FFS: si se puede configurar más de un recurso de frecuencia común por UE
Acuerdos:
Para los UEs RRC_CONNECTED, al menos soportar FDM entre PDSCH de unidifusión y PDSCH de grupo común en una ranura con base en la capacidad de UE.
• FFS: TDM o SDM en una ranura.
Acuerdos:
Para los UEs RRC_CONNECTED, al menos soportar la repetición a nivel de ranura para PDSCH de grupo común.
• FFS: si es necesaria una mejora
Acuerdos:
Para los UEs RRC_CONNECTED, la retroalimentación de CSI existente se puede usar para la transmisión de multidifusión.
• FFS: si es necesaria una mejora
************************************ Fin de Cita [7]
*************************************
Los Acuerdos y Supuestos de Trabajo de la reunión de 3GPP RAN1 #103-e sobre MBS en [8] se citan a continuación:
************************************Inicio de Cita [8]
************************************
Acuerdos: Para conveniencia de discusión, considerar la siguiente aclaración como entendimiento común de RAN1.
• Transmisión de PTP: Para UEs RRC_CONNECTED, usar PDCCH específico de UE con CRC encriptado por RNTI específico de UE (por ejemplo, C-RNTI) para programar PDSCH específico de UE que está encriptado con el mismo RNTI específico de UE.
• Esquema de transmisión de PTM 1: Para UEs RRC_CONNECTED en el mismo grupo de MBS, usar PDCCH de grupo común con CRC encriptado por RNTI de grupo común para programar PDSCH de grupo común que está encriptado con el mismo RNTI de grupo común. Este esquema también se puede llamar esquema de programación de grupo basado en PDCCH de grupo común.
• Esquema de transmisión de PTM 2: Para UEs RRC_CONNECTED en el mismo grupo de MBS, usar PDCCH específico de UE con CRC encriptado por RNTI específico de UE (por ejemplo, C-RNTI) para programar PDSCH de grupo común que está encriptado con RNTI de grupo común. Este esquema también puede denominarse esquema de programación de grupo basado en PDCCH específico de UE.
• Nota: El 'PDCCH/PDSCH específico de UE' aquí significa que el PDCCH/PDSCH solo puede ser identificado por el UE objetivo pero no puede ser identificado por los otros UEs en el mismo grupo de MBS con el UE objetivo.
• Nota: El 'PDCCH/PDSCH de grupo común' aquí significa que el PDCCH/PDSCH se transmiten en los mismos recursos de tiempo/frecuencia y pueden ser identificados por todos los UEs en el mismo grupo de MBS. • FFS si tener o no una definición adicional de esquemas de transmisión
Acuerdos: Para los UEs RRC_CONNECTED, si la transmisión inicial para multidifusión se basa en el esquema de transmisión de PTM 1, al menos las retransmisiones de soporte pueden usar el esquema de transmisión de PTM 1.
• FFS: si soportar la transmisión de PTP para retransmisiones.
• FFS: si soportar el esquema de transmisión de PTM 2 para retransmisiones.
• FFS: Cómo indicar la asociación entre esquema de PTM 1 y PTP que transmite el mismo TB.
• FFS: Si se soportan múltiples esquemas de retransmisión, entonces ¿se pueden soportar diferentes esquemas de retransmisión simultáneamente para diferentes UEs en el mismo grupo?
Supuesto de trabajo:
Para la multidifusión de UEs RRC-CONNECTED, un recurso de frecuencia común para PDCCH/PDSCH de grupo común está confinado dentro del recurso de frecuencia de una BWP de unidifusión dedicada para soportar la recepción simultánea de unidifusión y multidifusión en la misma ranura
• Seleccionar hacia abajo desde las dos opciones para el recurso de frecuencia común para PDCCH/PDSCH de grupo común
° Opción 2A: El recurso de frecuencia común se define como una BWP específica de MBS, que está asociada con la BWP de unidifusión dedicada y que usa la misma numerología (SCS y CP).
■ Se necesita conmutación de BWP de FFS entre la recepción de multidifusión en la BWP específica de MBS y la recepción de unidifusión en su BWP dedicada asociada.
° Opción 2B: El recurso de frecuencia común se define como una 'región de frecuencia de MBS' con un número de PRBs contiguos, que se configura dentro de la BWP de unidifusión dedicada.
■ FFS: Cómo indicar el PRB de partida y la longitud de PRBs de la región de frecuencia de MBS
• FFS si el UE se puede configurar sin recepción unidifusión en el recurso de frecuencia común
• FFS sobre detalles de la configuración de PDCCH/PDSCH de grupo común
• FFS si soportar más de un recurso de frecuencia común por UE/por BWP de unidifusión dedicada sujeto a las capacidades de UE
Acuerdo: Soportar TDM entre un PDSCH de unidifusión y un PDSCH de grupo común en una ranura con base en la capacidad de UE para UEs RRC_CONNECTED.
Acuerdos: Soportar PDSCH de grupo común de SPS para MBS para UEs RRC_CONNECTED
• FFS: usar PDCCH de grupo común o PDCCH específico de UE para la activación/desactivación de PDSCH de grupo común de SPS
• FFS: si soportar más de una configuración de PDSCH de grupo común de SPS por UE
• FFS: si y cómo se puede configurar la retroalimentación de enlace ascendente
• FFS: retransmisión de PDSCH de grupo común de SPS
Acuerdos: Para el esquema de transmisión de PTM 1, el CORESET para PDCCH de grupo común se configura dentro del recurso de frecuencia común para PDSCH de grupo común.
• FFS: número de CORESETs para PDCCH de grupo común dentro del recurso de frecuencia común para PDSCH de grupo común
Acuerdo: Para el conjunto de espacios de búsqueda de PDCCH de grupo común del esquema de PTM 1 para multidifusión en estado RRC_CONNECTED, los índices de CCE son comunes para diferentes UEs en el mismo grupo de MBS.
Acuerdos: Seleccionar hacia abajo entre las dos opciones para el límite de BDs/CCEs para MBS Rel-17 • Opción 1: el número máximo de candidatos de PDCCH monitorizados y CCEs no superpuestos por ranura por celda de servicio definida en Rel-15 se mantiene sin cambios para MBS Rel-17.
• Opción 2: Para los UEs que soportan la capacidad de CA, el presupuesto de BDs/CCEs de un CC no usado se puede usar para que el PDCCH de grupo común cuente el número de BDs/CCEs, que es similar al método usado para múltiples DCI basados en múltiples TRP en Rel-16.
Acuerdo: Para UEs RRC_CONNECTED, soportar TDM interranuras entre PDSCH de unidifusión y PDSCH de grupo común en diferentes ranuras (obligatorio para el UE que soporta MBS).
Acuerdos: Estudiar además los siguientes casos para la recepción simultánea de PDSCH de unidifusión y PDSCH de grupo común en una ranura con base en la capacidad de UE para UEs RRC_CONNECTED.
• Caso 1: soportar TDM entre múltiples PDSCHs de unidifusión TDMed y un PDSCH de grupo común en una ranura
• Caso 2: soportar TDM entre múltiples PDSCHs de grupo común en una ranura
• Caso 3: soportar TDM entre múltiples PDSCHs de unidifusión TDMed y múltiples PDSCHs de grupo común TDMed en una ranura
• Caso 4: soportar FDM entre múltiples PDSCHs de unidifusión TDMed y múltiples PDSCHs de grupo común TDMed en una ranura
• Caso 5: soportar FDM entre múltiples PDSCH de grupo común en una ranura
• FFS: número máximo de PDSCHs en una ranura recibidos simultáneamente por UE
Acuerdos: Para el conjunto de espacios de búsqueda de PDCCH de grupo común del esquema de PTM 1 para multidifusión en el estado RRC_CONNECTED, estudiar además las siguientes opciones.
• Opción 1: Definir un nuevo tipo de espacio de búsqueda específico para multidifusión
• Opción 2: Reutilizar los tipos de CSS existentes en Rel-15/16
° FFS: si se necesitan modificaciones para multidifusión
• Opción 3: Reutilizar el USS existente en Rel-15/16 con las modificaciones necesarias para MBS
° FFS: modificaciones detalladas
Acuerdo: Sin mejora en especificación en Rel-17 para soportar SDM entre PDSCH de unidifusión y PDSCH de grupo común en una ranura para UEs RRC_CONNECTED.
Acuerdo: Para el esquema de transmisión de PTM 1, si se acuerda la Opción 2A u Opción 2B para el recurso de frecuencia común para PDCCH/PDSCH de grupo común, el campo FDRA del PDCCH de grupo común se interpreta con base en el recurso de frecuencia común.
Acuerdos: Para el conjunto de espacios de búsqueda de PDCCH de grupo común del esquema de PTM 1 para multidifusión en el estado RRC_CONNECTED, estudiar además las siguientes opciones para la prioridad de monitorización del conjunto de espacios de búsqueda
• Opción 1: La prioridad de monitorización del espacio de búsqueda establecido para multidifusión es la misma que la del CSS Rel-15/16 existente
• Opción 2: La prioridad de monitorización del espacio de búsqueda establecido para multidifusión es la misma que la del USS Rel-15/16 existente
• No se excluyen otras opciones
• La prioridad de monitorización se usa al menos para el caso de sobreventa de PDCCH.
° FFS para otros casos (por ejemplo, para podar PDCCH en términos de si es unidifusión o multidifusión, etc.) Acuerdos:
Para los UEs RRC_CONNECTED que reciben multidifusión, al menos para el esquema de PTM 1, soportar al menos uno de los siguientes:
• Retroalimentación de HARQ-ACK basada en ACK/NACK para multidifusión,
• Desde perspectiva por UE, el UE retroalimenta ACK o NACK.
• Desde UEs dentro de la perspectiva grupal,
■ FFS: configuración de recursos de PUCCH para retroalimentación de ACK/NACK por ejemplo, recursos de PUCCH compartidos o separados.
• Detalles de FFS incluyendo las condiciones para que se use.
• Retroalimentación de HARQ-ACK basada solamente en NACK para multid ifusión,
• Desde perspectiva por UE, UE solo retroalimenta NACK.
• Desde UEs dentro de la perspectiva grupal
■ FFS: Configuración de recurso de PUCCH para retroalimentación solamente de NACK.
• Detalles de FFS incluyendo las condiciones para que se use.
• Decidir en RAN1#104-e si soportar o no solo uno o ambos de los esquemas anteriores
• Si ambos son soportados, configuración/selección de FFS de retroalimentación de HARQ-ACK basada en ACK/NACK y solo en NACK
Acuerdos:
Para los UEs RRC_CONNECTED que reciben multidifusión, para la retroalimentación de HARQ-ACK basada en ACK/NACK si se soporta para la programación de PDCCH de grupo común, la configuración de recursos de PUCCH para la retroalimentación de HARQ-ACK desde la perspectiva por UE es, seleccionar hacia abajo una de las siguientes opciones:
• Opción 1: compartida con configuración de recursos de PUCCH para retroalimentación de HARQ-ACK para unidifusión
• Opción 2: separada de la configuración de recursos de PUCCH para retroalimentación de HARQ-ACK para unidifusión
• Opción 3: Opción 1 u opción 2 con base en la configuración
Acuerdos:
Para los UEs RRC_CONNECTED que reciben multidifusión, para la retroalimentación de HARQ-ACK basada solamente en NACK si se soporta para la programación de PDCCH de grupo común, la configuración de recursos de PUCCH para la retroalimentación de HARQ-ACK desde la perspectiva por UE está separada de la configuración de recursos de PUCCH para la retroalimentación de HARQ-ACK para unidifusión.
• Formato de PUCCH de FFS
Acuerdos:
Se soporta habilitar/deshabilitar la retroalimentación de HARQ-ACK para MBS; seleccionar hacia abajo además entre:
• Opción 1: DCI
• Opción 2: RRC configura habilitar/deshabilitar
• Opción 3: RRC configura la función de habilitar/deshabilitar y DCI indica habilitar/deshabilitar
• FFS: Opción 4: MAC-CE indica habilitar/deshabilitar
• FFS: Opción 5: RRC configura la función habilitar/deshabilitar y MAC-CE indica habilitar/deshabilitar Acuerdos:
Para la repetición a nivel de ranura para PDSCH de grupo común de UEs RRC_CONNECTED, para indicar el número de repetición, seleccionar hacia abajo además entre:
• Opc. 1: por DCI
• Opc.2: por RRC
• Opc.3: por RRC+DCI
• FFS: Opc.4: por MAC-CE
• FFS: Opc. 5: por RRC+MAC-CE
• Detalles de FFS para cada opción.
• Mejoras adicionales de FFS para la configuración de la repetición a nivel de ranura
Acuerdos:
Desde la perspectiva de los UEs RRC_CONNECTED que reciben multidifusión, al menos para la transmisión inicial de esquema de PTM 1, soportes de retransmisión, para el propósito de selección descendente, las opciones son:
• Opción 1: PDSCH de grupo común programado por PDCCH de grupo común
• Opción 2: PDSCH programado por PDCCH específico de UE
o Alt 1: PDSCH es PDSCH específico de UE
° Alt 2: PDSCH es PDSCH de grupo común
• Opción 3: tanto opción 1 como opción 2
• FFS otras opciones
• Retransmisión basada en CBG de FFS
Acuerdos:
FFS si es necesaria una mejora de retroalimentación de CSI para MBS, que incluye pero no se limita a: • Nueva medición de CQI
• Nuevos formatos de reportes de CSI
• BLER direccionado
• Configuración de CSI-RS
• Activación de transmisión de A-CSI-RS
• Configuración de SRS
Acuerdos:
Para la retroalimentación de HARQ-ACK basada en ACK/NACK si se soporta, se soportan los libros de códigos de HARQ-ACK tanto de Tipo 1 como Tipo 2 para los UEs RRC_CON<n>E<c>TED que reciben multidifusión, • Detalles de FFS del diseño de libro de códigos de HARQ-ACK.
• FFS si se soporta o no el libro de códigos de HARQ-ACK mejorado de Tipo 2 y/o Tipo 3.
Acuerdos: Para UEs RRCJDLE/RRCJNACTIVE, soportar PDCCH de grupo común con CRC encriptado por un RNTI común para programar un PDSCH de grupo común, donde la encriptación del PDSCH de grupo común se basa en el mismo RNTI común.
• Detalles de FFS
Acuerdos:
• Para Ues RRCJDLE/RRCJNACTIVE, se soporta el barrido de haz para PDCCH/PDSCH de grupo común. o FFS: Detalles para el soporte de barrido de haz para PDCCH/PDSCH de grupo común.
Acuerdos: Para UEs RRC_IDLE/RRC_INACTIVE, definir/configurar recursos de frecuencia común para PDCCH/PDSCH de grupo común.
• el UE puede asumir la BWP inicial como el recurso de frecuencia común predeterminado para el PDCCH/PDSCH de grupo común, si no está configurado un recurso de frecuencia común específico.
• FFS: la relación de los recursos de frecuencia comunes (si están configurados) y la BWP inicial.
• FFS: si se configura uno o más recursos de frecuencia comunes
• FFS: detalles de configuración y definición del recurso de frecuencia común
Acuerdos: Desde la perspectiva de capa física, para la recepción de radiodifusión, el mismo PDCCH de grupo común y el PDSCH de grupo común programado correspondiente pueden recibirse mediante tanto los UEs RRC IDLE/RRC INACTIVE como UEs RRC CONNECTED.
• Detalles de FFS.
Acuerdos: Para UEs RRC_IDLE/RRC_INACTIVE, se soporta CSS para PDCCH de grupo común.
• FFS: reutilizar tipo de CSS actual, definir un nuevo tipo de CSS, etc.
• FFS otros detalles.
Acuerdos: Para UEs RRC_IDLE/RRC_INACTIVE, se puede configurar un CORESET dentro del recurso de frecuencia común para PDCCH/PDSCH de grupo común. CORESET0 se usa por defecto si el recurso de frecuencia común para PDCCH/PDSCH de grupo común es la BWP inicial y el CORESET no está configurado.
• FFS: detalles de configuración del CORESET para PDCCH/PDSCH de grupo común
<* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *>F<I>in de Cita [8]
*************************************
Las descripciones para introducir las mejoras especificadas sobre el soporte de MBS en NR[9] se citan a continuación:
************************************Inicio de Cita [9]
************************************
16.x MBS
16.x.1 General
Nota del editor: Aspectos generales que van a ser cubiertos aquí.
La sesión de MBS se define como una sesión de multidifusión o una sesión de radiodifusión. Una sesión de radiodifusión es para suministrar el servicio de comunicación de radiodifusión y una sesión de multidifusión es para suministrar el servicio de comunicación de multidifusión, donde el servicio de comunicación de radiodifusión es un servicio de comunicación en el cual el mismo servicio y los mismos datos de contenido específico se proporcionan simultáneamente a todos los UEs en un área geográfica y el servicio de comunicación de multidifusión es un tipo de servicio en el cual el mismo servicio y los mismos datos de contenido específico se proporcionan simultáneamente a un conjunto dedicado de UEs, como se especifica en TS 23XXX [xx].
Para la transmisión de servicio de MBS, los casos se pueden categorizar como sigue:
- En caso de una sesión de multidifusión con requisito de QoS de alta fiabilidad y/o baja latencia, el UE puede recibir datos de MBS en RRC_CONNECTED con mecanismos para garantizar el requisito de QoS requerido, por ejemplo, retroalimentación/retransmisión y/o asistencia de PTP, si es necesario.
- En el caso de la transmisión de una sesión de radiodifusión con requisito de QoS de baja fiabilidad y/o tolerante a la latencia, el UE puede recibir datos de MBS en RRC _IDLE/r Rc_INACTIVE/RRC_CONNEc Te D y no se necesita asistencia de PTP para garantizar la fiabilidad.
************************************ Fin de Cita[9]*************************************
Problema y solución 1:
Actualmente, en NR Rel-15/16, si un grupo específico de UEs exige los mismos datos/servicio de la red al (aproximadamente) mismo tiempo, por ejemplo, un grupo específico de UEs que exige vídeos/imágenes/datos de generación de flujo en vivo del mismo evento, la red puede usar información de control de enlace descendente (DCI) dedicada del UE para cada UE en el grupo específico para transmitir el mismo/repetido bloque de datos, por ejemplo, el mismo/repetido bloque de transporte (TB), en el recurso de radio dedicado de cada UE con la información de control de enlace descendente dedicada y el bloque de datos para cada UE, en el grupo específico, que se encriptan por la identidad única de cada UE, por ejemplo, C-RNTI. Más específicamente, la red puede transmitir una información de control de enlace descendente dedicada al UE para cada UE en el grupo específico y programar diferentes PDSCHs que portan el mismo bloque de transporte encriptado por la identidad única de cada UE para cada UE. De esta forma, el mismo bloque de datos, por ejemplo, el mismo bloque de transporte, puede transmitirse muchas veces para cada UE en el grupo específico.
Actualmente, no hay ningún mecanismo para que la red programe en grupo un grupo específico de UEs con un único bloque de datos de grupo común. En otras palabras, no hay ningún mecanismo para que la red transmita un único bloque de datos grupo común al grupo específico de UEs. Cuando el número de UEs en el grupo específico que demanda los mismos datos/servicio de la red al (aproximadamente) mismo tiempo se vuelve grande, las transmisiones dedicadas por UE de la información de control de enlace descendente y el mismo/repetido bloque de datos, por ejemplo, el mismo/repetido bloque de transporte, desde la red para cada UE en el grupo específico se vuelve ineficiente debido a que la red puede transmitir el mismo bloque de datos (bloque de transporte) muchas veces para cada UE en el grupo específico y puede desperdiciar recursos de radio y/o potencia de transmisión.
En NR Rel-17, se introduce el ítem de trabajo de MBS para soportar la función de programación de grupos de red. Para un grupo específico de UEs que exigen el mismo bloque de datos (bloque de transporte) al (aproximadamente) mismo tiempo, la red puede usar/transmitir una única información de control de enlace descendente de "grupo común (GC)" para programar un único bloque de datos de "grupo común" (bloque de transporte) en el recurso de grupo común para el grupo específico de UEs, donde tanto la información de control de enlace descendente de "grupo común" como el bloque de datos de "grupo común" (bloque de transporte) son encriptados por un RNTI de "grupo común" (por ejemplo, un GC-RNTI) que puede configurarse por capas superiores y puede compartirse entre los UEs en el grupo específico. Aquí, para un grupo de UEs que exigen el mismo bloque de datos (bloque de transporte) al (aproximadamente) mismo tiempo y que monitorizan una información de control de enlace descendente de grupo común para programar un bloque de datos de grupo común, cada UE en el grupo está configurado con o pertenece a un grupo de servicios de multidifusión y radiodifusión (MBS) con un identificador de grupo común (por ejemplo, un GC-RNTI) compartido y conocido por cada UE en el grupo de MBS. Preferiblemente, un UE puede configurarse con un, o más de un, RNTI de grupo común, lo cual significa que el UE puede pertenecer a un, o más de un, grupo de MBS, donde cada grupo de MBS puede comprender diferentes conjuntos de UEs.
Con base en los acuerdos y supuestos de trabajo descritos anteriormente, está claro que un UE debe estar en el estado RRC_CONNECTED para recibir una sesión de multidifusión con un requisito de QoS de alta fiabilidad y/o baja latencia. También se acuerda que "Cuando no hay datos en curso para la sesión de multidifusión, el UE puede permanecer en RRC_CONNECTED". Sin embargo, se especifica en la especificación de RRC de NR, por ejemplo, TS 38.331 V16.3.1, que un UE deberá realizar las acciones tras pasar al estado RRC_IDLE tras recibir la expiración del dataInactivityTimer desde las capas inferiores mientras está en el estado RRC CONNECTED.
Hasta ahora, la especificación de MAC de NR actual, por ejemplo, TS 38.321 V16.3.0, considera solo el canal lógico de DTCH, canal lógico de DCCH, o canal lógico de CCCH como la condición para mantener el "dataInactivityTime", que se usa para controlar la transición de estado de RRC de UE. El canal lógico de DTCH, canal lógico de DCCH, o canal lógico de CCCH pueden usarse para el servicio de MBS si se utiliza un esquema de transmisión de PTP. Sin embargo, si el UE recibe el servicio de MBS a través de otros esquemas de transmisión (por ejemplo, esquema de transmisión de PTM 1), el nuevo portador de radio para el servicio de MBS (por ejemplo, MRB) puede mapearse a un nuevo canal lógico para el canal de tráfico de MBS (por ejemplo, MTCH) y/o canal de control de MBS (MCCH). En este caso, el UE puede no iniciar o reiniciar el dataInactivityTimer y el dataInactivityTimer puede expirar y provocar que el UE realice una transición de estado desde RRC_CONNECTED a RRC_IDLE. La transición de estado involuntaria puede provocar que el UE falle en recibir la sesión de multidifusión con un requisito de QoS de alta fiabilidad y/o baja latencia durante un período de tiempo.
Con el fin de resolver el problema de la "transición de estado involuntaria" descrita anteriormente, se proporcionan o implementan uno o más de los siguientes conceptos, mecanismos, métodos, y/o realizaciones.
Por ejemplo, aplicando uno o más de estos métodos propuestos, se evita la transición de estado de UE involuntaria y se reduce el riesgo de pérdida de paquetes debido a la transición de estado de UE involuntaria.
Con referencia a las figuras 9-10, un método de la presente invención es que además del canal lógico de DTCH, canal lógico de DCCH, o canal lógico de CCCH, el nuevo canal lógico para tráfico de MBS (por ejemplo, MTCH) y/o control de MBS (por ejemplo, MCCH) se consideran como la condición de mantenimiento del dataInactivityTimer, que se usa para controlar la transición de estado de RRC de UE.
Realizaciones pueden incluir un dispositivo (por ejemplo, UE) configurado por un nodo de red a través de una señalización con una funcionalidad, en donde la funcionalidad está asociada con un temporizador. El dispositivo recibe un paquete, en donde el paquete contiene una o más cargas útiles, y la carga útil se mapea a un canal lógico, en donde el canal lógico se usa para servicio de multidifusión y/o radiodifusión, y el dispositivo inicia o reinicia el temporizador.
Para el proceso de ejemplo 1000 de la figura 9, el dispositivo es un UE en estado RRC_CONNECTED y configurado con un dataInactivityTimer en la etapa 1002. Una entidad de MAC del UE recibe una SDU de MAC para un canal lógico de tráfico de MBS en la etapa 1004, y el UE inicia o reinicia el dataInactivityTimer en la etapa 1006.
Para el proceso de ejemplo 1010 de la figura 10, el dispositivo es un UE en estado RRC CONNECTED y configurado con un dataInactivityTimer en la etapa 1012. Una entidad de MAC del UE recibe una SDU de MAC para un canal lógico de control de MBS en la etapa 1014, y el UE inicia o reinicia el dataInactivityTimer en la etapa 1016.
Preferiblemente, el dispositivo es un UE y/o el nodo de red es un gNB.
Preferiblemente, la señalización es un mensaje de RRC.
Preferiblemente, la funcionalidad es sobre, incluyendo, o está relacionada con la monitorización y operación de inactividad de datos.
Preferiblemente, el temporizador es un data-InactivityTimer, en donde el data-InactivityTimer controla el comportamiento de la transición de estado de RRC si el data-InactivityTimer expira.
Preferiblemente, si el data-Inactivity Timer expira, el dispositivo realiza la transición de estado de RRC al estado RRC_IDLE.
Preferiblemente, el paquete es una unidad de datos de protocolo (PDU) de control de acceso al medio (MAC).
Preferiblemente, la carga útil es una unidad de datos de servicio (SDU) de MAC.
Preferiblemente, el canal lógico es el canal de tráfico de MBS (MTCH) y/o canal de control de MBS (MCCH).
Con referencia de vuelta a las figuras 3 y 4, en una o más realizaciones, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para (i) configurar el dispositivo 300, mediante un nodo de red, a través de una señalización con una funcionalidad, en donde la funcionalidad está asociada con un temporizador, (ii) recibir un paquete, en el dispositivo 300, en donde el paquete contiene una o más cargas útiles, y la carga útil se mapea a un canal lógico, en donde el canal lógico es usado para servicio de multidifusión y/o radiodifusión, y (iii) iniciar o reiniciar el temporizador en el dispositivo 300. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones, etapas, y métodos descritos que se describen en este documento.
Con referencia a la figura 11, otro método de la presente invención es que el valor "infinito" se puede aplicar al valor del dataInactivityTimer. Preferiblemente, el valor "infinito" se aplica al valor del dataInactivityTimer configurado por RRC con una funcionalidad de monitorización de inactividad de Datos durante las etapas de proceso del UE que inicia el servicio de MBS.
Realizaciones pueden incluir un dispositivo (por ejemplo, UE) configurado por un nodo de red a través de una primera señalización con una funcionalidad, en donde la funcionalidad está asociada con un temporizador. El dispositivo es configurado por el nodo de red a través de una segunda señalización para iniciar el servicio de multidifusión y/o radiodifusión, y el dispositivo aplica un valor "infinito" al temporizador.
Para el proceso de ejemplo 1020 de la figura 11, el dispositivo es un UE en estado RRC_CONNECTED y configurado con un dataInactivityTime en la etapa 1022, el UE recibe una señalización para iniciar una sesión de MBS (y/o el UE almacena el valor original de dataInactivityTimer) en la etapa 1024, y el UE aplica el valor "infinito" al dataInactivityTimer en la etapa 1026.
Preferiblemente, el dispositivo almacena además el valor original del temporizador antes de aplicar el valor "infinito" al temporizador.
Preferiblemente, el dispositivo es configurado además por el nodo de red a través de una tercera señalización para cerrar el servicio de multidifusión y/o radiodifusión, y el dispositivo restaura el valor original del temporizador al temporizador.
Preferiblemente, el dispositivo es configurado además por el nodo de red a través de una tercera señalización para cerrar el servicio de multidifusión y/o radiodifusión, y el dispositivo aplica el valor incluido en la tercera señalización al temporizador.
Preferiblemente, el dispositivo es un UE y/o el nodo de red es un gNB.
Preferiblemente, la primera señalización y/o la segunda señalización y/o la tercera señalización es un mensaje de RRC.
Preferiblemente, la funcionalidad es sobre, que incluye, o está relacionada con la monitorización y operación de inactividad de datos.
Preferiblemente, el temporizador es un data-InactivityTimer, en donde el data-InactivityTimer controla el comportamiento de la transición de estado de RRC si el data-InactivityTimer expira.
Preferiblemente, si el data-Inactivity Timer expira, el dispositivo realiza la transición de estado de RRC al estado RRC_IDLE.
Con referencia de vuelta a las figuras 3 y 4, en una o más realizaciones, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para (i) configurar el dispositivo 300, mediante un nodo de red, a través de una señalización con una funcionalidad, en donde la funcionalidad está asociada con un temporizador, (ii) configurar el dispositivo 300, mediante el nodo de red, a través de una segunda señalización para iniciar el servicio de multidifusión y/o radiodifusión, y (iii) aplicar un valor "infinito" al temporizador. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones, etapas, y métodos descritos que se describen en este documento.
Con referencia a la figura 12, otro método de la presente invención es que la configuración del dataInactivityTimer se retira durante la unión de UE al servicio de MBS. Preferiblemente, el estado del dataInactivityTimer configurado por RRC con una funcionalidad de monitorización de inactividad de Datos se cambia para que esté "no configurado" durante las etapas de proceso del UE que inicia el servicio de MBS.
Realizaciones pueden incluir un dispositivo (por ejemplo, UE) configurado por un nodo de red a través de una primera señalización con una funcionalidad, en donde la funcionalidad está asociada con un temporizador. El dispositivo es configurado por el nodo de red a través de una segunda señalización para iniciar el servicio de multidifusión y/o radiodifusión, y el dispositivo retira la configuración de la funcionalidad de acuerdo con la segunda señalización.
Para el proceso de ejemplo 1030 de la figura 12, el dispositivo es un UE configurado con funcionalidad de monitorización de inactividad de Datos en estado RRC_CONNECTED en la etapa 1032, el UE recibe una señalización para iniciar una sesión de MBS (y/o el UE almacena la configuración original de funcionalidad de inactividad de Datos) en la etapa 1034, y el UE retira la configuración de la funcionalidad de monitorización de inactividad de Datos en la etapa 1036.
Preferiblemente, el dispositivo almacena además la configuración original de la funcionalidad.
Preferiblemente, el dispositivo es configurado además por el nodo de red a través de una tercera señalización para cerrar el servicio de multidifusión y/o radiodifusión, y el dispositivo recupera la configuración original de la funcionalidad.
Preferiblemente, el dispositivo es configurado además por el nodo de red a través de una tercera señalización para cerrar el servicio de multidifusión y/o radiodifusión, y el dispositivo está configurado con la funcionalidad de acuerdo con la tercera señalización.
Preferiblemente, el dispositivo es un UE y/o el nodo de red es un gNB.
Preferiblemente, la primera señalización, y/o la segunda señalización, y/o la tercera señalización es un mensaje de RRC.
Preferiblemente, la funcionalidad es sobre, que incluye, o está relacionada con la monitorización y operación de la inactividad de datos.
Preferiblemente, el temporizador es un data-InactivityTimer, en donde el data-InactivityTimer controla el comportamiento de la transición de estado de RRC si el data-InactivityTimer expira.
Preferiblemente, si el data-Inactivity Timer expira, el dispositivo realiza la transición de estado de RRC al estado RRC_IDLE.
Con referencia de vuelta a las figuras 3 y 4, en una o más realizaciones, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para (i) configurar el dispositivo 300, mediante un nodo de red, a través de una primera señalización con una funcionalidad, en donde la funcionalidad está asociada con un temporizador, (ii) configurar el dispositivo 300, mediante el nodo de red, a través de una segunda señalización para iniciar el servicio de multidifusión y/o radiodifusión, y (iii) retirar la configuración de la funcionalidad de acuerdo con la segunda señalización. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones, etapas, y métodos descritos que se describen en este documento.
Hay que anotar que cualquiera de los métodos, alternativas, etapas, ejemplos, y realizaciones propuestos en este documento se pueden aplicar de manera independiente, individual, y/o con múltiples métodos, alternativas, etapas, ejemplos, y realizaciones combinados juntos.
Problema y solución 2:
Con base en los acuerdos y supuestos de trabajo descritos anteriormente, está claro que los recursos de frecuencia para el servicio de MBS están relacionados con al menos una Parte de Ancho de Banda (BWP) y el UE debe conocer esa BWP para recibir el servicio de MBS. Como ejemplo, para UEs RRCJDLE/RRCJNACTIVE, los recursos de frecuencia para el servicio de MBS están relacionados con la BWP inicial. Como otro ejemplo, para UEs RRC-CONNECTED, los recursos de frecuencia para el servicio de MBS están relacionados con una BWP de unidifusión dedicada.
Para recibir el servicio de MBS, el UE necesita conocer el valor de RNTI específico para recuperar el PDCCH y/o PDSCH encriptados. Como ejemplo, para UEs RRCJDLE/RRCJNACTIVE, se soporta que un PDCCH de grupo común con CRC encriptado por un RNTI común programe un PDSCH de grupo común, donde la encriptación del PDSCH de grupo común se basa en el mismo RNTI. Como otro ejemplo, para UEs RRC-CONNECTED en el mismo grupo de MBS, el "esquema de transmisión de PTM 1" usa PDCCH de grupo común con CRC encriptado por RNTI de grupo común para programar PDSCH de grupo común que está encriptado con el mismo RNTI de grupo común. El "esquema de transmisión de PTM 1" también se denomina "esquema de programación de grupo basado en PDCCH de grupo común". Como otro ejemplo, para UEs RRC-CONNECTED en el mismo grupo de MBS, el "esquema de transmisión de PTM 2" usa PDCCH específico de UE con CRC encriptado por RNTI específico de UE (por ejemplo, C-RNTI) para programar PDSCH de grupo común que se encripta con el mismo RNTI de grupo común. El "esquema de transmisión de PTM 2" también se denomina "esquema de programación de grupo basado en PDCCH específico de UE". Como otro ejemplo, para UEs RRC-CONNEC<t>E<d>, la "transmisión de PTP" usa PDCCH específico de UE con CRC encriptado por RNTI específico de UE (por ejemplo, C-RNTI) para programar PDSCH específico de UE que está encriptado con el mismo RNTI específico de UE.
Hasta ahora, la especificación de MAC de NR actual, por ejemplo, TS 38.321 V16.3.0, considera solo C-RNTI y/o CS-RNTI como la condición para mantener el "bwp-InactivityTimer", que se usa para controlar la conmutación de BWP. Se conoce que C-RNTI y/o CS-RNTI se usan para transmisión de unidifusión y también se usa unidifusión como transmisión de PTP para servicio de MBS. Sin embargo, si el UE recibe el servicio de MBS a través de otro esquema de transmisión (por ejemplo, esquema de transmisión de PTM), se usa el nuevo RNTI de grupo común (por ejemplo, GC-RNTI) en lugar de C-RNTI y/o CS-RNTI. En este caso, el UE puede no iniciar ni reiniciar el "bwp-InactivityTimer" y el "bwp-InactivityTimer" puede expirar y hacer que el UE realice la conmutación de BWP a una BWP indicada por el defaultDownlinkBWP-Id si el defaultDownlinkBWP-Id está configurado, o conmutar al initialDownlinkBWP si el defaultDownlinkBWP-Id no está configurado. El comportamiento de conmutación involuntaria de BWP puede hacer que el UE falle en recibir la transmisión de enlace descendente en la BWP antes de la conmutación involuntaria durante un período de tiempo.
Con el fin de resolver el problema de la "conmutación involuntaria de BWP" descrita anteriormente, se proporcionan o implementan uno o más de los siguientes conceptos, mecanismos, métodos, y/o realizaciones. Por ejemplo, al aplicar uno o más de estos métodos propuestos, se evita la conmutación involuntaria de BWP y se reduce el riesgo de pérdida de paquetes debido a la conmutación involuntaria de BWP.
Con referencia a la realización de ejemplo de la figura 13, un método de la presente invención es que además del C-RNTI y/o CS-RNTI, el nuevo RNTI de grupo común (por ejemplo, GC-RNTI) se considera como la condición de mantener el "bwp-InactivityTimer", que se usa para controlar la conmutación de BWP. Preferiblemente, un PDCCH dirigido al nuevo RNTI de grupo común (por ejemplo, GC-RNTI) que indica la asignación de enlace descendente o la concesión de enlace ascendente se recibe en la BWP activa y se considera como la condición para iniciar o reiniciar el bwp-InactivityTimer asociado con la BWP de DL activa.
Realizaciones pueden incluir un dispositivo (por ejemplo, UE) configurado con al menos una celda de servicio activada, en donde la celda de servicio activada está configurada con una o múltiples BWPs. El dispositivo monitoriza PDCCH en una BWP activa, en donde la BWP activa es una de la BWP configurada, y la BWP activa incluye una BWP de DL activa, y en donde la BWP de DL activa está asociada con un temporizador. El dispositivo recibe una información desde PDCCH, en donde la recepción desde PDCCH se dirige a un RNTI de grupo común (GC-RNTI), y la información indica la asignación de enlace descendente o concesión de enlace ascendente en la BWP activa. El dispositivo inicia o reinicia el temporizador asociado con la BWP de DL activa.
Para el proceso de ejemplo 2000 de la figura 13, el dispositivo es un UE que monitoriza el PDCCH en una Celda de Servicio activada configurada con un bwp-InactivityTimer en la etapa 2002, se recibe un PDCCH dirigido a GC-RNTI que indica una asignación de enlace descendente o una concesión de enlace ascendente en la BWP activa en la etapa 2004, y el UE inicia o reinicia el bwp-InactivityTimer asociado con la BWP de DL activa en la etapa 2006.
Preferiblemente, el dispositivo es un UE.
De acuerdo con la invención, el temporizador es un bwp-InactivityTimer, en donde preferiblemente el bwp-InactivityTimer activa el comportamiento de conmutación de BWP cuando el bwp-InactivityTimer expira.
Preferiblemente, si el bwp-InactivityTimer expira, el dispositivo realiza la conmutación de BWP a otra BWP indicada por defaultDownlinkBWP-Id, en donde la BWP indicada por defaultDownlinkBWP-Id es una de la BWP configurada.
Preferiblemente, si el bwp-InactivityTimer expira, el dispositivo realiza la conmutación de BWP a la BWP indicada por initialDownlinkBWP, en donde la BWP indicada por initialDownlinkBWP es una de la BWP configurada.
Preferiblemente, la BWP activa incluye una BWP de DL activa y una BWP de UL activa.
Preferiblemente, la BWP de DL activa y la BWP de UL activa de la BWP activa están emparejadas.
Con referencia de vuelta a las figuras 3 y 4, en una o más realizaciones, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para (i) configurar el dispositivo 300 con al menos una celda de servicio activada, en donde la celda de servicio activada está configurada con una o múltiples BWPs, (ii) monitorizar PDCCH en una BWP activa, en donde la BWP activa es una de la BWP configurada, y la BWP activa incluye una BWP de DL activa, en donde la BWP de DL activa está asociada con un temporizador, (iii) recibir una información desde PDCCH, en donde la recepción desde PDCCH se dirige a un GC-RNTI, y la información indica una asignación de enlace descendente o concesión de enlace ascendente en la BWP activa, y (iv) iniciar o reiniciar el temporizador asociado con la BWP de DL activa. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones, etapas, y métodos descritos que se describen en este documento.
Otro método de la presente invención es que el valor "infinito" se puede aplicar al valor del bwp-InactivityTimer. Preferiblemente, el valor "infinito" se aplica al valor del bwp-InactivityTimer asociado con la BWP de<d>L activa durante las etapas de proceso del UE que inicia el servicio de MBS. Preferiblemente, el valor original del bwp-InactivityTimer asociado con la BWP de DL activa se recupera durante las etapas de proceso del UE que cierra el servicio de MBS.
Otro método de la presente invención es que la configuración del bwp-InactivityTimer se retira cuando el UE se une al servicio de MBS. Preferiblemente, el estado del bwp-InactivityTimer asociado con la BWP de DL activa de la celda de servicio se cambia para que esté "no configurado" durante las etapas de proceso del UE que inicia el servicio de MBS. Preferiblemente, el estado del bwp-InactivityTimer asociado con la BWP de DL activa de la celda de servicio se recupera durante las etapas de proceso del UE que cierra el servicio de MBS.
Hay que anotar que cualquiera de los métodos, alternativas, etapas, ejemplos, y realizaciones propuestos en este documento se pueden aplicar de manera independiente, individual, y/o con múltiples métodos, alternativas, etapas, ejemplos, y realizaciones combinados juntos.
Se han descrito anteriormente diversos aspectos de la divulgación. Debería ser evidente que las enseñanzas en este documento pueden realizarse en una amplia variedad de formas y que cualquier estructura, función, o ambas específicas que se divulgan en este documento son simplemente representativas. Con base en las enseñanzas en este documento un experto en la técnica debería apreciar que un aspecto divulgado en este documento puede implementarse independientemente de cualquier otro aspecto y que dos o más de estos aspectos pueden combinarse de diversas formas. Por ejemplo, se puede implementar un aparato o se puede practicar un método usando cualquier número de los aspectos establecidos en este documento. Además, tal aparato puede implementarse o tal método puede practicarse usando otra estructura, funcionalidad, o estructura y funcionalidad además de o aparte de uno o más de los aspectos establecidos en este documento. Como ejemplo de algunos de los conceptos anteriores, en algunos aspectos, se pueden establecer canales concurrentes con base en frecuencias de repetición de pulsos. En algunos aspectos, se pueden establecer canales concurrentes con base en la posición de pulso o en compensaciones. En algunos aspectos, se pueden establecer canales concurrentes con base en secuencias de saltos de tiempo. En algunos aspectos, se pueden establecer canales concurrentes con base en frecuencias de repetición de pulsos, posiciones o compensaciones de pulsos, y secuencias de saltos de tiempo.
Los expertos normales en la técnica entenderían que la información y señales pueden representarse usando cualquiera de una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, instrucciones, comandos, información, señales, bits, símbolos, y chips a los que se puede hacer referencia a lo largo de la descripción anterior pueden representarse mediante voltajes, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticas, o cualquier combinación de los mismos.
Los expertos normales en la técnica apreciarían 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 este 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 puede diseñarse usando codificación fuente o alguna otra técnica), diversas formas de programa o código de diseño que incorporan instrucciones (que en este documento pueden denominarse, por conveniencia, como "software" o un " módulo de software"), o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, se han descrito anteriormente diversos componentes, bloques, módulos, circuitos, y etapas ilustrativos generalmente en términos de su funcionalidad. Si tal funcionalidad se implementa como hardware o software depende de la aplicación particular y de las restricciones de diseño impuestas al sistema global. Las personas experimentadas pueden implementar la funcionalidad descrita de formas variables para cada aplicación particular, pero tales decisiones de implementación no deben interpretarse como que causan una desviación del alcance de la presente divulgación.
Además, los diversos bloques, módulos, y circuitos lógicos ilustrativos descritos en relación con los aspectos divulgados en este documento pueden implementarse dentro de o realizarse 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 de aplicación específica (ASIC), un arreglo de puertas programables en campo (FPGA) u otro dispositivo lógico programable, puerta discreta o lógica de transistor, componentes de hardware discretos, componentes eléctricos, componentes ópticos, componentes mecánicos, o cualquier combinación de los mismos diseñados para realizar las funciones descritas en este documento, y pueden ejecutar códigos o instrucciones que residen dentro del IC, fuera del IC, o ambos. Un procesador de propósito general puede ser un microprocesador, pero en la alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador, o máquina de estados convencional. Un procesador también puede implementarse 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 en conjunto con un núcleo de DSP, o cualquier otra de tal configuración.
Se entiende que cualquier orden o jerarquía específica de etapas en cualquier proceso divulgado es un ejemplo de un enfoque de muestra. Con base en las preferencias de diseño, se entiende que el orden o jerarquía específica de las etapas en los procesos se puede redisponer mientras que permanece dentro del alcance de la presente divulgación. Las reivindicaciones de método acompañantes presentan elementos de las diversas etapas en un orden de muestra, y no pretenden limitarse al orden o jerarquía específica presentada.
Las etapas de un método o algoritmo descrito en relación con los aspectos divulgados en este documento pueden realizarse directamente en hardware, en un módulo de software ejecutado por un procesador, o en una combinación de los dos. Un módulo de software (por ejemplo, incluyendo instrucciones ejecutables y datos relacionados) y otros datos pueden residir en una memoria de datos tal como memoria RAM, memoria flash, memoria ROM, memoria EPROM, memoria EEPROM, registros, un disco duro, un disco removible, un CD-ROM, o cualquier otra forma de medio de almacenamiento legible por ordenador conocido en la técnica. Se puede acoplar un medio de almacenamiento de muestras a una máquina tal como, por ejemplo, un ordenador/procesador (que se puede denominar en este documento, por conveniencia, como un "procesador'') de tal manera que el procesador pueda leer información (por ejemplo, código) desde y escribir información en el medio de almacenamiento. Un medio de almacenamiento de muestras puede ser integral al procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en el equipo de usuario. En la alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en el equipo de usuario. Además, en algunos aspectos, cualquier producto de programa de ordenador 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 de ordenador puede comprender materiales de empaquetado.

Claims (7)

REIVINDICACIONES
1. Un método para un dispositivo, que comprende:
configurar el dispositivo mediante un nodo de red con al menos una celda de servicio, en donde la celda de servicio está configurada con una o múltiples partes de ancho de banda, a continuación también denominadas BWPs, y un temporizador, y en donde la celda de servicio está activada;
monitorizar (2002) el canal de control de enlace descendente físico, a continuación también denominado como PDCCH, en una BWP, en donde la BWP está activa, y en donde la BWP activa es una de las BWPs configuradas y la BWP activa está asociada con un enlace descendente activo, a continuación también denominado como BWP de DL;
recibir (2004) una información desde PDCCH, en donde el PDCCH está dirigido a un RNTI de grupo común, a continuación también denominado como GC-RNTI, usado para servicio de multidifusión o radiodifusión, a continuación también denominado como MBS, y la información indica la asignación de enlace descendente en la BWP activa; e
iniciar o reiniciar (2006) el temporizador asociado con la BWP de DL activa en respuesta a la recepción de asignación de enlace descendente,
caracterizado porque
el temporizador es un bwp-InactivityTimer, y
si el bwp-InactivityTimer expira, el dispositivo realiza conmutación de BWP a una BWP indicada por defaultDownlinkBWP-Id, en donde la BWP indicada por defaultDownlinkBWP-Id es una de la BWP configurada; o si el bwp-InactivityTimer expira, el dispositivo realiza conmutación de BWP a una BWP indicada por initialDownlinkBWP, en donde la BWP indicada por initialDownlinkBWP es una de la BWP configurada.
2. El método de la reivindicación 1, en donde el dispositivo es un Equipo de Usuario, a continuación también denominado como UE.
3. El método de la reivindicación 1 o 2, en donde el nodo de red es un gNB.
4. El método de una cualquiera de las reivindicaciones 1 a 3, en donde la BWP activa está asociada con una BWP de DL activa y una BWP de UL activa.
5. El método de la reivindicación 4, en donde la BWP de DL activa y la BWP de UL activa de la BWP activa están emparejadas.
6. El método de una cualquiera de las reivindicaciones 1 a 5, en donde la información es una información de control de enlace descendente, a continuación también denominada como DCI.
7. Un dispositivo, que comprende:
una memoria (310); y
un procesador (308) acoplado operativamente a la memoria (310),
caracterizado porque
el procesador (308) está configurado para ejecutar código de programa (312) para realizar las etapas de método como se define en una cualquiera de las reivindicaciones precedentes.
ES22194432T 2021-01-15 2021-12-30 Método y aparato para controlar conmutación involuntaria de parte de ancho de banda, BWP, en un sistema de comunicación inalámbrica Active ES2983981T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163138075P 2021-01-15 2021-01-15
US202163143737P 2021-01-29 2021-01-29

Publications (1)

Publication Number Publication Date
ES2983981T3 true ES2983981T3 (es) 2024-10-28

Family

ID=79927437

Family Applications (1)

Application Number Title Priority Date Filing Date
ES22194432T Active ES2983981T3 (es) 2021-01-15 2021-12-30 Método y aparato para controlar conmutación involuntaria de parte de ancho de banda, BWP, en un sistema de comunicación inalámbrica

Country Status (5)

Country Link
US (2) US11470676B2 (es)
EP (2) EP4124161B1 (es)
KR (1) KR102930706B1 (es)
CN (1) CN114845322A (es)
ES (1) ES2983981T3 (es)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019216750A1 (ko) * 2018-05-09 2019-11-14 엘지전자 주식회사 무선 통신 시스템에서 상향링크 전송을 수행하는 방법 및 이를 위한 장치
WO2020220357A1 (zh) * 2019-04-30 2020-11-05 Oppo广东移动通信有限公司 Harq码本确定方法、终端设备和网络设备
US11582745B2 (en) * 2019-08-14 2023-02-14 Industrial Technology Research Institute Method for BWP operating and user equipment using the same
CN113260004A (zh) * 2020-02-13 2021-08-13 华为技术有限公司 一种通信方法及装置
US20210376967A1 (en) * 2020-06-02 2021-12-02 Electronics And Telecommunications Research Institute Method and apparatus for transmitting and receiving feedback signal in communication system
US12317158B2 (en) * 2020-11-16 2025-05-27 Ofinno, Llc Channel state information report for multicast and broadcast services
CN115088344A (zh) * 2021-01-13 2022-09-20 北京小米移动软件有限公司 广播多播业务数据接收方法及装置
US11665672B2 (en) * 2021-02-18 2023-05-30 Qualcomm Incorporated Techniques for channel state information feedback for sidelink communications
US12219435B2 (en) * 2021-03-04 2025-02-04 Sharp Kabushiki Kaisha Method and user equipment for management of MBS data reception
US20240163865A1 (en) * 2021-03-22 2024-05-16 JRD Communication (Shenzhen) Ltd. User equipment, base station, and wireless communication method
CN116868592A (zh) * 2021-03-26 2023-10-10 紫藤科技有限公司 针对nr多播和广播服务的bwp操作
EP4302492A4 (en) * 2021-04-01 2024-12-11 ZTE Corporation MULTICAST BROADCAST SERVICE RECEPTION AVAILABILITY
US11937236B2 (en) * 2021-04-01 2024-03-19 Qualcomm Incorporated Acknowledgment feedback configuration for group-common downlink channels with repetitions
WO2022205367A1 (zh) * 2021-04-01 2022-10-06 Oppo广东移动通信有限公司 无线通信方法、终端设备和网络设备
US20240244640A1 (en) * 2021-04-26 2024-07-18 Lg Electronics Inc. Method and device for performing sl drx retransmission timer-based transmission resource reselection operation in nr v2x
US12567922B2 (en) * 2021-04-30 2026-03-03 Samsung Electronics Co., Ltd Method and device for rate matching for multicast and broadcast services
US12256398B2 (en) * 2021-05-10 2025-03-18 Qualcomm Incorporated Techniques for collecting sidelink channel feedback from a receiving UE
WO2022240180A1 (ko) * 2021-05-11 2022-11-17 엘지전자 주식회사 무선 통신 시스템에서 상향링크 송수신을 수행하는 방법 및 장치
WO2022236687A1 (en) * 2021-05-11 2022-11-17 Nokia Shanghai Bell Co., Ltd. Ue monitoring occasions with in rrc idle and inactive state
CN117730494A (zh) * 2021-08-06 2024-03-19 Lg 电子株式会社 无线通信系统中发送和接收pdsch的方法和设备
WO2023037296A1 (en) * 2021-09-08 2023-03-16 Lenovo (Singapore) Pte. Ltd. Timer expiration in response to receiving dci
US12495440B2 (en) * 2021-10-21 2025-12-09 Ofinno, Llc Two-step random access procedure with discontinuous reception
US12348320B2 (en) * 2021-12-29 2025-07-01 Qualcomm Incorporated Semi-persistent scheduling timer for reliable transmission
KR20230156258A (ko) * 2022-05-05 2023-11-14 아서스 테크놀러지 라이센싱 아이엔씨. 무선 통신 시스템에서 다중-trp에 관한 시간 정렬을 위한 방법 및 장치
US12273813B2 (en) 2022-08-16 2025-04-08 Qualcomm Incorporated User equipment (UE) power saving
US20240098759A1 (en) * 2022-09-19 2024-03-21 Qualcomm Incorporated Common time resources for multicasting
WO2024130598A1 (en) * 2022-12-21 2024-06-27 Shenzhen Tcl New Technology Co., Ltd. Notifying method of multicast session deactivation and apparatus
WO2025116538A1 (en) * 2023-11-28 2025-06-05 Samsung Electronics Co., Ltd. Method and apparatus for resuming radio resource control connection during multicast broadcast service in a wireless communication system

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9693306B2 (en) * 2012-07-11 2017-06-27 Blackberry Limited Mechanisms to support UE power preference signaling
US10869357B2 (en) * 2016-03-24 2020-12-15 Lg Electronics Inc. Method for configuring discontinuous reception in a communication system and device therefor
US10880786B2 (en) * 2016-11-11 2020-12-29 Lg Electronics Inc. Method for terminal performing cell reselection procedure, and device supporting same
US10602563B2 (en) * 2017-06-09 2020-03-24 Samsung Electronics Co., Ltd. Method and apparatus for supporting RLC UM mode operation in next generation mobile communication system
EP3679679B1 (en) * 2017-09-08 2025-03-26 IPLA Holdings Inc. Communications management using down link control information
US11219088B2 (en) * 2017-09-28 2022-01-04 Lg Electronics Inc. Method and apparatus for configuring release cause
US10693620B2 (en) * 2017-10-27 2020-06-23 Ofinno, Llc Bandwidth part configuration and operation
US10813137B2 (en) 2017-12-13 2020-10-20 Asustek Computer Inc. Method and apparatus of handling BWP inactivity timer during random access procedure in a wireless communication system
US10701734B2 (en) 2017-12-28 2020-06-30 Asustek Computer Inc. Method and apparatus of selecting bandwidth part for random access (RA) procedure in a wireless communication system
KR102596391B1 (ko) * 2018-01-05 2023-11-01 삼성전자 주식회사 무선 통신 시스템에서 개선된 통신 성능을 위한 방법 및 장치
WO2019135649A1 (ko) * 2018-01-05 2019-07-11 삼성전자 주식회사 무선 통신 시스템에서 개선된 통신 성능을 위한 방법 및 장치
KR102433768B1 (ko) * 2018-03-28 2022-08-19 삼성전자주식회사 무선 통신 시스템에서 측정을 위한 장치 및 방법
US10880949B2 (en) * 2018-05-15 2020-12-29 Comcast Cable Communications, Llc Multiple active bandwidth parts
US11452169B2 (en) * 2018-08-15 2022-09-20 Google Llc Preventing inadvertent idle mode in multi-node connectivity environments
KR102910138B1 (ko) * 2018-09-18 2026-01-09 삼성전자주식회사 V2x 통신을 위한 자원 할당 및 대역폭 부분 비활성 타이머 처리 방법 및 장치
US11310723B2 (en) * 2018-09-26 2022-04-19 Ofinno, Llc Bandwidth part and uplink carrier switching
JP7455820B2 (ja) * 2018-09-26 2024-03-26 インターデイジタル パテント ホールディングス インコーポレイテッド Ｎｒ－ｕ ｌｂｔ ｍａｃ手順
WO2020175923A1 (ko) * 2019-02-26 2020-09-03 엘지전자 주식회사 무선 통신 시스템에서 동작 모드 전환 방법 및 이에 대한 장치
US11317335B2 (en) * 2019-03-29 2022-04-26 Samsung Electronics Co., Ltd. Method and apparatus for executing conditional handover in wireless communication network
US11805528B2 (en) * 2019-05-13 2023-10-31 Qualcomm Incorporated Communication preemption applicability techniques
US11374626B2 (en) * 2019-08-16 2022-06-28 Lg Electronics Inc. Method and apparatus for performing communication using multiple transmission layer configurations per bandwidth part in wireless communication system
EP4029348B1 (en) * 2019-09-12 2025-09-10 Lenovo (Singapore) Pte. Ltd. Reporting transmission for discontinuous reception
MX2022008390A (es) * 2020-01-10 2022-08-08 Fg innovation co ltd Metodo y equipo de usuario para recepcion de datos de servicio de multidifusion/difusion.
WO2021217571A1 (zh) * 2020-04-30 2021-11-04 北京小米移动软件有限公司 终端状态切换处理、控制方法及装置、通信设备及介质
JP2023102794A (ja) * 2020-06-08 2023-07-26 シャープ株式会社 端末装置、方法、および、集積回路
KR102789480B1 (ko) * 2020-06-19 2025-04-03 삼성전자 주식회사 차세대 이동 통신 시스템에서 멀티캐스트 서비스를 위한 이동성 지원 방법 및 장치
CN113873687B (zh) * 2020-06-30 2025-03-14 展讯通信（上海）有限公司 状态转换方法及链接态mtch的指示方法、装置、存储介质、终端、基站
US20210409984A1 (en) * 2020-06-30 2021-12-30 Samsung Electronics Co., Ltd. Method of monitoring data inactivity and an electronic device performing the method
US11622414B2 (en) * 2020-07-17 2023-04-04 Qualcomm Incorporated Enhanced connection release techniques for wireless communications systems
US11856630B2 (en) * 2020-07-22 2023-12-26 Samsung Electronics Co., Ltd. Method and apparatus for handling a protocol supporting suspension and resumption of secondary cell group (SCG) in dual connectivity technology supported by next-generation mobile communication system
EP4118862B1 (en) * 2020-10-16 2024-12-25 Ofinno, LLC Bandwidth part for multicast and broadcast services
US11979853B2 (en) * 2020-10-23 2024-05-07 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving a signal in the wireless communication system
WO2022125540A1 (en) * 2020-12-07 2022-06-16 Ofinno, Llc Power saving operation for multicast and broadcast services
KR20220102002A (ko) * 2021-01-12 2022-07-19 삼성전자주식회사 무선 통신 시스템에서 이중 접속을 수행하는 방법 및 장치

Also Published As

Publication number Publication date
US11470676B2 (en) 2022-10-11
KR102930706B1 (ko) 2026-02-25
US20220232658A1 (en) 2022-07-21
EP4030865A1 (en) 2022-07-20
EP4124161A3 (en) 2023-06-07
CN114845322A (zh) 2022-08-02
EP4124161A2 (en) 2023-01-25
EP4124161B1 (en) 2024-05-08
KR20220103625A (ko) 2022-07-22
US20220394805A1 (en) 2022-12-08

Similar Documents

Publication Publication Date Title
ES2983981T3 (es) Método y aparato para controlar conmutación involuntaria de parte de ancho de banda, BWP, en un sistema de comunicación inalámbrica
CN114982321B (zh) 用于多播/广播服务数据接收的方法和用户设备
US11889577B2 (en) Methods for handling periodic radio access network notification area (RNA) update configuration upon reject
ES3012506T3 (en) Method and apparatus for improving pdcch monitoring pattern in a wireless communication system
US20250267764A1 (en) Multicast broadcast services notification and operation in inactive state
US20250254710A1 (en) Enhanced resource allocation for multicast broadcast services
EP4211934A1 (en) System and method for maintaining multicast broadcast service continuity in idle and inactive states
US11877238B2 (en) Power saving for multicast broadcast services
ES3041250T3 (en) Method and apparatus for handling discontinuous reception (drx) timer for data reception of unicast and multicast in a wireless communication system
JP2023540106A (ja) マルチキャスト及びブロードキャスト構成シグナリング
US12604366B2 (en) Multicast service delivery for use in inactive state
EP4335238A1 (en) Small data transmission
WO2018030305A1 (ja) 無線端末及び基地局
US12335818B2 (en) Packet data convergence protocol (PDCP) enhancement for multicast and broadcast services
US12245303B2 (en) Radio link control (RLC) enhancements for multicast and broadcast services
US12538100B2 (en) Beam-based counting indication for multicast broadcast services
EP4338332A1 (en) Enhanced retransmission for sidelink communications
CN116806053A (zh) 无线通信系统中用于移动终止的小数据传送的方法和设备
HK40077456A (en) Method and apparatus for controlling ue state transition in a wireless communication system