ES2934143T3 - Procedimiento y aparato para solicitar la configuración del portador de radio de enlace lateral (SLRB) de la transmisión de unidifusión en un sistema de comunicación inalámbrica - Google Patents

Procedimiento y aparato para solicitar la configuración del portador de radio de enlace lateral (SLRB) de la transmisión de unidifusión en un sistema de comunicación inalámbrica Download PDF

Info

Publication number
ES2934143T3
ES2934143T3 ES20170006T ES20170006T ES2934143T3 ES 2934143 T3 ES2934143 T3 ES 2934143T3 ES 20170006 T ES20170006 T ES 20170006T ES 20170006 T ES20170006 T ES 20170006T ES 2934143 T3 ES2934143 T3 ES 2934143T3
Authority
ES
Spain
Prior art keywords
slrb
message
configuration
link
qos
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
ES20170006T
Other languages
English (en)
Inventor
Li-Te Pan
Richard Lee-Chee Kuo
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 ES2934143T3 publication Critical patent/ES2934143T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H04W28/0263—Traffic management, e.g. flow control or congestion control per individual bearer or channel involving mapping traffic to individual bearers or channels, e.g. traffic flow template [TFT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1221—Wireless traffic scheduling based on age of data to be sent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/535—Allocation or scheduling criteria for wireless resources based on resource usage policies
    • 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/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Landscapes

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

Abstract

Se describen un método y un aparato desde la perspectiva de un primer UE (equipo de usuario) para solicitar la configuración SLRB (portador de radio de enlace lateral) para un enlace de unidifusión con un segundo UE. En una realización, el método incluye que el primer UE reciba un primer mensaje del segundo UE, en el que el primer mensaje incluye una primera configuración de SLRB para el enlace de unidifusión (2505). El método incluye además que el primer UE transmita un segundo mensaje a un nodo de red para solicitar una segunda configuración de SLRB para el enlace de unidifusión cuando se recibe el primer mensaje o se confirma una transmisión exitosa de un mensaje completo asociado con el primer mensaje al segundo UE. (2510). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento y aparato para solicitar la configuración del portador de radio de enlace lateral (SLRB) de la transmisión de unidifusión en un sistema de comunicación inalámbrica
Esta divulgación se refiere en general a las redes de comunicación inalámbricas, y más particularmente, a un procedimiento y aparato para solicitar la configuración de SLRB de la transmisión de unidifusión en un sistema de comunicación inalámbrica.
Con el rápido aumento de la demanda para la comunicación de grandes cantidades de datos hacia y desde los dispositivos de comunicación móvil, las redes de comunicación de voz móvil tradicionales evolucionan hacia redes que se comunican con paquetes de datos de Protocolo de Internet (IP). Tal comunicación de paquetes de datos de IP puede proporcionar a los usuarios de los dispositivos de comunicación móvil servicios de voz sobre IP, multimedia, multidifusión y comunicación bajo demanda.
Una estructura de red ilustrativa es una Red de acceso de radio terrestre universal evolucionada (E-UTRAN). El sistema E-UTRAN puede proporcionar un alto rendimiento de datos con el fin de realizar los servicios de voz sobre IP y multimedia mencionados anteriormente. Una nueva tecnología de radio para la próxima generación (por ejemplo, 5G) se analiza actualmente por la organización de estándares 3GPP. En consecuencia, los cambios al cuerpo actual del estándar 3GPP se presentan y consideran actualmente para evolucionar y finalizar con el estándar 3GPP.
El documento 3GPP R2-1900370 divulga que después de que llegan los paquetes, un UE puede solicitar la configuración de un SLRB asociado con los perfiles de QoS de PC5 de los paquetes recibidos del gNB.
El documento 3GPP TR 23.786 V1.0.0 divulga las mejoras de arquitectura para los sistemas EPS y 5G para admitir los servicios V2X avanzados.
El documento EP 3101978 A1divulga un procedimiento de asignación de recursos y un equipo de asignación de recursos para la transmisión de señales D2D.
Sumario
Se divulgan un procedimiento y un aparato desde la perspectiva de un primer UE (Equipo de Usuario) para solicitar la configuración de SLRB (portador de radio de enlace lateral) para un enlace de unidifusión con un segundo UE y se definen en las reivindicaciones independientes. Las reivindicaciones dependientes definen las realizaciones preferentes de las mismas. En una realización, el procedimiento incluye que primer UE que recibe un primer mensaje del segundo UE, en el que el primer mensaje incluye una primera configuración de SLRB para el enlace de unidifusión. El procedimiento incluye además que el primer UE transmita un segundo mensaje a un nodo de red para solicitar una segunda configuración de SLRB para el enlace de unidifusión cuando se recibe el primer mensaje o se confirma una transmisión exitosa de un mensaje completo asociado con el primer mensaje al segundo UE.
Breve descripción de las figuras
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 (conocido también como red de acceso) y un sistema receptor (conocido también como equipo de usuario o UE).
La Figura 3 es un diagrama de bloques funcional de un dispositivo de comunicación de acuerdo con una realización ilustrativa de la invención reivindicada.
La Figura 4 es un diagrama de bloques funcional no reivindicado del código del programa de la Figura. 3.
La Figura 5 es una reproducción de la Figura 6.11.3.1-1 del 3GPP TR 23.786 V1.0.0.
La Figura 6 es una reproducción de la Figura 6.11.3.1-2 del 3GPP TR 23.786 V1.0.0.
La Figura 7 es una reproducción de la Figura 6.11.3.1-2 del 3GPP TR 23.786 V1.0.0.
La Figura 8 es una reproducción de la Figura 6.19.2.1.2-1 del 3GPP TR 23.786 V1.0.0.
La Figura 9 es una reproducción de la Figura A-1 del 3GPP R2-1900370.
La Figura 10 es una reproducción de la Figura A-2 del 3GPP R2-1900370.
La Figura 11 es una reproducción de la
Figure imgf000003_0001
Figura A-3 del 3GPP R2-1900370.
La Figura 12 es una reproducción de la
Figure imgf000003_0002
Figura 6-3 del 3GPP TS 36.300 V15.3.0.
La Figura 13 es una reproducción de la Figura 5.10.2-1 del 3GPP 36.331 V15.3.0.
La Figura 14 es una reproducción de la Figura 5.1.1.5.3-1 del 3GPP TS 23.303 V15.1.0.
La Figura 15 es una reproducción de la Figura 1 del 3GPP R2-1904094.
La Figura 16 es una reproducción de la Figura 2 del 3GPP R2-1904094.
La Figura 17 es una reproducción de la Figura 3 del 3GPP R2-1904094.
La Figura 18 es una reproducción de la Figura 4 del 3GPP R2-1904094.
La Figura 19 es una reproducción de la Figura 1 del 3GPP R2-1903227.
La Figura 20 es una reproducción de la Figura 5 del Resumen del 3GPP de la señalización [105bis#32]PC5-RRC.
La Figura 21 es una reproducción de la Figura 1 del Resumen del 3GPP de la señalización [105bis#32]PC5-RRC.
La Figura 22 es un diagrama de acuerdo con una realización ilustrativa de la invención reivindicada.
La Figura 23 es un diagrama de acuerdo con una realización ilustrativa no cubierta por la invención reivindicada. La Figura 24 es un diagrama de acuerdo con una realización ilustrativa no cubierta por la invención reivindicada. La Figura 25 es un diagrama de flujo de acuerdo con una realización ilustrativa de la invención reivindicada. La Figura 26 es un diagrama de flujo de acuerdo con una realización preferente de la invención reivindicada. Descripción detallada
Los dispositivos y sistemas de comunicación inalámbrica ilustrativos descritos más abajo emplean un sistema de comunicación inalámbrica, que soporta un servicio de difusió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 ser en base al 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 3GPP LTE (Evolución a largo plazo), 3GPP LTE-A o LTE-Advanced (Evolución a largo plazo avanzada), 3GPP2 UMB (Ultra banda ancha móvil), WiMáx, 3GPP NR (Nueva radio), o algunas otras técnicas de modulación. En particular, los dispositivos de sistemas de comunicación inalámbrica ilustrativos descritos más abajo pueden diseñarse para admitir uno o más estándares tal como el estándar ofrecido por un consorcio llamado "Proyecto de Asociación de 3ra Generación" denominado en la presente memoria como 3GPP, que incluye: 3GPP RAN2 #104 Nota del Presidente; TR 23.786 V1.0.0, "Estudio sobre las mejoras en la arquitectura de EPS y del sistema 5G para admitir servicios avanzados V2X"; TS 36.321 V15.3.0, " Acceso de Radio Terrestre Universal Evolucionado (E-UTRA); especificación del protocolo de control de acceso al medio (MAC)"; R2-1900370, " Resumen del debate por correo electrónico [104#58][NR V2X]- Soporte de QoS para NR V2X"; Ts 36.300 V15.3.0, "Acceso radioeléctrico terrestre universal evolucionado (E-UTRA) y red de acceso radioeléctrico terrestre universal evolucionado (E-UTRAN); descripción general"; TS 36.331 V15.3.0, " Acceso de Radio Terrestre Universal Evolucionado (E-UTRA); control de recursos radioeléctricos (RRC); Especificación del Protocolo"; TS 23.303 V15.1.0, "Servicios basados en la proximidad (ProSe); etapa 2"; R2-1904707, " Sobre los ID de la capa inferior", Ericson; TS 33.303 V15.0.0, " Servicios basados en la proximidad (ProSe); Aspectos de seguridad"; R2-1904094, "Soporte de RLC AM para la unidifusión y configuración de SLRB relacionado", Huawei; R2-1903227, "Contenido y manejo de la configuración PC5-RRC", MediaTek; y 3GPP Resumen de [105bis#32]Señalización PC5-RRC, OPPO.
La Figura 1 muestra un sistema de comunicación inalámbrica de acceso múltiple. Una red de acceso 100 (AN) incluye grupos de antenas múltiples, uno que incluye a 104 y a 106, otro que incluye a 108 y a 110, y uno adicional que incluye a 112 y a 114. En la Figura 1, sólo se muestran dos antenas para cada grupo de antenas, sin embargo, pueden utilizarse más o menos antenas para cada grupo de antenas. El terminal de acceso 116 (AT) 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 el terminal de acceso 116 a través del enlace inverso 118. El terminal de acceso (AT) 122 está en comunicación con las antenas 106 y 108, donde las antenas 106 y 108 transmiten información al terminal de acceso (AT) 122 a través del enlace directo 126 y reciben información desde el terminal de acceso (AT) 122 a través del enlace inverso 124. En un sistema FDD, los enlaces de comunicación 118, 120, 124 y 126 pueden usar una frecuencia diferente para la comunicación. Por ejemplo, el enlace directo 120 puede usar una frecuencia diferente a la usada por el enlace inverso 118.
Cada grupo de antenas y/o el área en la que se diseñan para comunicarse se refiere a menudo como un sector de la red de acceso. En la realización, cada uno de los grupos de antenas se diseñan para comunicarse con los terminales de acceso en un sector de las áreas cubiertas por la red de acceso 100.
En la comunicación a través de los enlaces directos 120 y 126, las antenas de transmisión de la red de acceso 100 pueden utilizar la conformación de haces con el fin de mejorar la relación señal-ruido de los enlaces directos para los terminales de acceso 116 y 122 diferentes. También, una red de acceso que usa la conformación de haces para transmitir a terminales de acceso dispersos aleatoriamente a través de su cobertura provoca menos interferencia a los terminales de acceso en las células vecinas que una red de acceso que transmite a través de una única antena a todos sus terminales de acceso.
Una red de acceso (AN) puede ser una estación fija o estación base usada para comunicarse con los terminales y puede denominarse también como un punto de acceso, un Nodo B, una estación base, una estación base mejorada, un Nodo B evolucionado (eNB), o alguna otra terminología. Un terminal de acceso (AT) puede llamarse también 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 un sistema transmisor 210 (conocido también como la red de acceso) y un sistema receptor 250 (conocido también como terminal de acceso (AT) o equipo de usuario (UE)) en un sistema 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.
Preferentemente, 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 en base a un esquema de codificación particular seleccionado para ese flujo de datos para proporcionar los datos codificados. Los datos codificados para cada flujo de datos pueden multiplexarse con datos piloto mediante el uso de técnicas OFDM. Los datos piloto son típicamente un patrón de datos conocido que se procesa de manera conocida y puede usarse en el sistema receptor para estimar la respuesta del canal. Los datos piloto y codificados multiplexados para cada flujo de datos entonces se modulan (es decir, se mapean símbolos) en base a un esquema de modulación particular (por ejemplo, BPSK, QPSK, M-PSK, o M-QAM) seleccionado para ese flujo de datos para proporcionar símbolos de modulación. La velocidad de datos, la codificación, y la modulación para cada flujo de datos puede determinarse mediante instrucciones realizadas por el procesador 230.
Los símbolos de modulación para todos los flujos de datos entonces se proporcionan a un procesador de TX MIMO 220, que puede procesar además los símbolos de modulación (por ejemplo, para OFDM). El procesador de TX MIMO 220 entonces proporciona Nt flujos de símbolos de modulación para Nt transmisores (TMTR) del 222a a través del 222t. En ciertas realizaciones, el procesador de TX MIMO 220 aplica los pesos de la conformación de haces a los símbolos de los flujos de datos y a la antena desde la que se transmite 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 condiciona además (por ejemplo, amplifica, filtra, y convierte) las señales analógicas para proporcionar una señal modulada adecuada para la transmisión a través del canal MIMO. Las señales moduladas Nt desde los transmisores del 222a a través del 222t entonces se transmiten desde las antenas Nt de la 224a a través de la 224t, respectivamente.
En el sistema receptor 250, las señales moduladas que se transmiten se reciben por las antenas Nr de la 252a a través de la 252r y la señal recibida desde cada antena 252 se proporciona a un receptor (RCVR) respectivo del 254a a través del 254r. Cada receptor 254 condiciona (por ejemplo, filtra, amplifica, y convierte descendentemente) una señal recibida respectiva, digitaliza la señal condicionada para proporcionar muestras, y procesa además las muestras para proporcionar un flujo de símbolos "recibidos" correspondiente.
Un procesador de datos de RX 260 entonces recibe y procesa los Nr flujos de símbolos recibidos desde Nr receptores 254 en base a una técnica de procesamiento del receptor particular para proporcionar flujos de símbolos Nt "detectados". El procesador de datos de RX 260 entonces demodula, 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 realizado por el procesador de TX MIMO 220 y el procesador de datos de TX 214 en el sistema transmisor 210.
Un procesador 270 determina periódicamente qué matriz de precodificación usar (se analiza a más abajo). El procesador 270 formula un mensaje de enlace inverso que comprende una porción del índice de la matriz y una porción del valor del rango.
El mensaje de enlace inverso puede comprender diversos tipos de información respecto al enlace de comunicación y/o el flujo de datos recibido. El mensaje de enlace inverso entonces se procesa por un procesador de datos de TX 238, que recibe además los datos de tráfico para un número de flujos de datos desde una fuente de datos 236, se modula por un modulador 280, se condiciona por los transmisores del 254a a través del 254r, y se transmite de vuelta al sistema transmisor 210.
En el sistema transmisor 210, las señales moduladas desde el sistema receptor 250 se reciben por las antenas 224, se condicionan por los receptores 222, se demodulan por un demodulador 240, y se procesan por un procesador de datos de RX 242 para extraer el mensaje del enlace inverso trasmitido por el sistema receptor 250. El procesador 230 entonces determina qué matriz de precodificación usar para determinar los pesos de la conformación de haces y entonces procesa el mensaje extraído.
Al volver 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 puede utilizarse para realizar los UE (o AT) 116 y 122 en la Figura 1 o la estación base (o AN) 100 en la Figura 1, y el sistema de comunicaciones inalámbricas es preferentemente el sistema LTE o 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 de procesamiento central (CPU) 308, una memoria 310, un código del programa 312, y un transceptor 314. El circuito de control 306 ejecuta el código del programa 312 en la memoria 310 a través de la CPU 308, que controla de esta 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, que entrega señales recibidas al circuito de control 306, y que emite señales generadas por el circuito de control 306 de manera inalámbrica. El dispositivo de comunicación 300 en un sistema de comunicación inalámbrica puede utilizarse también para realizar la a N 100 en la Figura 1.
La Figura 4 es un diagrama de bloques simplificado del código del programa 312 mostrado en la Figura 3. Como se muestra en la Figura 4, el código del programa 312 incluye una capa de aplicación 400, una porción de la Capa 3 402 y una porción de la Capa 2404, y se acopla a una porción de la Capa 1406. La porción de la Capa 3402 realiza en general el control de recursos de radio. La porción de la Capa 2 404 realiza en general el control de enlace. La porción de la Capa 1406 realiza en general las conexiones físicas.
Las técnicas de fondo de la presente invención se introducen y analizan en los siguientes párrafos:
La reunión 3GPP RAN2# 104 llegó a los siguientes acuerdos sobre las comunicaciones de enlace lateral NR eV2X, como se analiza en la nota del Presidente del 3GPP RAN2# 104:
Figure imgf000005_0001
3GPP TR 23.786 introdujo las siguientes soluciones para las comunicaciones eV2X:
6.11 Solución #11: Solución para unidifusión o multidifusión para la comunicación eV2X a través del punto de referencia PC5
6.11.1 Descripción Funcional
Esta solución aborda el Problema Clave # 1 sobre el soporte de la Comunicación de Grupo eV2X, el Problema Clave # 9 sobre el soporte de la comunicación de unidifusión/multidifusión a través de PC5 y el Problema Clave # 4 sobre el soporte de la mejora del marco QoS de PC5 para eV2X, centrándose en los siguientes aspectos:
- Identificadores para la comunicación de unidifusión, por ejemplo, ID de L2;
- Protocolo de señalización para admitir la comunicación de unidifusión/multidifusión;
- Soporte de QoS y configuraciones de la capa AS;
- Asociaciones de seguridad;
- Procedimientos para el mantenimiento y establecimiento del enlace.
6.11.2 Descripción de la solución
6.11.2.1 Identificadores para la comunicación de unidifusión
6.11.2.1.1 Separar el espacio de direcciones del ID de L2 para la unidifusión y la multidifusión de los de la difusión Uno de los identificadores esenciales para la comunicación de unidifusión/multidifusión es el ID de L2. A partir del diseño de ProSe en TS 23.303 [8], el espacio de direcciones del ID de L2 de destino para la comunicación uno a uno y las comunicaciones uno a muchos se separan con el mecanismo de la capa AS, es decir, el número de versión de la capa MAC. Esto se hace para evitar conflictos de la dirección usada que puedan dañar las comunicaciones uno a uno. De manera similar, la unidifusión V2X también debería usar los ID de L2 separados de los de difusión y multidifusión.
Esta separación se aplica tanto al ID de L2 de destino como al ID de L2 de origen. Para un UE que tiene tráfico tanto de difusión como de unidifusión/multidifusión, deben usarse diferentes ID de L2 con los formatos correspondientes. El ID de L2 de origen se usará por el UE par como el ID de L2 de destino en la comunicación de unidifusión. Los detalles de la gestión del ID de L2 relacionada para la unidifusión/multidifusión se describen en las cláusulas siguientes.
El UE puede usar un ID de L2 de origen distinto para diferentes enlaces de comunicación de unidifusión uno a uno, por ejemplo, cuando diferentes enlaces de unidifusión se asocian con diferentes identificadores de capa superior. 6.11.2.1.2 Decidir el ID de L2 de destino a usar para la comunicación de unidifusión/multidifusión
6.11.2.1.2.1 Opción A
En TS 23.285 [5], el ID de L2 de destino se decide por el UE en base a un mapeo configurado entre PSID/ITS-AID al ID de L2. Esto es adecuado para el tráfico de difusión, pero no funciona para el tráfico de unidifusión o multidifusión. En unidifusión o multidifusión, el ID de L2 de destino no se decidiría en base al PSID/ITS-AID. Debe permitirse que un UE V2X tenga múltiples conexiones de unidifusión o grupos de multidifusión soportados simultáneamente para un servicio en particular (PSID/ITS-AID). Por tanto, la información del ID de L2 de destino en este caso debe provenir de la capa superior. Esto significa que la interfaz entre la capa V2X y la capa superior debe mejorarse para permitir que dicha información se transmita junto con el paquete de datos.
Se espera que las aplicaciones V2X reales no entiendan la noción del ID de L2, ya que las aplicaciones pueden construirse para tecnologías o plataformas transversales. Por tanto, alguna capa de software intermedio dentro del UE tiene que traducir el identificador usado por la capa de aplicación, por ejemplo, el ID de la estación, al ID del L2 del V2X. Significa que dicha capa de software intermedio necesita mantener el mapeo de los identificadores de destino de la capa de aplicación y los ID de L2. Dado que esta capa de software intermedio está fuera del ámbito de SA2, en la memoria descriptiva puede anotarse como "capa superior" en general, y debe documentarse la suposición de que esta "capa superior" mantiene el mapeo y proporciona el ID de L2 para la comunicación de unidifusión o multidifusión.
6.11.2.1.2.2 Opción B
Una alternativa a la solución anterior es que la capa V2X administre dicho enlace de unidifusión/grupo de multidifusión para el mapeo de ID de L2. En ese caso, el enlace de unidifusión/grupo de multidifusión puede asignarse con un identificador de flujo en el momento del establecimiento. La información del perfil de conexión correspondiente, por ejemplo, el ID de L2, configuraciones de transmisión, parámetros de QoS, etc., podría asociarse con él. En tal caso, la capa superior solo necesita usar el identificador de flujo para indicar el destino y transmitirlo con el paquete de datos. La capa V2X aplicará la información de perfil asociada, que incluyen los ID de L2, para la transmisión. Esto permitiría la reutilización de los mecanismos de manejo de enlaces Uu, por ejemplo, similar a la de los flujos de QoS, y sería más extensible. De nuevo, la traducción de los identificadores de la capa de aplicación, por ejemplo, el ID de Estación, a este identificador de flujo tiene que realizarse por esta capa intermedia, es decir, la "capa superior".
6.11.2.2 Protocolo de señalización para admitir la comunicación de unidifusión/multidifusión
Para la comunicación de unidifusión o multidifusión, existe la necesidad de algún mensaje de control intercambiado entre los UE involucrados para establecer el enlace o grupo. Por tanto, se requiere algún protocolo de señalización. En la comunicación uno a uno ProSe definida en TS 23.303 [8], se introdujo un Protocolo de Señalización PC5 (cláusula 5.1.1.5.2), que se ejecuta a través de la capa PDCP. Aunque se define para uso ProSe, los mensajes podrían extenderse con el fin de usarse para la comunicación V2X. El diseño detallado del protocolo debe revisarse en base a los procedimientos de operación de unidifusión reales.
Otro enfoque alternativo es ejecutar RRC a través de PC5. Como el Protocolo de Señalización PC5 se usa a través de PDCP de todos modos, el protocolo RRC puede usarse para reemplazarlo. Aunque no se requieren todas las características de RRC para la operación de PC5, los mensajes de RRC relevantes del V2X seleccionados pueden ampliarse y usar, por ejemplo, SidelinkUElnformation, etc. La ventaja de eso es la unificación potencial de los protocolos de señalización de control para Uu y PC5.
Por tanto, en esta solución se introduce un protocolo de señalización a través de PC5 para la gestión de la comunicación de unidifusión/multidifusión.
6.11.2.3 Soporte de QoS y configuraciones de la capa AS;
Es deseable que la QoS pueda admitirse también en la comunicación de unidifusión y multidifusión.
En TS 23.285 [5], el modelo de QoS para la comunicación V2X se basa en el modelo por paquete, por ejemplo, PPPP y PPPR. Con la comunicación de unidifusión o multidifusión, debe discutirse si también debe admitirse un modelo de QoS orientado a la conexión similar al de la conexión Uu.
Como también se discutió en el Problema Clave #4, "Compatibilidad con la mejora del marco QoS de PC5 para eV2X", se espera que se requiera algo más que PPPP y PPPR existentes.
Específicamente para la unidifusión o la multidifusión, debido al enlace o al grupo implicado, la mayoría de los paquetes enviados por el mismo enlace de unidifusión entre un par de pares deberían tener las mismas características de QoS. Esto se acerca al modelo de conexión Uu, en lugar del tráfico normal basado en la difusión. Por tanto, aquí puede reutilizarse el concepto de gestión de la QoS del tipo Uu. Esto permite un modelo unificado para Uu y PC5.
Además, podría haber diferentes características de la capa AS que podrían ser opcionales o no compatibles con las anteriores. Por tanto, al establecer el enlace de unidifusión, dicha configuración también podría negociarse y configurarse junto con/o como parte del perfil de QoS.
NOTA: Se usa el modelo QoS para la unidifusión descrito en la Solución #19 (cláusula 6.19).
6.11.2.4 Asociaciones de seguridad
La comunicación de unidifusión o multidifusión también puede necesitar protección en la capa de enlace. La comunicación ProSe uno a uno soporta el establecimiento del enlace seguro L2, como se define en TS 33.303 [11]. Sin embargo, dentro del contexto de comunicación V2X, cada UE tiene los certificados correspondientes para la protección de la seguridad. Por tanto, puede haber una necesidad de mejorar o ajustar el protocolo de establecimiento del enlace seguro L2 existente con el fin de admitir el uso de tales asociaciones de seguridad. El manejo exacto de la seguridad debe analizarse y decidirse por el SA3. El diseño del SA2 debe alinearse con esas decisiones cuando estén disponibles.
6.11.2.5 Procedimientos para el mantenimiento y establecimiento del enlace.
TS 23.303 [8] ha definido los procedimientos para el mantenimiento y establecimiento de un enlace seguro L2 a través de PC5, como en la cláusula 5.4.5. Estos procedimientos pueden mejorarse y adaptarse para el uso del V2X, sujeto a las decisiones anteriores con respecto a la elección del protocolo de señalización, manejo de seguridad, etc. Sin embargo, se requieren algunas consideraciones adicionales para el V2X para el manejo del enlace/grupo. Para la comunicación V2X, no todos los UE admitirán o usarán la comunicación de unidifusión. Además, es posible que no todos los servicios se ejecuten en el mismo canal o RAT (por ejemplo, LTE V2X frente a NR V2X). Con V2X, no hay un canal de detección como el de ProSe (es decir, PC5-D), y no se supone que la configuración de la red sea como la del uso de seguridad pública. Por tanto, con el fin de apoyar el establecimiento del enlace, existe la necesidad de un anuncio de servicio para informar al par de la existencia del UE y la capacidad del UE para la comunicación de unidifusión, por ejemplo, el canal para operar o los servicios soportados, etc.
Dicho anuncio de servicio debe hacerse accesible a todos los UE que se interesen en usar el servicio. Por ejemplo, dicho anuncio podría configurarse para enviarse a través de un canal dedicado, de forma similar a como se maneja el Anuncio de Servicio WAVE (WSA), o para aprovecharse de los mensajes periódicos de los UE compatibles. NOTA 1: El anuncio de servicio se maneja por la capa superior y está fuera del ámbito de SA2.
Para el mantenimiento del enlace de la capa 2, se necesita la funcionalidad de mantenimiento activo para detectar cuando los UE no están en el rango de comunicación directa, de modo que puedan proceder con la liberación implícita del enlace de la capa 2.
NOTA 2: Se deja a la Etapa 3 determinar cómo se soporta la funcionalidad de mantenimiento.
6.11.3 Procedimientos
6.11.3.1 Establecimiento de enlace de la capa 2 a través de PC5
El procedimiento de establecimiento del enlace de la capa 2, tal como se define en TS 23.303 [8], cláusula 5.4.5.2, se puede reutilizar para el establecimiento del enlace de unidifusión eV2X, con las siguientes adaptaciones:
• Los mensajes pueden convertirse en mensajes de señalización RRC en lugar de mensajes de señalización PC5, según la decisión del RAN WG.
• El "establecimiento del enlace de la capa 2 orientado al UE" opera como se muestra a continuación y la Figura 6.11.3.1-1 muestra el procedimiento:
- El mensaje de Solicitud de Comunicación Directa puede enviarse por el UE-1 con un mecanismo de difusión, es decir, a una dirección de difusión asociada con la aplicación en lugar del ID de L2 del UE-2. El identificador superior del UE-2 se incluye en el mensaje de solicitud de comunicación directa para permitir que el UE-2 decida si responde a la solicitud. El ID de L2 de origen de este mensaje debe ser el ID de L2 de unidifusión del UE-1.
• El mensaje de solicitud de comunicación directa debe transmitirse mediante el uso de la configuración predeterminada de la capa AS, por ejemplo, la configuración de difusión, que puede entenderse por el UE-2. • El UE-2 usa el ID de L2 de origen del mensaje de solicitud de comunicación directa recibido como ID de L2 de destino en la señalización posterior al UE-1, y usa su propio ID de L2 de unidifusión como el ID de L2 de origen. El UE-1 obtiene el ID de L2 del UE-2 para futuras comunicaciones, para señalización y tráfico de datos.
[Figura 6.11.3.1-1 del 3GPP TR 23.786 V1.0.0, titulado "Procedimiento de establecimiento del enlace de la capa 2 orientado al UE", se reproduce como la Figura 5]
• El "establecimiento del enlace de la capa 2 orientado al servicio V2X" funciona igual que el "establecimiento del enlace de la capa 2 orientado al UE" con las siguientes diferencias y la Figura 6.11.3.1-2 muestra el procedimiento:
- La información sobre el Servicio V2X que solicita el establecimiento del enlace L2, es decir, la información sobre el Servicio V2X anunciado, se incluye en el mensaje de Solicitud de Comunicación Directa para permitir que otros UE decidan si responder a la solicitud.
- Los UE que se interesen en usar el Servicio V2X anunciado por el mensaje de Solicitud de Comunicación Directa pueden responder a la solicitud (el UE-2 y el UE-4 en la Figura 6.11.3.1-2).
- Después de establecer el enlace de la capa 2 con otros UE como se describe anteriormente, los nuevos UE pueden entrar en proximidad con el UE-1, es decir, el rango de comunicación directa del UE-1. En este caso, el UE-1 puede iniciar el procedimiento de establecimiento del enlace de la capa 2 orientado al servicio V2X ya que conoce los nuevos UE de los mensajes de la capa de aplicación enviados por los UE. O el nuevo Ue puede iniciar el procedimiento de establecimiento del enlace de la capa 2 orientado al servicio V2X. Por tanto, el UE-1 no tiene que seguir enviando un mensaje de Solicitud de Comunicación Directa periódicamente para anunciar el Servicio V2X que desea establecer un enlace L2 con otro UE para la unidifusión.
[Figura 6.11.3.1-2 del 3GPP TR 23.786 V1.0.0, titulado "Procedimiento de establecimiento del enlace de la capa 2 orientado al servicio V2X, se reproduce como la Figura 6]
El enlace de la capa 2 soporta el tráfico no IP. No se llevaría a cabo ningún procedimiento de negociación y asignación de direcciones IP.
6.11.3.2 Contenido del mensaje de señalización para el establecimiento del enlace
La información transportada en el mensaje de solicitud de comunicación directa definido en TS 24.334 [13] requiere al menos las siguientes actualizaciones:
• Para "establecimiento del enlace de la capa 2 orientado al UE",
- La Información de Usuario debe incluir el ID del UE de destino (identificación de la capa superior del UE-2), además del ID del UE iniciador (ID de la capa superior del UE-1).
NOTA: La etapa 3 puede decidir si estos ID pueden transportarse en el mismo IE o en IE separados, por ejemplo, el ID de Estación/ID Temporal del Vehículo solo necesita tener 4 octetos.
• Para "establecimiento del enlace de la capa 2 orientado al servicio V2X",
- La Información del Servicio Anunciado V2X debe incluir la información sobre el Servicio V2X que solicita el establecimiento del enlace L2, por ejemplo, PSID o ITS-AID de la aplicación V2X. Compartir sensores, y etc. puede ser el caso del Servicio V2X.
• La Configuración de la Dirección IP, que se especifica como obligatoria para ProSe, debe permitir una indicación de que no se usará ninguna IP, de modo que el UE receptor (por ejemplo, el UE-2) no inicie ningún procedimiento de configuración de IP para este enlace en particular.
• Los IE dedicados a la seguridad deben revisarse por el SA3, ya que el mecanismo de seguridad para eV2X puede ser diferente y requiere diferentes IE.
• La información de configuración adicional relativa al enlace, por ejemplo, cuando se utiliza el mensaje RRC puede haber configuraciones de la capa AS.
6.11.3.3 Procedimiento de actualización del identificador del enlace para la protección de la privacidad de la comunicación de unidifusión
[Figura 6.11.3.3-1 de 3GPP TR 23.786 V1.0.0, titulado "Procedimiento de actualización del identificador del enlace de la capa 2", se reproduce como la Figura 7]
Este procedimiento se usa para actualizar al par en la comunicación de unidifusión del cambio inminente de los identificadores usados para este enlace. Debido a los requisitos de privacidad, en el uso de eV2X, UE debe cambiar con frecuencia sus identificadores con el fin de evitar rastrearse por terceros. Cuando ocurre el cambio de identificador, todos los identificadores en todas las capas, es decir, desde el ID de la capa de aplicación hasta el ID de L2, deben cambiarse. Esta señalización es necesaria antes de que ocurran los cambios del identificador, para prevenir interrupciones del servicio.
1. El UE-1 decide el cambio de los identificadores, por ejemplo, debido al cambio del identificador de la capa superior o a un temporizador, e incluye los nuevos identificadores a utilizar (que incluyen los nuevos identificadores de la capa superior, la nueva dirección/prefijo IP si es una aplicación, los nuevos identificadores L2) en el mensaje de Solicitud de Actualización del Identificador de Enlace, y lo envía al UE-2 antes de que éste cambie los identificadores. Los nuevos identificadores a usar deben cifrarse para proteger la privacidad.
NOTA 1: El temporizador se ejecuta en un ID de L2 de Origen.
2. El UE-2 responde con un mensaje de Respuesta de Actualización del Identificador del Enlace. Tras la recepción del mensaje, el UE-1 y el u E-2 pueden comenzar a utilizar los nuevos identificadores para el tráfico de datos. El UE-1 recibirá tráfico en su antigua ID de L2 hasta que reciba la Respuesta de Actualización del ID del Enlace desde el UE-2.
NOTA 2: Si hay varios enlaces del UE-1 que usan los mismos identificadores de la capa superior o ID de L2, el UE-1 debe realizar el procedimiento de actualización en cada uno de los enlaces y, para cada enlace, debe seguir recibiendo tráfico en su antiguo ID de L2 para ese enlace específico hasta que reciba la Respuesta de Actualización del ID de Enlace.
6.11.3.4 Aspectos de seguridad para el enlace de la capa 2
Como las aplicaciones eV2X tienen certificados de seguridad asociados, el enlace de unidifusión puede reusarlos para derivar la asociación de seguridad para proteger la señalización o los datos del enlace de unidifusión.
6.11.4 Impacto en las entidades e interfaces existentes
Nota del editor: Se agregarán impactos en los nodos o la funcionalidad existentes.
6.11.5 Temas para estudio adicional
Nula.
6.11.6 Conclusiones
La solución documentada en las cláusulas 6.11.1 a 6.11.4 aborda todos los aspectos del Problema Clave #9 Soporte de unidifusión/multidifusión para compartir sensores a través de PC5, y debería pasar a la fase normativa. Los siguientes aspectos se actualizarán además en base a los comentarios de otros Grupos de Trabajo:
• la definición del mensaje de señalización para el establecimiento y la gestión del enlace de unidifusión, por ejemplo, si se usa la señalización RRC para el enlace de unidifusión y cómo;
• la elección del modelo de QoS por paquete o el modelo de QoS basado en portador para difusión, difusión en grupo y unidifusión en base a las decisiones de RAN;
• señal a la estación base sobre el servicio usado cuando se utiliza el modo programado de red;
• las posibles actualizaciones de procedimientos relacionados con la seguridad para la comunicación de unidifusión a través de PC5.
NOTA: La capa de aplicación puede usar un mecanismo de comunicación de unidifusión o difusión en grupo para diferentes aplicaciones, por ejemplo, aplicaciones de pelotones.
[...]
6.19 Solución #19: Soporte de QoS para la comunicación eV2X a través de la interfaz PC5
6.19.1 Descripción Funcional
6.19.1.1 Descripción general
Esta solución aborda el Problema Clave #4 (cláusula 5.4) Soporte de mejora del marco QoS de PC5 para eV2X. Los requisitos de QoS para eV2X son diferentes de los de EPS V2X, y se considera que los PPPP/PPPR definidos anteriormente en TS 23.285 [5] no satisfacen las necesidades. Específicamente, hay muchos más parámetros de QoS a considerar para los servicios eV2X. Esta solución propone utilizar 5QI para la comunicación eV2X a través de la interfaz PC5. Esto permite un modelo QoS unificado para servicios eV2X a través de diferentes enlaces.
6.19.1.2 Descripción de la solución
Los nuevos requisitos de servicio se capturaron en TS 22.186 [4]. Los nuevos KPI de rendimiento se especificaron con los siguientes parámetros:
• Carga útil (bytes);
• Tasa de transmisión (Mensaje/Seg);
• Latencia máxima de extremo a extremo (ms);
• Fiabilidad (%);
• Tasa de datos (Mbps);
• Rango de comunicación mínimo requerido (metros).
Note que el mismo conjunto de requisitos de servicio se aplica tanto a la comunicación V2X basada en PC5 como a la comunicación V2X basada en Uu. Como se analizó en la Solución #2 (cláusula 6.2), estas características de QoS podrían representarse bien con 5QI definido en TS 23.501 [7].
Por tanto, es posible tener un modelo de QoS unificado para PC5 y Uu, es decir, también usar 5QI para la comunicación V2X a través de PC5, de modo que la capa de aplicación pueda tener una forma consistente de indicar los requisitos de QoS independientemente del enlace usado. Esto no evita que la capa AS implemente diferentes mecanismos a través de PC5 y Uu para lograr los requisitos de QoS.
Considerando los UE compatibles con 5GS V2X, existen tres tipos diferentes de tráfico: difusión, multidifusión y unidifusión.
El UE-PC5-AMBR se aplica a todos los tipos de tráfico y se usa para la RAN para limitar la transmisión del UE PC5 en la gestión de recursos.
Para el tipo de tráfico de unidifusión, está claro que puede usarse el mismo modelo de QoS que el de Uu, es decir, cada uno de los enlaces de unidifusión podría tratarse como un portador, y los flujos de QoS podrían asociarse con él. Podrían aplicarse todas las características de QoS definidas en 5QI y el parámetro adicional de tasa de datos. Además, el rango de comunicación Mínimo requerido podría tratarse como un parámetro adicional específicamente para el uso de PC5.
Para el tráfico de difusión, no existe el concepto de portador. Por tanto, cada uno de los mensajes puede tener características diferentes de acuerdo con los requisitos de la aplicación. El 5QI debe utilizarse entonces de manera similar a la del PPPP/PPPR, es decir, para etiquetarse con cada uno de los paquetes. El 5QI es capaz de representar todas las características necesarias para el funcionamiento de la difusión del PC5, por ejemplo, la latencia, la prioridad, la fiabilidad, etc. Podría definirse un grupo específico de los 5QI de difusión V2X (es decir, los VQI) para el uso de PC5.
NOTA 1: El 5QI usado para PC5 puede ser diferente del usado para Uu incluso para el mismo servicio V2X, por ejemplo, el PDB para PC5 puede ser más largo que el de Uu ya que es un enlace directo. Los 5QI usados para PC5 se denominan VQI por diferenciación.
NOTA 2: Un mapeo entre los parámetros QoS de EPS V2X, por ejemplo, PPPP y PPPR, con los nuevos VQI, por ejemplo, similar a los 5QI no GBR definidos en TS 23.501 [7], se definirá en la fase normativa para la operación de difusión.
NOTA 3: La suposición de trabajo es que el diseño de NR PC5 soporta el uso de los 5QI del V2X.
NOTA 4: La capa AS puede manejar el tráfico de unidifusión, difusión en grupo y difusión teniendo en cuenta todas sus prioridades, por ejemplo, indicadas por VQI.
6.19.1.3 Valores 5QI del V2X (VQI) para el uso de difusión PC5
Se definirá un conjunto de nuevos VQI para uso del V2X en la fase normativa que refleje los requisitos de servicio documentados en TS 22.186 [4].
NOTA 1: La suposición de trabajo es que el VQI no estandarizado no es compatible con esta versión.
NOTA 2: El uso del modelo QoS por paquete o por flujo QoS depende de la decisión de la RAN.
6.19.2 Procedimientos
Nota del editor: Esta cláusula describe los procedimientos para usar el nuevo modelo QoS para la comunicación PC5. También depende del desarrollo de la RAN.
6.19.2.1 Soporte de QoS para la comunicación de unidifusión a través de la interfaz PC5
6.19.2.1.0 General
Para habilitar el soporte de QoS para la comunicación uno a uno de eV2X a través de la interfaz PC5, es necesario admitir los siguientes procedimientos.
Nota del editor: Los siguientes procedimientos pueden actualizarse además en función del progreso en el modelo QoS de PC5.
6.19.2.1.1 Suministro de parámetros de QoS a UE y NG-RAN
Los parámetros de QoS de PC5 y la regla de QoS de PC5 se proporcionan al UE como parte de los parámetros de autorización de servicio mediante el uso de la solución definida para el Problema Clave #5. La regla de QoS de PC5 se usa para mapea r los servicios V2X (por ejemplo, PSID o ITS-AID de la aplicación V2X) al flujo de QoS de PC5. Los parámetros de QoS de PC5 recuperados por el PCF de la UDR se proporcionan a la NG-RAN a través del AMF. El AMF almacena tal información como parte del contexto UE. Para los procedimientos posteriores (por ejemplo, la solicitud del servicio, el traspaso), la provisión de los parámetros de QoS de PC5 a través de N2 seguirá la descripción de la cláusula 6.6.2.
NOTA 1: La UE-PC5-AMBR se proporciona por el UDM y los detalles seguirán la descripción como por la Solución #6.
El suministro de parámetros de QoS de PC5 al UE y la NG-RAN podría activarse mediante el contenedor de políticas del UE incluido en el mensaje NAS proporcionado por el UE. El PCF envía al AMF los parámetros de QoS de PC5 actualizados para la NG-RAN cuando es necesario.
NOTA 2: Los parámetros detallados de QoS de PC5 usados por la NG-RAN se identificarán durante la fase de trabajo normativo.
NOTA 3: La NG-RAN se configura con parámetros estáticos para el modo de asignación de recursos programados de la red para admitir la QoS de PC5.
6.19.2.1.2 Negociación de parámetros de QoS entre los UE
Los parámetros de QoS de PC5 se negocian en el establecimiento del procedimiento de comunicación uno a uno, por lo que el procedimiento de establecimiento de comunicación uno a uno definido en TS 23.303 [8] se mejora para admitir la negociación de parámetros de QoS de PC5 entre dos UE. Después del procedimiento de negociación de parámetros de QoS de PC5, se utiliza la misma QoS en ambas direcciones.
[La Figura 6.19.2.1.2-1 del 3GPP TR 23.786 V1.0.0, titulada "Establecimiento de un enlace seguro de la capa 2 a través de PC5, se reproduce como la Figura 8]
Los UE involucrados en una comunicación uno a uno negocian los parámetros de QoS de PC5 durante el procedimiento de establecimiento del enlace.
1. El UE-1 envía un mensaje de solicitud de comunicación directa al UE-2 con el fin de desencadenar la autenticación mutua. Este mensaje incluye los parámetros de QoS de PC5 solicitados.
2. El UE-2 inicia el procedimiento de autenticación mutua. El UE-2 incluye los parámetros de QoS de PC5 aceptados en el mensaje de Respuesta.
NOTA: Este procedimiento se alinea con la Solución #11 (cláusula 6.11).
6.19.2.1.3 Manejo de QoS para la comunicación eV2X
Cuando se usa la unidifusión de PC5 para la transmisión de mensajes eV2X, se aplican los siguientes principios tanto para el modo de operación programada de red como para el modo de selección de recursos autónomos de UE:
• Los parámetros de QoS de PC5 definidos en la cláusula 6.19.1.2 se aplican a la comunicación eV2X a través de PC5.
• El mensaje eV2X se envía en el flujo de QoS de PC5 establecido mediante el uso del procedimiento descrito en la cláusula 6.19.2.1.2.
• El mapeo del mensaje eV2X de la capa de aplicación a los parámetros de QoS de PC5 se basa en la regla de QoS de PC5.
Cuando se usa el modo de operación programado de la red, se aplican los siguientes principios adicionales:
• El UE proporciona la información de los parámetros de QoS de PC5 al gNB para la solicitud de recursos.
• Cuando el gNB recibe una solicitud de recurso de PC5 de un UE, el gNB puede autorizar el parámetro de QoS de PC5 solicitado en base a los parámetros de QoS de PC5 recibidos del AMF.
• El gNB puede usar la información del parámetro de QoS de PC5 para el manejo de QoS de PC5.
Cuando se usa el modo de selección de recursos autónomos, se aplica el siguiente principio adicional:
• El UE puede usar el parámetro de QoS de PC5 para el manejo de QoS de PC5 en base a la información proporcionada descrita en la cláusula 6.19.2.1.1.
6.19.2.2 Soporte de QoS para la comunicación de difusión a través de la interfaz PC5
Cuando se usa la difusión de PC5 para la transmisión de mensajes eV2X, se aplican los siguientes principios tanto para el modo de operación programada de red como para el modo de selección de recursos autónomos del UE: • Los parámetros de QoS de PC5 (por ejemplo, VQI) definidos en la cláusula 6.19.1.2 se aplican a la comunicación eV2X a través de PC5.
• La capa de aplicación establece los parámetros de QoS de PC5 para cada mensaje eV2X cuando lo pasa a la capa V2X para su transmisión.
Cuando se usa el modo de operación programado de la red, se aplican los siguientes principios adicionales:
• El UE proporciona información de QoS de PC5 que refleja los parámetros de QoS de PC5 al gNB para la solicitud de recursos.
• El gNB puede usar la información de QoS de PC5 que refleja los parámetros de QoS de PC5 para el manejo de QoS.
Cuando se usa el modo de selección de recursos autónomos, se aplica el siguiente principio adicional:
• El UE puede usar los parámetros de QoS de PC5 para el manejo de QoS de PC5.
NOTA: La elección del modelo de QoS por paquete o del modelo de QoS basado en el portador para la difusión se basa en las decisiones de la RAN.
6.19.2.3 Soporte de QoS para la comunicación de grupo a través de la interfaz PC5
El procedimiento de soporte de QoS para la comunicación de grupo a través de la interfaz de PC5 se describe en la cláusula 6.21.2 (Solución #21).
6.19.3 Impacto en las entidades e interfaces existentes
Los siguientes son los impactos en el UE y otras NF:
• El UE necesita admitir el nuevo modelo de QoS para la comunicación de PC5.
• El AMF proporciona la NG-RAN con los parámetros de QoS para la comunicación de PC5 obtenidos del PCF al asociar los mensajes N2 para diferentes procedimientos.
• La NG-RAN recibe los parámetros de QoS para la comunicación de PC5 del AMF y aplica el parámetro de QoS para el modo de programación de la red.
• El UDR almacena los parámetros de QoS para la comunicación de PC5.
Nota del editor: Es FFS si el mapeo de PPPP, PPPR al nuevo VQI fuera necesario para el tráfico de difusión.
6.19.4 Temas para estudio adicional
Nota del editor: En esta cláusula se describen los temas a estudiar.
6.19.5 Conclusiones
La solución capturada en las cláusulas 6.19.1 a 6.19.3 debería pasar a la fase normativa.
El 3GPP R2-1900370 incluye la siguiente discusión:
En algunas contribuciones [11][12][13], se señaló que podría ser necesario que el UE receptor se informe de algunos lado receptor parámetros relevantes correspondientes a los SLRB configurados en el lateral del UE del transmisor, para que el receptor se alinee con el transmisor y reciba correctamente los datos enviados desde los SLRB correspondientes. Estas configuraciones del SLRB relacionadas con el receptor pueden incluir el espacio del número de secuencia y los modos RLC si son configurables [13], y la razón es fácil de entender: si estos parámetros son configurables, cuando un UE recibe los datos correspondientes a un LCID, el UE tiene que informarse de los valores específicos establecidos para estos parámetros por el transmisor en el SL LCH correspondiente (y el SLRB correspondiente), con el fin de procesar la recepción de los datos correctamente.
Sin embargo, también hubo otros puntos de vista razonables que indican que, de manera similar a la recepción del UE en el DL, es posible que no se necesite una operación de cumplimiento de QoS en el receptor en SL [11], o que trataron tal cumplimiento de las configuraciones del SLRB del lateral del receptor por parte del transmisor como algunas formas de optimización [12]
A continuación, por tanto, vale la pena discutir si tallado receptor se necesita o no la(s) configuración(es) del SLRB relacionada(s) informada(s) al Ue receptor por el UE transmisor en NR SL. También, en SL LTE estas configuraciones del SLRB del lado del receptor se especifican en la configuración STCH en TS 36.331 [17, 9.1.1.6]), por lo que no necesitan informarse por el transmisor.
Pregunta 5: ¿El UE transmisor necesita informar al UE receptor de cualquier configuración de SLRB relacionada con el lado receptor en el NR SL (para alinear el transmisor y el receptor en estas configuraciones)? Si es así, ¿cuáles son?
a) Sí, es necesario informar de la longitud de la SN utilizada para la recepción de un SLRB (si es configurable). b) Sí, es necesario informar del modo RLC usado para un SLRB (si es configurable).
c) No. En NR SL no se necesita esa configuración de SLRB del lado del receptor informada por el transmisor; se trata de una configuración especificada en las especificaciones como en SL LTE.
d) Otros. Si se selecciona, aclare qué otras Opciones hay.
e) Sí, el perfil de QoS de PC5 asociado a cada SLRB/SL LCH establecido en el UE transmisor debe informarse al UE receptor.
f) Sí, es necesario informar de la configuración PHY específica del SLRB (por ejemplo, la configuración HARQ/SFCI)
g) Sí, la configuración de SLRB del lado receptor se configura por el UE transmisor (por ejemplo, t-Reordenamiento, t-Remontaje, etc.)
El apéndice en el 3GPP R2-1900370 describe varias Opciones candidatas para el SLRB configurado/preconfigurado de Nw de la siguiente manera:
Apéndice: Opciones candidatas para el SLRB configurado/preconfigurado de NW
Según la experiencia de SL LTE, los UE con diferentes estados RRC/modo de asignación de recursos pueden depender de diferentes formas de señalización y procedimientos para su (pre)configuración del SL (es decir, señalización dedicada, información del sistema y preconfiguración). Por tanto, a continuación se dan Opciones con diferentes flujos de señalización.
• Opción 1
[Figura A-1 del 3GPP R2-1900370, titulado "Configuración específica del UE basada en perfil de QoS de PC5", se reproduce como la Figura 9]
Dado que el SA2 concluyó definir el VQI para representar los parámetros de QoS de PC5 por paquete en TR 23.786 e indica que el VQI de cada mensaje v 2x (siempre que sea aplicable) se establece por la capa de aplicación [1], esta opción se basa en tales conclusiones y además asume que los parámetros de QoS de PC5 (por ejemplo, VQI, etc.1), es decir, los perfiles de QoS de PC52, etiquetados en cada paquete V2X también se envían al AS (similar al PPPP/PPPR heredado) como en la Etapa 2 anterior. En la Etapa 3, el UE puede reportar los perfiles de QoS de PC5 de los paquetes al gNB/ng-eNB, y solicita la configuración de los SLRB asociados con estos perfiles de QoS de PC5 reportados. Como respuesta, el gNB/ng-eNB puede señalar las configuraciones de los SLRB asociados con los perfiles PC5 QoS informados; estas configuraciones del SLRB pueden incluir el ID del SLRB, el perfil de QoS de PC5 para mapear el SLRB, las configuraciones de SDAP/PdCp/RLC/LCH, etc. En la Etapa 5, el UE en el AS establece el(los) SLRB(s) asociado(s) con el perfil de QoS del(de los) paquete(s) según la configuración gNB/nbeNB, y mapea el
1Aquí, los parámetros de QoS de PC5 específicos en la figura incluyen el VQI y otros parámetros de QoS potenciales identificados por la Q2, de modo que el "etc." colocado aquí podría actualizarse según la conclusión de la Q2 más adelante (si la opción misma es finalmente apoyada). Esto se aplica también a la Opción 3 y 4 a continuación
2De forma similar al Uu, el término "perfil de QoS de PC5" significa aquí un conjunto de parámetros de QoS de PC5, es decir, VQI y otros posibles parámetros de QoS de la Q2. del(de los) paquete(s) a la(s) SLRB establecida(s). Posteriormente, ocurre la transmisión del SL.
Dado que el SA2 supone que "el VQI no estandarizado no es soportado con esta versión" en TR 23.786 [1], es bastante probable que, de forma similar al 5QI usado en la NR Uu, los parámetros PC5 QoS de cada VQI también se estandaricen en la memoria descriptiva. Además, si se considera que el VQI por sí mismo no es suficiente para reflejar todos los parámetros de QoS de PC5 en la Q2, se utilizarán otros parámetros de QoS necesarios junto con el VQI para formar el perfil de QoS de PC5 y se comunicarán también a la RAN. Por tanto, esta opción se caracteriza por permitir que el UE "indique" directamente los parámetros de QoS de los paquetes disponibles en RAN al gNB/ngeNB que, por lo tanto, ya no necesita depender del CN para conocer los perfiles de QoS del tráfico del UE como en el Uu.
Aplicabilidad: En esta opción, el gNB/ng-eNB configura el SLRB en función de los parámetros QoS de PC5 de los paquetes realmente disponibles según lo informado por el UE, por lo que funciona de manera específica del UE y se aplica a los UE RRC_CONNECTED.
• Opción 2
[Figura A-2 del 3GPP R2-1900370, titulado "Configuración específica del UE basada en el perfil de QoS de PC5", se reproduce como la Figura 10]
La opción 2, como se muestra en la Figura A-2, es imitar el mecanismo basado en el flujo de QoS en la NR Uu, porque, según la Solución #19 en TR 23.786 [1], SA2 también propone, al menos para la unidifusión de SL que admite QoS, usar el mecanismo basado en el flujo de QoS de PC5 como sigue [1]:
Figure imgf000015_0001
En particular, en el Paso 0, los parámetros de QoS de PC5 y las reglas de QoS de PC5 para cada flujo de QoS de PC5 se suministran al UE por adelantado mediante el procedimiento de autorización y suministro de servicios, tal como se indica en las conclusiones de SA2; asimismo, los perfiles de QoS de PC5 para cada flujo de QoS también se suministran al eNB/ng-eNB por adelantado. Luego, cuando llega(n) el(los paquetes), el UE primero puede derivar el identificador de los flujos de QoS de PC5 asociados en base a las reglas de QoS de PC5 configuradas en la Etapa 0, y luego puede informar estos QFI de PC5 al gNB/ ng-eNB en la Etapa 3. En el lateral del gNB/ng-eNB, puede derivar el(los) perfil(es) de QoS de estos PC5 QFI(s) notificados en base al aprovisionamiento del 5GC en el Paso 0, y por lo tanto puede señalar las configuraciones del(los) SLRB(s) asociado(s) a los PC5 QFI(s) notificados por el UE. En la Etapa 5, el UE en el AS establece el(los) SLRB asociado(s) con el(los) QFI de PC5 del(los) paquete(s) según la configuración del gNB/ng-eNB y mapea el(los) paquete(s) disponible(s) al(los) SLRB establecido(s). La mayor diferencia con respecto a la opción 1 es que, si sólo se usa la QFI como en la NR Uu, los parámetros de QoS específicos de cada flujo de QoS pueden no ser directamente visibles en el AS del UE/RAN, de modo que el gNB/ng-eNB sigue teniendo que depender de la configuración de la CN para conocer el perfil de QoS específico como en la Uu (aunque los perfiles de QoS se proporcionan de forma anticipada)
Aplicabilidad: Esta opción, similar a la Opción 1, solo se aplica a los UE RRC_CONNECTED.
• Opción 3
[Figura A-3 del 3GPP R2-1900370, titulado "Configuración específica de la célula basada en el perfil QoS de PC5 (por ejemplo, en SIB específico del V2X)", se reproduce como la Figura 11]
La opción 3 se aplica cuando se desea aplicar el SLRB configurado en NW para el UE RRCJDLE/RRCJNACTIVE también. Específicamente, en esta opción, el gNB/ng-eNB usa el SIB específico del V2X para la difusión de la configuración de SLRB asociada con cada posible perfil de QoS de PC5. Luego, cuando llega(n) el(los) paquete(s) con perfil(es) de QoS de PC5 específico(s) como en las Etapas 1 y 2, el UE establece el(los) SLRB(s) correspondiente(s) a este(s) perfil(es) QoS según las configuraciones específicas de la célula de difusión en el SIB y mapea el(los) paquete(s) a los SLRB establecido(s).
Aplicabilidad: Esta opción solo convierte las configuraciones del SLRB específicas del UE en configuraciones específicas de la célula. Aunque se ha diseñado principalmente para los UE RRCJDLE/RRCJNACTIVE, es técnicamente usable también para los UE RRC_COn NeCTED.
3GPP TS 36.300 introdujo el mapeo entre los portadores de radio de enlace lateral y los canales lógicos de enlace lateral como sigue:
6 Capa 2
La capa 2 se divide en las siguientes subcapas: Control de Acceso al Medio (MAC), Control de Enlace de Radio (RLC) y Protocolo de Convergencia de Paquetes de Datos (PDCP).
Esta subcláusula proporciona una descripción de alto nivel de las subcapas de la capa 2 en términos de servicios y funciones. Las tres figuras a continuación representan la arquitectura PDCP/RLC/MAC para el enlace descendente, el enlace ascendente y el enlace lateral, donde:
- Los Puntos de Acceso al Servicio (SAP) para la comunicación entre pares se marcan con círculos en la interfaz entre las subcapas. El SAP entre la capa física y la subcapa MAC proporciona los canales de transporte. Los SAP entre la subcapa MAC y la subcapa RLC proporcionan los canales lógicos.
- La multiplexación de varios canales lógicos (es decir, los portadores de radio) en el mismo canal de transporte (es decir, el bloque de transporte) se realiza por la subcapa MAC;
- Tanto en el enlace ascendente como en el enlace descendente, cuando no se configuran la CA ni la DC, solo se genera un bloque de transporte por TTI en ausencia de multiplexación espacial;
- En el Enlace Lateral, solo se genera un bloque de transporte por TTI.
[...]
[Figura 6-3 del 3GPP TS 36.300 V15.3.0, titulado "Estructura de la capa 2 para el Enlace Lateral", se reproduce como la Figura 12]
3GPP TS 36.331 establece:
5.10.2 Información del Enlace Lateral del UE
5.10.2.1 Generalidades
[Figura 5.10.2-1 del 3GPP 36.331 V15.3.0, titulado "Información del Enlace Lateral del UE", se reproduce como la Figura 13]
El propósito de este procedimiento es informar a la E-UTRAN de que el UE se interesa o deja de interesarse por recibir comunicación de enlace lateral o descubrimiento, por recibir comunicación de enlace lateral V2X, así como por solicitar la asignación o liberación de recursos de transmisión para los anuncios de comunicación de enlace lateral o de descubrimiento o las lagunas de comunicación de enlace lateral V2X o de descubrimiento de enlace lateral, por reportar de los parámetros relacionados con el descubrimiento de enlace lateral a partir de la información del sistema de las células de interfrecuencia/PLMN y por informar de la referencia de sincronización usada por el UE para la comunicación de enlace lateral V2X.
5.10.2.2 Iniciación
Un UE capaz de establecer una comunicación de enlace lateral o una comunicación de enlace lateral V2X o un descubrimiento de enlace lateral que esté en RRC_CONNECTED puede iniciar el procedimiento para indicar que se(interesa en) recibir una comunicación de enlace lateral o una comunicación de enlace lateral V2X o un descubrimiento de enlace lateral en varios casos, entre ellos, cuando se establece con éxito la conexión, al cambiar de interés, al cambiar a una PCell de difusión SystemInformationBlockType18 o SystemInformationBlockType19 o SystemInformationBlockType21 que incluye sl-V2X-ConfigCommon. Un Ue capaz de la comunicación de enlace lateral o de la comunicación de enlace lateral V2X o del descubrimiento de enlace lateral puede iniciar el procedimiento para solicitar la asignación de recursos dedicados para la transmisión de la comunicación de enlace lateral en cuestión o los anuncios de descubrimiento o la transmisión de la comunicación de enlace lateral V2X, o para solicitar lagunas de descubrimiento de enlace lateral para la transmisión de descubrimiento de enlace lateral o la recepción de descubrimiento de enlace lateral, y un UE capaz de informar de los parámetros de descubrimiento de enlace lateral entre frecuencias/PLMN puede iniciar el procedimiento para informar de los parámetros relacionados con el descubrimiento de enlace lateral a partir de la información del sistema de células entre frecuencias/PLMN.
NOTA 1: Un UE en RRC_IDLE que se configura para transmitir comunicaciones de enlace lateral/comunicación de enlace lateral V2X/anuncios de descubrimiento de enlace lateral, mientras el SystemInformationBlockType18/SystemInformationBlockType19/ SystemlnformationBlockType21 que incluye elSL-V2X-ConfigCommon o SystemInformationBlockType26 no incluye los recursos para la transmisión (en condiciones normales), inicia el establecimiento de la conexión de acuerdo con 5.3.3.1a.
Al iniciar el procedimiento, el UE deberá: [...]
1> si elSystemlnformationBlockType21 que incluyeSL-V2X-ConfigCommon es la difusión por la PCell:
2> asegurarse de tener una versión válida delSystemlnformationBlockType21 y el SystemInformationBlockType26, si la difusión, para la PCell;
2> si se configura por las capas superiores para recibir la comunicación de enlace lateral V2X en una frecuencia principal o en una o más frecuencias incluidas en elv2x-InterFreqInfoList, si se incluye en SystemlnformationBlockType21 o SystemlnformationBlockType26de la PCell:
3> si el UE no transmitió un mensaje SidelinkUEInformation desde que entró por última vez al estado RRC_CONNECTED; o
3> si desde la última vez que el UE transmitió un mensaje SidelinkUEInformation el UE conectado a una PCell que no difunde SystemlnformationBlockType21 que incluye sl-V2X-ConfigCommon; o
3> si la última transmisión del mensaje SidelinkUEInformation no incluye el v2x-CommRxInterestedFreqList; o si la(las) frecuencia(s) configurada(s) por las capas superiores para recibir la comunicación de enlace lateral V2X ha cambiado desde la última transmisión del mensaje SidelinkUEInformation:
4> iniciar la transmisión del mensaje SidelinkUEInformation para indicar la(s) frecuencia(s) de interés de recepción de la comunicación de enlace lateral V2X de acuerdo con 5.10.2.3;
2> si no:
3> si la última transmisión del mensaje SidelinkUEInformation incluye el v2x-CommRxInterestedFreqList: 4> iniciar la transmisión del mensaje SidelinkUEInformation para indicar que ya no se interesa por la recepción de la comunicación de enlace lateral V2X de acuerdo con 5.10.2.3;
2> si se configura por las capas superiores para transmitir la comunicación de enlace lateral V2X en una frecuencia primaria o en una o más frecuencias incluidas en el v2x-InterFreqInfoList, si se incluye en el SystemlnformationBlockType21 o SystemlnformationBlockType26de la PCell:
3> si el UE no transmitió un mensaje SidelinkUEInformation desde que entró por última vez al estado RRC_CONNECTED; o
3> si desde la última vez que el UE transmitió un mensaje SidelinkUEInformation el UE conectado a una PCell que no difunde SystemlnformationBlockType21 que incluye sl-V2X-ConfigCommon; o
3> si la última transmisión del mensaje SidelinkUEInformation no incluye el v2x-CommTxResourceReq; o si la información transportada por el mensaje v2x-CommTxResourceReq ha cambiado desde la última transmisión del mensaje SidelinkUEInformation:
4> iniciar la transmisión del mensaje SidelinkUEInformation para indicar los recursos de transmisión de la comunicación de enlace lateral V2X requeridos por el UE de acuerdo con 5.10.2.3;
2> si no:
3> si la última transmisión del mensaje SidelinkUEInformation incluye el v2x-CommTxResourceReq:
4> iniciar la transmisión del mensaje SidelinkUEInformation para indicar que ya no requiere recursos de transmisión de la comunicación de enlace lateral V2X de acuerdo con 5.10.2.3;
- SidelinkUEInformation
El mensaje SidelinkUEInformation se usa para la indicación de la información del enlace lateral al eNB. Portador de radio de señalización: SRB1
RLC-SAP: AM
Canal lógico: DCCH
Dirección: UE a E-UTRAN
Mensaje SidelinkUEInformation
— ASN1START
SidcUnkUEInformatior.-vl430-IEs ::= SECUENCIA {
v2x-CorranRxlnterestedfcreqList-r14 SL-V2X-CommFreqList-r14 OPCIONAL, p2x-CommTxType-r14 ENUMERADO {verdadero} OPCIONAL, v2x-CommTxResourceReq-rl4 SL-V2X-CommrxFreqList-rl4 OPCIONAL , nonCriticalExtensión SidelinkUEInformation-vi530-1Es
OPCIONAL
SidelinkUEInformation-vi530-1Es SECUENCIA {
reliabilitylnfoListSL-rl5 SL-ReliabilityList-rl5 OPCIONAL, nonCriticalExtension SECUENCIA{} OPCIONAL
)
SL-V2X-CommFreqList-rl4 ::=SECUENCIA ( TAMAÑO (1..maxFreqV2X-rl4)) DE ENTERO (0..maxFreqV2X-1-rl4)
SL-V2X-CommTxFreaList-r14 secu e n cia ( tamaño (1..maxFreqV2X-rl4)) DE SL-V2X-CommTxResourceReqrl4
SL-V2X-CcmmTxRcsourceReq-rl4 ::= SECUENCIA{
carrierFreqCommTx-rl4 ENTERO (0.. maxFreqV2X-1-rl4) OPCIONAL v2x-TypeTxSync-r14 SL-TypeTxSync-rl4 opcional ,
v2x-DestinationlnfoList-rl4 SL-DestinationlnfoList-r!2 opcional
)
— ASN1STOP
Figure imgf000018_0001
(continuación)
Figure imgf000019_0001
3GPP TS 23.303 establece:
5.1.1.5.2 Protocolo de señalización de PC5
Leyenda:
- La funcionalidad PDCP/RLC/MAC/PHY se especifica en TS 36.300 [17].
- El Protocolo de señalización de PC5" se usa para la señalización del plano de control a través del PC5 (por ejemplo, establecimiento, mantenimiento y liberación de un enlace seguro de la capa 2 a través de PC5, solicitudes de monitoreo de TMGI, solicitudes de anuncio de ID de Célula, etc. como se describe en otra parte de esta memoria descriptiva).
- El campo Tipo SDU (3 bits) en el encabezado PDCP se usa para discriminar entre el Protocolo de Señalización IP, ARP y PC5. El ARP no es compatible con la comunicación uno a uno.
- Los mensajes del Protocolo de Señalización de PC5 se envían en un ID de Capa 2 de Destino de unidifusión. [Figura 5.1.1.5.3-1 del 3GPP TS 23.303 V15.1.0, titulado "Pila de Protocolo de Señalización de PC5", se reproduce como la Figura 14]
3GPP R2-1904707 establece:
Para la unidifusión de SL, entre el mismo par de UE, se permite establecer múltiples enlaces mediante el uso de los ID de origen iguales o diferentes.
Figure imgf000019_0002
El propósito de tal diseño es mantener cierta flexibilidad para la gestión de enlaces de la capa superior. Sin embargo, prevemos algunos impactos críticos para la gestión de enlaces en el estrato de acceso. Por ejemplo, no está claro si el UE par puede entender si diferentes ID de origen se refieren al mismo UE transmisor. Por lo tanto, será problemático para un UE saber si la capacidad del UE recibida a través de un enlace también puede aplicarse a otros enlaces. Además, parece innecesario tener una gestión de enlaces en el estrato de acceso, por ejemplo, RLM/RLF, para todos los enlaces entre el mismo par de UE.
En cuanto al ID de L1, entre el mismo par de UE para diferentes enlaces con diferentes ID de L2 de origen, los ID de L1 correspondientes también pueden ser diferentes. Sin embargo, en nuestra opinión, esto no es necesario y puede causar problemas para otros procedimientos, por ejemplo, el reporte CSI. En primer lugar, desde la perspectiva del filtrado de paquetes, el UE receptor decodificará todos los paquetes del UE par incluso si esos paquetes pertenecen a diferentes enlaces. En segundo lugar, entre los diferentes enlaces entre el mismo par de UE, la condición del canal es siempre la misma. Por tanto, no tiene sentido adquirir el reporte CSI para diferentes enlaces deducidos desde diferentes pares de ID de L1 de origen/destino entre el mismo par de UE.
Observación 4 Para la unidifusión de SL, un UE puede establecer múltiples enlaces de unidifusión con un UE par y usar el mismo o diferentes ID de la capa 2 de origen para estos enlaces de unidifusión. Se prevén impactos en el diseño del estrato de acceso con respecto al intercambio de capacidades del UE, el procedimiento RLM/RLF y el reporte CSI.
La propuesta 5 RAN2 investiga los impactos de permitir que un UE use múltiples ID de L2 de origen para la comunicación con el mismo UE par. Si es necesario, el RAN2 envía LS a SA2 para aclarar y retroalimentar la vista de RAN2.
3GPP R2-1904094 establece:
2.1 Preliminares para el modelado de RB en la NR Uu y en el SL LTE
En la NR Uu, el portador de radio configurado con RLC AM es un portador bidireccional, que incluye una entidad PDCP, una entidad RLC y un canal lógico3. La entidad RLC consta de un lado transmisor y un lado receptor. La PDU de datos de RLC y el reporte de estado (SR) de RLC se transmiten y reciben a través de la misma entidad de RLC y el mismo canal lógico (es decir, con el mismo LCID). El modelado de tal portador de radio bidireccional se ilustra en la Figura 1.
[Figura 1 del 3GPP R2-1904094, titulado "Uu RB bidireccional con RLC AM", se reproduce como la Figura 15] En el SL LTE, solo se soporta el RLC UM para el SLRB. El LCID de cada SLRB es único dentro del ámbito de una combinación de ID de la Capa 2 de Origen (SRC L2 ID) y de ID de la Capa 2 de Destino (DST L2 ID), sin importar si se trata de unidifusión y difusión en grupo en la comunicación D2D o de difusión en la comunicación de SL de V2X. Por tanto, puede entenderse que cada portador de radio de SL se identifica mediante la combinación de {LCID, SRC ID de L2, DST ID de L2} de su SL LCH asociado. Esto significa que, dentro de un UE, cualquier SLRB usado para Tx y la usado para Rx en un enlace de unidifusión nunca pueden ser iguales, porque la primera se identifica mediante {SRC ID de L2, DST ID de L2} = {ID del UE del propio Ue , ID del UE del par} pero este último se identifica mediante {SRC ID de L2, DST ID de L2} = {ID del UE del par, ID del UE del propio UE} (es decir, en orden diferente). Por ejemplo, con respecto al UE1 en la Figura 2, el SLRB usado para Tx al UE2 se identifica mediante {ID UE1, ID UE2}, mientras que el SLRB usado para Rx desde el UE2 se identifica mediante {ID UE2, ID UE1}. Esto significa que un portador de radio de SL, junto con su entidad PDCP/RLC asociada 3 Para simplificar, el caso de duplicación de PDCP no se considera a lo largo de este documento y el SL LCH en el SL LTE de unidifusión es unidireccional, ya sea que se use solo para transmisión o solo para recepción. El modelado de tal portador unidireccional se ilustra en la Figura 2.
Tal modelado unidireccional es factible en el SL LTE, con una razón importante de que solo se aplica RLC UM para STCH, de modo que una entidad RLC debe usarse solo para transmisión o recepción sin la necesidad de realizar ambas.
[Figura 2 del 3GPP R2-1904094, titulada "SL RB unidireccional con el RLC UM", se reproduce como la Figura 16] 2.2 SLRB bidireccional frente al unidireccional para RLC AM en SL
Para admitir RLC AM para el SLRB NR (que incluye el SL DRB para datos UP y el SL SRB para PC5 RRC) en unidifusión NR, el primer problema que debe discutirse es si el SLRB con RLC a M debe modelarse como portador unidireccional o portador bidireccional. Esto funciona como la esencia para todos los demás diseños detallados de las 3 etapa posteriores.
■ Opción 1: SLRB unidireccional para RLC AM
Esta opción trata de reusar tanto como sea posible el modelado del SLRB unidireccional con RLC UM en el SL LTE, que también es el único modo RLC aceptado para ser compatible con el SL NR de la difusión en grupo y la difusión. Para ser específicos, cada SL RB incluye una entidad PDCP, una entidad RLC unidireccional y un canal lógico de SL. Además, el principio del SL LTE de que el LCID del canal lógico es único dentro de una combinación de ID de la capa 2 de origen/ID de la capa 2 de destino aún se mantiene, lo que significa que la entidad SLRB/SL LCH/PDCP/RLC usada para Tx y los de Rx todavía se distinguen por el par asociado {SRC ID de L2, DST ID de L2}. Suponiendo que el UE1 transmite datos al UE2 y el UE2 retroalimenta el RLC SR asociado al UE1, la Figura 3 muestra el modelado de esta opción.
[Figura 3 del 3GPP R2-1904094, titulado "SL RB unidireccional para RLC AM", se reproduce como la Figura 17]4 Tal modelado unidireccional se aplica inherentemente para RLC UM, porque no hay asociación entre la PDU de datos RLC transmitida en el portador TX y la PDU de datos RLC recibida en el portador RX, por lo que no es necesario tener ninguna relación entre cualquier Portador de TX y portador de RX. Sin embargo, si también aplicamos tal modelo SLRB unidireccional para RLC AM, la situación se vuelve diferente, porque puede ser necesaria la asociación entre la PDU de datos RLC y su SR RLC, es decir: si una PDU de datos RLC en una entidad RLC Tx necesita (re)transmitirse depende del RLC SR recibido en una entidad RLC Rx correspondiente (por ejemplo, en el lateral del UE1), y el SR derivado por una entidad RLC Rx debe enviarse a la entidad RLC Tx correspondiente para su transmisión (por ejemplo, en el lateral del UE2). Como consecuencia, debe haber un enlace entre el SLRB tX usado para transmitir la Pd U de datos RLC (RLC SR) y el SLRB Rx usado para recibir el RLC SR correspondiente (PDU de datos RLC), cuando los SLRB involucrados se configuran como RLC AM.
En base al ejemplo que se muestra en la Figura 1, cuando el UE1 inicia el tráfico de unidifusión configurado con RLC AM al UE2, es posible que el UE1 deba establecer tanto un SLRB Tx como un SLRB Rx asociado con el UE2:
a) Suponga que el LCID del SL LCH asociado con este SLRB Tx establecido por el UE1 (de acuerdo con la configuración/preconfiguración de NW) es el LCID1, y el UE1 le dice al UE2 en el SL que el SL LCH de este SLRB (marcado con el LCID1) se configura con RLC AM según la conclusión de la fase SI [2];
b) El UE2 puede establecer un SLRB Rx con el LCID1 para la recepción de datos y, en consecuencia, decidir que un SLRb Tx con el LCID2 esté vinculado a este SLRB Rx y se use para transmitir el RLC SR para él, es decir, el SLRB Rx con el LCID 1 se vincula con el SLRB Tx con el LCID2 en el UE2. Esto también significa que, desde la perspectiva del UE1, recibirá el RLC SR de la entidad RLC en el SLRB Rx con el LCID2 para sus datos enviados en el SLRB Tx con el LCID1;
c) Cuando UE1 transmite PDU de datos RLC a UE2 con el LCID 1, UE2 (cuando sea necesario) utilizará la entidad RLC de SLRB Tx con el LCID2 para transmitir el SR correspondiente a MAC SDU4La denominación "SLRBX' en las Figuras 3 y 4 solo corresponde al "SLRB con el LCIDX' utilizado en los textos de discusión. recibido con el LCID1 de UEl, es decir, transmitiendo el SR como una MAC SDU marcada con {LCID2, SRC ID de L2 de UE2, DST ID de L2 de UE1};
d) Después de que el UE1 tenga conocimiento del enlace SLRB "Tx-Rx" anterior realizado por el UE2, el UE1, después de recibir esa MAC SDU que transporta RLC SR, sabe que se entrega desde el UE2 y debe entregarse a la entidad RLC de SLRB Rx con el LCID2. Luego, en base al enlace que el UE1 conoció antes, el RLC SR se identifica por la entidad RLC del SLRB Rx con el LCID2 y enviado al SLRB Tx con el LCID1 como retroalimentación.
En base a los análisis anteriores, vemos que al menos los siguientes problemas deben resolverse con el fin de admitir tal modelo SLRB unidireccional para RLC AM: 1) cómo un UE vincula un SLRB Rx a un SLRB Tx configurado con RLC AM para permitir que la entidad RLC del último envíe el RLC SR generado por el primero; 2) cómo se alinean los dos UE en un enlace de unidifusión con tal enlace SLRB "Tx-Rx" (como en las viñetas b y d anteriores). Observación 1: Si la RAN2 tiene la intención de adoptar el modelado SLRB unidireccional para admitir RLC AM en unidifusión, primero deben abordarse al menos los siguientes problemas:
• Cómo enlaza un UE un SLRB de Rx con un SLRB de Tx configurado con RLC AM para permitir que la entidad RLC del segundo envíe el SR RLC generado por el primero;
• ¿Cómo se alinean entre sí los dos UE en un enlace de unidifusión en dicho enlace SLRB "Tx-Rx"? También tenga en cuenta que las operaciones anteriores inevitablemente necesitan algunas formas de interacciones entre los SLRB dentro de un UE. Es posible que también debamos considerar este factor cuando tomemos la decisión final sobre si adoptar el modelo SLRB unidireccional para RLC AM.
Observación 1a: Es posible que inevitablemente se necesiten operaciones entre el SLRB dentro de un UE para que el modelado SLRB unidireccional admita RLC AM en unidifusión.
■ Opción 2: Modelado SLRB bidireccional para RLC AM
Esta opción es para tratar de reusar el modelado de la RB bidireccional con RLC AM en el Uu. Para ser específicos, cada SLRB incluye una entidad PDCP, una entidad RLC bidireccional y un canal lógico de SL. Además, el LCID del canal lógico ya no se identifica únicamente mediante la combinación {SRC ID de L2, DST ID de L2} que diferencia quién es el origen y quién es el destino entre los dos UE; en su lugar, debe ser único dentro de una conexión de unidifusión, por ejemplo, no más diferenciación en el orden del ID del UE1 e ID del UE2 incluidos en la combinación {SRC ID de L2, DST ID de L2}.
Suponiendo que el UE1 transmite datos al UE2 y el UE2 retroalimenta el SR RLC asociado al UE1, la Figura 4 muestra el modelado de esta opción.
[Figura 4 del 3GPP R2-1904094, titulada "SL RB bidireccional para RLC AM", se reproduce como la Figura 18] Tal modelado SLRB bidireccional nunca se ha aplicado en SL LTE, por lo que a continuación es posible que debamos analizar cómo funciona con una analogía con la NR Uu y en base a los acuerdos que hicimos para SLRB configurados/preconfigurados con NR durante la fase SI.
En base al ejemplo que se muestra en la Figura 4, cuando el UE1 inicia el tráfico de unidifusión configurado con RLC AM al UE2, el UE1 establece un SLRB bidireccional que incluye el lateral Tx y el lateral Rx como en Uu con el UE2, en lugar de dos SLRB respectivamente para Tx y Rx como en la Opción 1 anterior:
a) Suponga que el LCID del SL LCH asociado con este SLRB (según la configuración/preconfiguración de NW) establecido por el UE1 es el LCID1, que es único dentro de la conexión de unidifusión entre el UE1 y el UE2, y el UE1 indica el UE2 en el SL que el Sl LCH de este SLRB (marcado con el LCID1) se configura con RLC AM según la conclusión de la fase SI [2];
b) Entonces, el UE2 necesita establecer un SLRB correspondiente con RLC AM y LCID1 también, según la configuración NW/preconfiguración. Este SLRB con el LCID1 en el UE2 no solo recibe datos (es decir, PDU de datos RLC) con su entidad RLC, sino que también envía RLC SR al SLRB con el LCID1 en el UE1. Adicionalmente, en el lateral del UE1, el SLRB con el LCID1 recibirá, por su lado Rx, el SR para su propia transmisión de datos. Esto significa que debe garantizarse que el UE2 tenga también RLC AM en el SLRB con el LCID1, es decir, alinearse con el UE1 en el SLRB con el mismo LCID;
c) Cuando el UE1 transmite PDU de datos RLC al UE2 con el LCID1, el UE2 (cuando sea necesario) usará la entidad RLC del SLRB con el LCID1 para transmitir el SR correspondiente a la PDU RLC con el mismo valor LCID desde el UE1, es decir, transmitir el SR como una MAC SDU marcada con el LCID1 y el ID de conexión entre el UE1 y el UE2 (por ejemplo, identificada por la combinación de {ID del UE1, ID del UE2} sin orden); d) Dado que en esta opción SLRB bidireccional, el SR recibido con un LCID se aplica automáticamente a la entidad RLC asociada con el mismo LCID, el UE1 después de recibir esa MAC SDU, primero sabe que esta MAC SDU se entrega desde el UE2 a sí mismo, y debe entregarse a la entidad RLC del SLRB con el LCID1. Luego, el RLC SR se identifica por la entidad RLC de SLRB con el LCID1 dentro del UE1 como la retroalimentación para la transmisión de datos anterior.
En base a los análisis anteriores, vemos que al menos hay que resolver un problema como el siguiente, es decir: si un UE ya ha establecido un SLRB bidireccional con el r Lc AM, ¿cómo garantizar que su UE par tenga el mismo modo RLC en el SLRB con el mismo LCID según también NW-/preconfiguración (es decir, para evitar desajustes del modo RLC)? Esto es crucial, ya que, si el UE par se configura por el NW o tras la preconfiguración para establecer un SLRB basado en el RLC UM con el mismo LCID, no podrá transmitirse ninguna retroalimentación ARQ, por lo que el RLC AM no se soporta realmente en este SLRB.
Observación 2: Si RAN2 tiene la intención de adoptar el modelo SLRB bidireccional para admitir el RLC AM en la unidifusión, al menos este problema debe abordarse primero: si uno de los UE ya ha establecido un SLRB bidireccional con el RLC a M a través de NR-configuración/preconfiguración, ¿cómo garantizar que su UE par también se (pre) configure con el RLC AM en el SLRB con el mismo LCID?
Se observa además que, específicamente para el caso de que un UE solicite configuraciones del SLRB dedicadas del gNB (por ejemplo, cuando el UE está en RRC_CONNECTED), puede requerir que el gNB del UE configure un SLRB siguiendo el modo RLC de su UE par, si el UE par ya había establecido el SLRB del mismo LCID con el RLC AM antes y se lo indicó a ese UE en el SL.
Observación 2a: En el modelo del SLRB bidireccional, cuando el gNB configura un SLRB a un UE como se solicita (por ejemplo, cuando el UE está en RRC_CONNECTED), es posible que inevitablemente tenga que seguir el modo RLC ya adoptado y que indica su UE par en el SLRB con el mismo LCID.
Anteriormente, se elaboraron las cuestiones básicas sobre el soporte de los SLRB unidireccionales o bidireccionales para la unidifusión de SL del RLC AM, respectivamente. Se sugiere que RAN2 elija el modelo SLRB para el soporte del SL RLC AM teniendo en cuenta los problemas anteriores.
Propuesta 2: RAN2 para decidir si adopta el modelado SLRB unidireccional o bidireccional para el soporte RLC AM en la unidifusión de Sl , teniendo en cuenta sus problemas como se muestra en las Observaciones anteriores.
3GPP R2-1903227 establece:
Si el UE Rx necesita transmitir tráfico, puede configurar el UE Tx (original) con una configuración de recepción utilizando un nuevo mensaje de configuración. Esto conduce al flujo que se muestra en la [Figura, donde el u E1 es el UE Tx inicial y el UE2 es el UE Rx inicial.
[Figura 1 del 3GPP R2-1903227, titulado "Configuración de PC5-RRC en ambas direcciones", se reproduce como la Figura 19]
Propuesta 4: Si el UE Rx necesita transmitir datos, envía un nuevo mensaje de configuración al (anterior) UE Tx con una configuración de recepción.
3GPP Resumen de los estados de señalización [105bis#32]PC5-RRC:
2.2 Problema-2: Configuración de la capa AS
De acuerdo con la conclusión de RAN2#105, solo hay una opción para la configuración de la capa AS.
[Figura 5 del 3GPP Resumen de la señalización [105bis#32]PC5-RRC, titulado "Flujo de información de configuración de la capa AS del SL, exitoso", se reproduce como la Figura 20]
El primer problema es la necesidad de un caso de falla, si se ve el caso anterior como un caso exitoso (La anotación en las figuras es solo para ilustración, pero no para concluir sobre el nombre del procedimiento).
[Figura 2 de 3GPP Resumen de [105bis#32]señalización PC5-RRC, titulado "Flujo de información de configuración de la capa AS del SL, fallo", se reproduce como la Figura 21]
Como se discutió en el 3GPP R2-1900370, se introdujeron Opciones para la configuración de SLRB configurada en NW y la configuración de SLRB preconfigurada para QoS de PC5 (calidad de servicio) basada en el flujo y perfil de QoS de PC5. La configuración de SLRB puede incluir ID(s) del(de los) SLRB, mapeo de flujo de QoS al SLRB y configuración de AS (Estrato de Acceso) (por ejemplo, configuraciones de PDCP (Protocolo de Convergencia de Datos en Paquetes)/RLC (Control de Enlace de Radio)/LCH (Canal lógico)). La configuración del AS podría indicar, por ejemplo, t-Reordering, Ventana de Reordenamiento, Maximum_PDCP_SN, modo RLC (UM (Modo No Reconocido) o AM (Modo Reconocido)), AM_Window_Size, UM_Window_Size, identidad del canal lógico de enlace lateral, y/o etc.
Para admitir el RLC AM para el SLRB en unidifusión NR, se introdujo en el 3GPP R2-1904094 si el SLRB con el RLC AM debe modelarse como portador unidireccional o bidireccional. En la NR Uu, el portador de radio configurado con el RLC AM es un portador bidireccional, que incluye una entidad PDCP, una entidad RLC y un canal lógico. La entidad RLC consta de un lado transmisor y un lado receptor. La PDU de datos RLC y el informe de estado RLC se transmiten y reciben a través de la misma entidad RLC y el mismo canal lógico (es decir, con el mismo LCID). En el SL LTE, solo se soporta el RLC UM para el SLRB. El LCID de cada SLRB es único dentro del ámbito de una combinación de ID de la capa 2 de origen (SRC L2 ID) y de ID de la capa 2 de destino (DST L2 ID), sin importar si se trata de unidifusión y difusión en grupo en la comunicación D2D o de difusión en la comunicación de SL de V2X. Esto significa que un portador de radio de SL, junto con su entidad PDCP/RLC asociada y el SL del LCH en el SL LTE de unidifusión es unidireccional, ya sea que se use solo para transmisión o solo para recepción.
Teniendo en cuenta el caso en el que un UE está en modo RRC ocioso y el UE par está en modo RRC conectado, no parece ser una buena solución para ninguno de los UE obtener la configuración de SLRB para ambas direcciones (en base a la configuración del gNB o preconfiguración) y reenviarlo al otro UE que lo siga. Por ejemplo, el UE1 en modo RRC ocioso envía la configuración de SLRB determinada de acuerdo con la preconfiguración (o información del sistema transmitida por una estación base) al UE2, lo que requiere que el gNB se conecte al UE2 para programar el UE2 en base a la configuración de SLRB determinada de acuerdo con la preconfiguración. O, el UE1 en modo RRC conectado envía la configuración de SLRB configurada por el gNB al UE2, lo que requiere que el UE2 en modo RRC ocioso utilice la configuración de SLRB configurada por el gNB. Por tanto, el SLRB unidireccional para el RLC AM (mediante el uso de canales lógicos de enlace lateral separados) parece más apropiado para tales escenarios. Este concepto también puede aplicarse a otros escenarios, por ejemplo, ambos UE están en modo conectado.
Dado el SLRB unidireccional para el RLC AM, hay un problema después de que el UE1 obtiene la configuración de SLRB para la dirección Tx (en base a la configuración del gNB o la preconfiguración) y la reenvía al UE2, es decir, no es apropio del UE1 comenzar a transmitir los paquetes (de un flujo de QoS de PC5) en el SLRB con el RLC AM porque la configuración de SLRB para la dirección contraria (u opuesta) al UE1 no se ha asignado y, por defecto, el UE1 no puede recibir el informe de estado del RLC que indica el RLC ACK/NACK del UE2. De acuerdo con el 3GPP R2-1903227, si el UE1 necesita transmitir tráfico al UE2, puede configurar el UE2 con una configuración de SLRB para recepción mediante el uso de un nuevo mensaje de configuración. Con el fin de configurar el UE1 con la configuración de SLRB para recepción, el UE2 necesita solicitar el gNB para la configuración de SLRB para recepción en el UE1. De manera similar, el UE2 no puede transmitir la solicitud de configuración de SLRB hasta que llegue un paquete del mismo flujo de QoS al UE2. En esta situación, el UE1 no puede transmitir paquetes de enlace lateral (del flujo de QoS de PC5) en el SLRB hasta que los paquetes de enlace lateral lleguen al UE2, lo que desencadena el UE2 para enviar la configuración de SLRB al UE1. Esta situación provocaría latencia en la transmisión de enlace lateral.
La presente invención proporciona una solución para resolver los problemas anteriores de las técnicas de fondo. Un concepto de la invención es que el UE2 solicita al gNB que configure la configuración de SLRB para la dirección UE2-a-UE1 cuando recibe la configuración de SLRB para la dirección UE1-a-UE2 del UE1.
Por ejemplo, el UE1 transmite una primera configuración de SLRB al UE2, y la primera configuración de SLRB indica un primer ID del SLRB para un SLRB con el RLC AM. En respuesta a la recepción de la primera configuración de SLRB, el UE2 transmite una solicitud de mensaje de configuración de SLRB al gNB, y el gNB proporciona la configuración de SLRB configurada en NW al UE2. Y luego, el UE2 transmite una segunda configuración de SLRB en base a la configuración de SLRB configurada en el NW al UE1. En cuanto al ID del SLRB, puede haber dos Opciones: (1) se usan diferentes ID de SLRB para direcciones separadas y (2) se usa el mismo Id de SLRB para direcciones separadas. Si se usan diferentes ID de SLRB, es posible que el UE2 necesite indicar el primer ID de SLRB en el mensaje de solicitud de configuración de SLRB; y si se usa el mismo ID de SLRB, es posible que no se necesite el primer ID de SLRB en el mensaje de solicitud de configuración de SLRB, y el gNB puede asignar un segundo ID de SLRB para el SLRB en la configuración de SLRB configurada en NW.
Alternativamente, el primer ID de SLRB aún puede incluirse en la solicitud de mensaje de configuración de SLRB, y el gNB puede asignar un segundo ID de SLRB para la SLRB en la configuración de SLRB configurada en NW. Dado que el primer ID de SLRB y el segundo ID de SLRB se asocian con el mismo flujo de QoS de PC5, el primer ID de SLRB se empareja con el segundo ID de SLRB para admitir el RLC AM para el mismo flujo de QoS de PC5. Posiblemente, el primer ID de SLRB y el segundo ID de SLRB pueden ser el mismo.
Es posible que el UE2 necesite responder un mensaje completo al UE2 en respuesta a la recepción del mensaje que incluye la primera configuración de SLRB del UE1. En esta situación, otro momento potencial para que el UE2 solicite la segunda configuración de SLRB del gNB es cuando una capa inferior ha confirmado la transmisión exitosa del mensaje completo (por ejemplo, la capa RLC, la capa MAC o la capa PHY). La transmisión del mensaje completo puede confirmarse, por ejemplo, mediante un acuse de recibo del RLC o un acuse de recibo del HARQ asociado a la transmisión del mensaje completo. Las soluciones anteriores podrían ilustrarse en la Figura 22.
Si tanto el UE1 como el UE2 están en modo RRC ocioso o inactivo, el UE2 no transmite el mensaje de solicitud de configuración de SLRB al gNB cuando recibe la primera configuración de SLRB del UE1. De manera similar, el UE1 no puede comenzar a transmitir los paquetes en el SLRB con el RLC AM hasta que el UE2 reenvíe la configuración de SLRB para la dirección contraria (u opuesta) al UE1. Por tanto, el UE2 podría derivar la segunda configuración de SLRB de acuerdo con la información del sistema transmitida por el gNB o la preconfiguración en el UE2 cuando/si recibe la primera configuración de SLRB del UE1 y transmite la segunda configuración de SLRB al UE1. Alternativamente, el LTE2 podría derivar la segunda configuración de SLRB cuando/si un mensaje completo en respuesta a la recepción de un mensaje que incluye la primera configuración de SLRB se transmite al UE 1 exitosamente. Posiblemente, si la transmisión del mensaje completo se ha transmitido con éxito puede confirmarse mediante la recepción del acuse de recibo del RLC o del acuse de recibo de la retroalimentación del HARQ asociado a la transmisión del mensaje completo. Este concepto también puede aplicarse al caso en el que UE1 está en modo conectado y UE2 está en modo ocioso/inactivo. Esta solución que no está cubierta por la invención reivindicada podría ilustrarse en la Figura 23.
Si el UE1 está en modo inactivo del RRC y el UE2 está en modo RRC conectado, es posible que el UE2 necesite transmitir una solicitud para la configuración de SLRB al gNB. El UE2 puede transmitir la segunda configuración de SLRB en base a la configuración de SLRB configurada en NW al UE1. Normalmente, el UE1 responde un mensaje completo al UE2 en respuesta a la recepción de un mensaje que incluye la segunda configuración de SLRB. Como se discutió en el Resumen el 3GPP de la señalización [105bis#32]PC5-RRC, se discute el caso de falla del manejo para la recepción de la configuración de SLRB. Si el UE2 recibe un mensaje de falla del UE1 en respuesta a la transmisión del mensaje que incluye la segunda configuración de SLRB, es posible que el UE2 deba informar este caso de falla al gNB, y el gNB puede liberar la configuración de SLRB configurada en NW. Este caso provocaría una sobrecarga de señalización.
Otro flujo de señalización podría ser que ambos UE pudieran primero completar el intercambio de configuraciones del SLRB (cada configuración de SLRB de cada Ue podría derivarse de la información del sistema o de la configuración previa) entre sí, y el UE en modo RRC conectado luego transmite un mensaje usado para solicitar la configuración relacionada con las transmisiones de enlace lateral en el enlace de unidifusión (incluida, por ejemplo, el mapeo de ID de flujo de QoS al ID de SLRB, el mapeo de ID de SLRB al LCG y/o etc., donde el UE asigna el ID de SLRB y una identidad del LCG se asigna por el gNB). El mensaje usado para solicitar la configuración relacionada con las transmisiones de enlace lateral en el enlace de unidifusión podría incluir, por ejemplo, SLRB ID, ID del flujo de QoS de PC5 y/o etc.
Por ejemplo, el UE1 transmite una primera configuración de SLRB al UE2, y la primera configuración de SLRB indica un primer ID del SLRB para un SLRB con el RLC AM. En respuesta a la recepción de un mensaje que incluye la primera configuración de SLRB, el UE2 transmite un mensaje completo al UE1. Y luego, el UE2 transmite una segunda configuración de SLRB al UE1, y la segunda configuración de SLRB indica un segundo ID de SLRB (o el primer ID de SLRB) para el SLRB con el RLC AM. En respuesta a la recepción de un mensaje que incluye la segunda configuración de SLRB, el UE1 transmite un mensaje completo al u E2. Al recibir el mensaje completo, el UE2 transmite un mensaje usado para solicitar la configuración relacionada con las transmisiones de enlace lateral en el enlace de unidifusión al gNB, y luego el gNB proporciona la configuración relacionada con las transmisiones de enlace lateral en el enlace de unidifusión al UE1. Esta solución que no está cubierta por la invención reivindicada podría ilustrarse en la Figura 24.
La Figura 25 es un diagrama de flujo 2500 de acuerdo con una realización ilustrativa de la invención reivindicada desde la perspectiva de un primer UE para solicitar la configuración de SLRB para un enlace de unidifusión con un segundo UE. En la etapa 2505, el primer UE recibe un primer mensaje del segundo UE, en el que el primer mensaje incluye una primera configuración de SLRB para el enlace de unidifusión. En la etapa 2510, el primer UE transmite un segundo mensaje a un nodo de red para solicitar una segunda configuración de SLRB para el enlace de unidifusión cuando se recibe el primer mensaje o se confirma una transmisión exitosa de un mensaje completo asociado con el primer mensaje al segundo UE.
Preferentemente, el primer UE podría recibir un tercer mensaje del nodo de red, en el que el tercer mensaje incluye la segunda configuración de SLRB. El primer UE también podría transmitir un cuarto mensaje al segundo UE, en el que el cuarto mensaje incluye la segunda configuración de SLRB.
Preferentemente, el primer mensaje podría incluir una identidad de un flujo de QoS de PC5 para el enlace de unidifusión. El segundo mensaje podría incluir una identidad de un flujo de QoS de PC5.
Preferentemente, la primera configuración de SLRB puede aplicarse para recibir paquetes desde el segundo UE, y la segunda configuración de SLRB puede aplicarse para transmitir paquetes al segundo UE. El primer mensaje podría ser un mensaje RRC de PC5. El cuarto mensaje podría ser un mensaje RRC de PC5.
Preferentemente, el primer UE podría estar en RRC_CONNECTED. El nodo de red puede ser una estación base (por ejemplo, un gNB).
Con referencia de vuelta a las Figuras 3 y 4, en una realización ilustrativa de un primer UE de la invención reivindicada, el dispositivo 300 incluye un código del programa 312 almacenado en la memoria 310. La CPU 308 ejecuta el código del programa 312 para permitir que el primer UE (i) reciba un primer mensaje de un segundo UE, en el que el primer mensaje incluye una primera configuración de SLRB para el enlace de unidifusión, y (ii) para transmitir un segundo mensaje a un nodo de red para solicitar una segunda configuración de SLRB para el enlace de unidifusión cuando se recibe el primer mensaje o se confirma una transmisión exitosa de un mensaje completo asociado con el primer mensaje al segundo UE. Además, la CPU 308 ejecuta el código del programa 312 para realizar todas las acciones y etapas descritas anteriormente u otras descritas en la presente memoria.
La Figura 26 es un diagrama de flujo 2600 de acuerdo con una realización preferente de la invención reivindicada desde la perspectiva de un primer UE para solicitar la configuración de SLRB para un enlace de unidifusión con un segundo UE. En la Etapa 2605, el primer UE recibe un primer mensaje del segundo UE, en el que el primer mensaje incluye una primera configuración de SLRB para el enlace de unidifusión. En la Etapa 2610, el primer UE transmite un segundo mensaje a un nodo de red para solicitar una segunda configuración de SLRB para el enlace de unidifusión cuando se recibe el primer mensaje o se confirma una transmisión exitosa de un mensaje completo asociado con el primer mensaje al segundo UE. En la Etapa 2615, el primer UE recibe un tercer mensaje del nodo de red, en el que el tercer mensaje incluye la segunda configuración de SLRB.
Preferentemente, el primer UE podría transmitir un cuarto mensaje al segundo UE, en el que el cuarto mensaje incluye la segunda configuración de SLRB. El primer mensaje puede incluir una identidad de un flujo de QoS de PC5 para el enlace de unidifusión. El segundo mensaje puede incluir la identidad del flujo de QoS de PC5. El tercer mensaje puede incluir la identidad del flujo de QoS de PC5.
Preferentemente, el primer mensaje puede incluir una identidad de un primer SLRB asociado con la primera configuración de SLRB. El segundo mensaje puede incluir una identidad de un segundo SLRB asociado con la segunda configuración de SLRB. La identidad del segundo SLRB puede asignarse por el primer UE. La identidad del segundo SLRB puede ser igual a la Identidad del primer SLRB.
Preferentemente, el segundo mensaje puede no incluir una identidad de un segundo SLRB asociado con la segunda configuración de SLRB. La identidad del segunda SLRB puede asignarse por el nodo de red.
Preferentemente, el tercer mensaje puede incluir la identidad del segundo SLRB asociado con la segunda configuración de SLRB. El cuarto mensaje puede incluir la información para indicar una asociación entre la primera configuración de SLRB y la segunda configuración de SLRB.
Preferentemente, la primera configuración de SLRB puede aplicarse para recibir paquetes desde el segundo UE, y la segunda configuración de SLRB puede aplicarse para transmitir paquetes al segundo UE. El nodo de red podría ser una estación base (por ejemplo, un gNB).
Preferentemente, el primer mensaje y/o el cuarto mensaje podrían ser un mensaje RRC de PC5. El segundo mensaje podría ser un mensaje RRC que incluya información de asistencia del UE. El tercer mensaje podría ser un mensaje de reconfiguración de RRC.
Preferentemente, el primer UE podría estar en RRC_CONNECTED. El segundo UE podría estar en RRC_CONNECTED, RRC IDLE, o RrC INACTIVE. El primer SLRB y/o el segundo SLRB podrían asociarse con la identidad del flujo de QoS de PC5.
Preferentemente, el mensaje completo podría transmitirse por el primer UE al segundo UE en respuesta a la recepción del primer mensaje. La transmisión exitosa del mensaje completo asociado con el primer mensaje al segundo UE podría confirmarse en base a un acuse de recibo RLC o un acuse de recibo de retroalimentación HARQ asociado con el mensaje completo.
Con referencia de vuelta a las Figuras 3 y 4, en una realización preferente de un primer UE de la invención reivindicada, el dispositivo 300 incluye un código del programa 312 almacenado en la memoria 310. La CPU 308 ejecuta el código del programa 312 para permitir que el primer UE (i) reciba un primer mensaje de un segundo UE, en el que el primer mensaje incluye una primera configuración de SLRB para el enlace de unidifusión, (ii) para transmitir un segundo mensaje a una red nodo para solicitar una segunda configuración de SLRB para el enlace de unidifusión cuando se recibe el primer mensaje o se confirma una transmisión exitosa de un mensaje completo asociado con el primer mensaje al segundo UE, y (iii) para recibir un tercer mensaje del nodo de red, en el que el tercer mensaje incluye la segunda configuración de SLRB. Además, la CPU 308 puede ejecutar el código del programa 312 para realizar todas las acciones y etapas descritas anteriormente u otras descritas en la presente memoria.
Los expertos en la técnica entenderán que la información y las señales pueden representarse mediante el uso de cualquiera de una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, las instrucciones, los comandos, la información, las señales, los bits, los símbolos, y los chips que pueden referenciarse a lo largo de la descripción anterior pueden representarse por tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticas, campos o partículas ópticas, o cualquier combinación de los mismos.
Los expertos apreciarían además que los diversos bloques, módulos, procesadores, medios, circuitos, y etapas de algoritmos lógicos ilustrativos descritos en relación con los aspectos divulgados en la presente memoria 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 pueden diseñarse mediante el uso de la codificación fuente o alguna otra técnica), diversas formas de código del programa o diseño que incorporan instrucciones (que pueden denominarse en la presente memoria, por conveniencia, como "software" o "módulo de software"), o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, diversos componentes, bloques, módulos, circuitos, y etapas ilustrativas se han descrito anteriormente en general en términos de su funcionalidad. Si tal funcionalidad se implementa como hardware o software depende de la aplicación particular y las restricciones de diseño impuestas en el sistema en general.

Claims (11)

REIVINDICACIONES
1. Un procedimiento para que un primer Equipo de Usuario, en lo sucesivo también denominado como UE, solicite la configuración de Portador de Radio de Enlace Lateral, en lo sucesivo también denominado como SLRB, para un enlace de unidifusión con un segundo UE, que comprende:
recibir un primer mensaje desde el segundo UE, en el que el primer mensaje incluye una primera configuración de SLRB para el enlace de unidifusión (2505); y
transmitir un segundo mensaje a un nodo de red para solicitar una segunda configuración de SLRB para el enlace de unidifusión cuando se recibe el primer mensaje o se confirma una transmisión exitosa de un mensaje completo asociado con el primer mensaje al segundo UE (2510).
2. El procedimiento de la reivindicación 1, que comprende además:
recibir un tercer mensaje del nodo de red, en el que el tercer mensaje incluye la segunda configuración de SLRB.
3. El procedimiento de la reivindicación 2, que comprende además:
transmitir un cuarto mensaje al segundo UE, en el que el cuarto mensaje incluye la segunda configuración de SLRB.
4. El procedimiento de una cualquiera de las reivindicaciones 1 a 3, en el que el primer mensaje incluye una identidad de un flujo de Calidad de Servicio de PC5, en lo sucesivo también denominado QoS, para el enlace de unidifusión.
5. El procedimiento de una cualquiera de las reivindicaciones 1 a 4, en el que el segundo mensaje incluye una identidad de un flujo de QoS de PC5.
6. El procedimiento de una cualquiera de las reivindicaciones 1 a 5, en el que la primera configuración de SLRB se aplica para recibir paquetes desde el segundo UE, y la segunda configuración de SLRB se aplica para transmitir paquetes al segundo UE.
7. El procedimiento de una cualquiera de las reivindicaciones 1 a 6, en el que el primer mensaje es un mensaje de control de recursos de radio de PC5, en lo sucesivo también denominado r Rc .
8. El procedimiento de la reivindicación 3 o una combinación de una cualquiera de las reivindicaciones 4 a 7 con la reivindicación 3, en el que el cuarto mensaje es un mensaje RRC de PC5.
9. El procedimiento de una cualquiera de las reivindicaciones 1 a 8, en el que el primer UE está en RRC_CONNECTED.
10. El procedimiento de una cualquiera de las reivindicaciones 1 a 9, en el que el nodo de red es una estación base.
11. Un primer Equipo de Usuario, en lo sucesivo también denominado como UE, para solicitar la configuración de Portador de Radio de Enlace Lateral, en lo sucesivo también denominado como SLRB, para un enlace de unidifusión con un segundo UE, que comprende:
un circuito de control (306);
un procesador (308) instalado en el circuito de control (306); y
una memoria (310) instalada en el circuito de control (306) y acoplada operativamente al procesador (308);
caracterizado porque el procesador (308) se configura para ejecutar un código del programa (312) almacenado en la memoria (310) para realizar las etapas del procedimiento como se definen en una cualquiera de las reivindicaciones anteriores.
ES20170006T 2019-05-02 2020-04-17 Procedimiento y aparato para solicitar la configuración del portador de radio de enlace lateral (SLRB) de la transmisión de unidifusión en un sistema de comunicación inalámbrica Active ES2934143T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201962842179P 2019-05-02 2019-05-02

Publications (1)

Publication Number Publication Date
ES2934143T3 true ES2934143T3 (es) 2023-02-17

Family

ID=70294981

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20170006T Active ES2934143T3 (es) 2019-05-02 2020-04-17 Procedimiento y aparato para solicitar la configuración del portador de radio de enlace lateral (SLRB) de la transmisión de unidifusión en un sistema de comunicación inalámbrica

Country Status (7)

Country Link
US (2) US10904787B2 (es)
EP (1) EP3742832B1 (es)
JP (1) JP6902651B2 (es)
KR (1) KR102328223B1 (es)
CN (1) CN111885734B (es)
ES (1) ES2934143T3 (es)
TW (1) TWI742619B (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019156474A1 (ko) * 2018-02-11 2019-08-15 엘지전자 주식회사 무선 통신 시스템에서 사이드링크 통신을 위한 피드백 신호를 설정하는 방법 및 장치
US11291059B2 (en) * 2018-08-03 2022-03-29 Telefonaktiebolaget LM Ericsson (Publ) Stockholm, Sweden Methods, user equipment and base station for sidelink identification
KR20200094343A (ko) 2019-01-30 2020-08-07 삼성전자주식회사 무선 통신 시스템에서 직접 통신 베어러의 서비스 품질을 관리 및 설정하는 장치 및 방법
KR20220047772A (ko) * 2019-08-15 2022-04-19 지티이 코포레이션 피어 단말기들 간의 사이드링크 능력 정보 송신 및 보안
CN114586464A (zh) * 2019-10-03 2022-06-03 欧芬诺有限责任公司 无线装置的侧链路配置
CN113079712B (zh) * 2019-11-04 2024-06-11 苹果公司 双向侧链路无线电链路控制承载
KR102645819B1 (ko) * 2019-11-07 2024-03-07 엘지전자 주식회사 무선 통신 시스템에서 사이드링크 통신에 관련된 설정을 제어하기 위한 방법 및 장치
KR20210056067A (ko) * 2019-11-08 2021-05-18 삼성전자주식회사 무선 통신 시스템에서 사이드링크 라디오 베어러 구성 정보를 처리하기 위한 장치 및 방법
US11812481B2 (en) * 2020-03-06 2023-11-07 Qualcomm Incorporated Layer 2 relay unicast link setup
KR20230009821A (ko) * 2021-07-09 2023-01-17 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에서 ue-대-네트워크 릴레잉을 지원하기 위한 무선 베어러 구성을 위한 방법 및 장치
CN116582948A (zh) * 2022-01-30 2023-08-11 华为技术有限公司 侧行链路通信方法、设备、存储介质和计算机程序产品

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8331399B2 (en) * 2007-05-07 2012-12-11 Qualcomm Incorporated Re-using sequence number by multiple protocols for wireless communication
CN104936292B (zh) * 2014-03-18 2019-02-05 电信科学技术研究院 用于设备到设备信号传输的资源分配方法和装置
WO2015163626A1 (en) * 2014-04-24 2015-10-29 Lg Electronics Inc. Method for releasing a sidelink radio bearer for d2d communication system and device therefor
US10292192B2 (en) * 2014-05-06 2019-05-14 Lg Electronics Inc. Method for processing received RLC PDUs for D2D communication system and device therefor
KR102396043B1 (ko) * 2014-11-10 2022-05-10 엘지전자 주식회사 D2d 통신 시스템에서 사이드링크 무선 베어러에 대한 암호화 지시를 나타내는 방법 및 그 장치
CN107079005A (zh) * 2014-12-18 2017-08-18 Lg 电子株式会社 在无线通信***中重新配置pdcp重排序定时器的方法及其设备
EP3051736B1 (en) * 2015-01-30 2020-04-29 Panasonic Intellectual Property Corporation of America Prioritization in the logical channel prioritization procedure for sidelink logical channels in ProSe direct communications
US20180132161A1 (en) * 2015-05-15 2018-05-10 Lg Electronics Inc. Method for transmitting discovery signal for establishing d2d link with relay ue in wireless communication system and apparatus therefor
EP3322253B1 (en) * 2015-08-07 2020-12-23 Huawei Technologies Co., Ltd. Apparatus and connection control method
EP3148285B1 (en) * 2015-09-25 2019-04-17 Panasonic Intellectual Property Corporation of America Improved radio bearer mapping for proximity services ue to network relay with associated priority signalling
US10257677B2 (en) * 2015-10-16 2019-04-09 Qualcomm Incorporated System and method for device-to-device communication with evolved machine type communication
WO2017132991A1 (zh) * 2016-02-05 2017-08-10 华为技术有限公司 通信资源分配方法及装置、终端设备、基站和通信***
US10849037B2 (en) * 2016-03-30 2020-11-24 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Data transmission method, base station, and terminal equipment
WO2017166129A1 (zh) 2016-03-30 2017-10-05 华为技术有限公司 承载切换方法及基站设备、网络节点
WO2018006313A1 (en) * 2016-07-07 2018-01-11 Panasonic Intellectual Property Corporation Of America Improved semi-persistent resource allocation behavior for v2x transmissions
EP3273634A1 (en) * 2016-07-18 2018-01-24 Panasonic Intellectual Property Corporation of America Improved support of quality of service for v2x transmissions
EP3603284A1 (en) * 2017-03-24 2020-02-05 Telefonaktiebolaget LM Ericsson (publ) Methods providing scheduling for sidelink communications and related wireless terminals
US10405231B2 (en) * 2017-04-24 2019-09-03 Motorola Mobility Llc Switching between packet duplication operating modes
ES2929734T3 (es) * 2017-05-05 2022-12-01 Asustek Comp Inc Procedimiento y aparato de transmisión de duplicación de datos en un sistema de comunicación inalámbrica
CN108990125B (zh) * 2017-06-01 2020-12-22 华为技术有限公司 数据传输的方法、终端设备和网络设备
EP3416436B1 (en) * 2017-06-15 2021-02-17 BlackBerry Limited Configuring sidelink communications
WO2019061182A1 (en) * 2017-09-28 2019-04-04 Zte Corporation SYSTEMS AND METHODS FOR EXECUTING CARRIER AGGREGATION IN LATERAL BINDING COMMUNICATIONS
US10827380B2 (en) * 2018-01-30 2020-11-03 Huawei Technologies Co., Ltd. System and method for supporting URLLC in advanced V2X communications
KR102125172B1 (ko) * 2018-09-10 2020-07-06 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에 있어서 사이드링크 복사 수신의 초기화를 개선하는 방법 및 장치
CN112970275A (zh) * 2018-11-02 2021-06-15 鸿颖创新有限公司 下一代无线网络侧链路测量报告的方法和用户设备
US11224007B2 (en) * 2018-11-19 2022-01-11 Huawei Technologies Co., Ltd. System and method for supporting sidelink radio bearers
CN111436079A (zh) * 2019-01-11 2020-07-21 华硕电脑股份有限公司 用于无线通信中的侧链路资源分配模式配置的方法及设备
EP3709760B1 (en) * 2019-03-14 2021-09-29 ASUSTek Computer Inc. Methods and apparatuses for sidelink logical channel establishment in a wireless communication system
US11540106B2 (en) * 2019-04-05 2022-12-27 Qualcomm Incorporated Beam sweeping on millimeter wave frequencies for device-to-device communications
US11464066B2 (en) * 2019-04-05 2022-10-04 Qualcomm Incorporated Establishing radio bearers on millimeter wave frequencies for device-to-device communications
KR20210056067A (ko) * 2019-11-08 2021-05-18 삼성전자주식회사 무선 통신 시스템에서 사이드링크 라디오 베어러 구성 정보를 처리하기 위한 장치 및 방법

Also Published As

Publication number Publication date
US20200351699A1 (en) 2020-11-05
US20210105653A1 (en) 2021-04-08
EP3742832B1 (en) 2022-11-02
US11589254B2 (en) 2023-02-21
KR20200128354A (ko) 2020-11-12
JP2020184752A (ja) 2020-11-12
TW202044902A (zh) 2020-12-01
CN111885734A (zh) 2020-11-03
CN111885734B (zh) 2021-08-24
EP3742832A1 (en) 2020-11-25
TWI742619B (zh) 2021-10-11
US10904787B2 (en) 2021-01-26
JP6902651B2 (ja) 2021-07-14
KR102328223B1 (ko) 2021-11-18

Similar Documents

Publication Publication Date Title
ES2934143T3 (es) Procedimiento y aparato para solicitar la configuración del portador de radio de enlace lateral (SLRB) de la transmisión de unidifusión en un sistema de comunicación inalámbrica
ES2897684T3 (es) Procedimientos y aparatos para el establecimiento de canales lógicos de enlace lateral en un sistema de comunicación inalámbrica
ES2870927T3 (es) Método y aparato para soportar comunicación de enlace lateral uno a uno en un sistema de comunicación inalámbrica a través de PC5
CN110431859B (zh) 用于无线通信***中层之间交互的方法及其设备
ES2940479T3 (es) Procedimiento y aparato para configurar la comunicación de enlace lateral en un sistema de comunicación inalámbrica
US10716165B2 (en) Methods and apparatus for releasing a sidelink radio bearer for D2D communication system
US10602555B2 (en) Method for establishing layer-2 entities for D2D communication system and device therefor
KR101294517B1 (ko) 무선 통신 시스템에서 릴레이 노드를 사용하는 방법
ES2901630T3 (es) Procedimiento y aparato para admitir la reasignación del flujo de QoS (calidad de servicio) a DRB (portador de radio de datos) para la comunicación de enlace lateral en un sistema de comunicación inalámbrica
ES2903227T3 (es) Procedimientos y aparatos para gestionar un cambio de identificador de enlace lateral en un sistema de comunicación inalámbrica
ES2932964T3 (es) Procedimiento y aparato para solicitar recursos de transmisión de enlace lateral en un sistema de comunicación inalámbrica
KR20220066840A (ko) 무선 통신 시스템에서 uu 무선 베어러 대 pc5 무선 링크 제어(rlc) 베어러 매핑을 위한 방법 및 장치