ES2917823T3 - Procedimiento y aparato para la configuración de la compresión de cabecera para el portador de radio de enlace lateral en un sistema de comunicación inalámbrica - Google Patents

Procedimiento y aparato para la configuración de la compresión de cabecera para el portador de radio de enlace lateral en un sistema de comunicación inalámbrica Download PDF

Info

Publication number
ES2917823T3
ES2917823T3 ES20191025T ES20191025T ES2917823T3 ES 2917823 T3 ES2917823 T3 ES 2917823T3 ES 20191025 T ES20191025 T ES 20191025T ES 20191025 T ES20191025 T ES 20191025T ES 2917823 T3 ES2917823 T3 ES 2917823T3
Authority
ES
Spain
Prior art keywords
slrb
header compression
pdcp
messages
communication
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
ES20191025T
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 ES2917823T3 publication Critical patent/ES2917823T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/0273—Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • 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
    • 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]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

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

Abstract

Se divulga un método y un aparato desde la perspectiva de un UE, equipo de usuario, para aplicar la compresión de encabezado y la descompresión en un portador de radio lateral, SLRB. El método incluye la obtención de UE (1105) al menos un protocolo de convergencia de datos de paquete, PDCP, parámetro para el SLRB desde un nodo de red. El método también incluye determinar (1110) si la compresión del encabezado y la descompresión se usan para transmitir mensajes de vehículo a todo, V2X, en el SLRB de acuerdo con si los mensajes V2X basados en Internet, IP, basados o no IP se transmiten. En el SLRB, en el que se usa la compresión y la descompresión del encabezado si los mensajes V2X basados en IP se transmiten en el SLRB, y la compresión y la descompresión del encabezado no se usan si los mensajes V2X no basados en IP se transmiten en el SLRB. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento y aparato para la configuración de la compresión de cabecera para el portador de radio de enlace lateral en un sistema de comunicación inalámbrica
Esta divulgación se refiere generalmente a las redes de comunicación inalámbrica, y más particularmente, a un procedimiento y aparato para la configuración de la compresión de cabecera para el portador de radio de enlace lateral 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 Protocolo de Internet (IP). Dicha comunicación de paquetes de datos 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 que se mencionan anteriormente. Una nueva tecnología de radio para la próxima generación (por ejemplo, 5G) se discute 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 el estándar 3GPP.
El documento 3GPP R2-1910223 divulga que la compresión y descompresión de cabecera puede configurarse para IP SDU.
El documento 3GPP R2-1909074 divulga la configuración de los parámetros SLRB.
Sumario
Un procedimiento y un aparato se divulgan desde la perspectiva de un UE (Equipo de Usuario) para aplicar la compresión y descompresión de cabecera en un Portador de Radio de Enlace Lateral (SLRB) y se definen en la reivindicación independiente: 1 y 6
Las realizaciones preferidas de las reivindicaciones dependientes de la misma. La invención incluye que el UE obtenga al menos un parámetro del Protocolo de Convergencia de Paquetes de Datos (PDCP) para el SLRB desde un nodo de red. La invención también incluye la determinación de si la compresión y descompresión de cabecera se usa para transmitir mensajes V2X (Vehículo a Todo) en el SLRB de acuerdo con si los mensajes V2X (Protocolo de Internet) basados en IP o no basados en IP deben transmitirse en el SLRB, en el que la compresión y descompresión de cabecera se usa si los mensajes V2X basados en IP van a transmitirse en el SLRB, y la compresión y descompresión de cabecera no se usa si los mensajes V2X no basados en IP van a transmitirse en el SLRB.
Breve descripción de los dibujos
La Figura 1 muestra un diagrama de un sistema de comunicaciones inalámbricas.
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 sistema de comunicación.
La Figura 4 es un diagrama de bloques funcional del código del programa de la Figura 3.
La Figura 5 es una reproducción de la Figura 5.2.1.4-1 de 3GPP TS 23.287 V1.1.0.
La Figura 6 es una reproducción de la Figura 6.1.1-1 de 3GPP TS 23.287 V1.1.0.
La Figura 7 es una reproducción de la Figura 7-1 de 3GPP TS 38.885 V16.0.0.
La Figura 8 es una reproducción de la Figura 7-2 de 3GPP TS 38.885 V16.0.0.
La Figura 9 es una reproducción de la Figura 5.10.2-1 de 3GPP TS 36.331 V15.3.0.
La Figura 10 es una reproducción de la Tabla 5.5.1-1 de 3GPP TS 36.323 V15.3.0.
Descripción detallada
El objeto, es decir, denominado "ejemplo(s)'y"aspecto(s)"/"realizac¡ón(es)"/"¡nvenc¡ón(es)" en la descripción de las Figuras 1-15, no es de acuerdo con la invención como se define en las reivindicaciones. Este objeto sirve para resaltar y explicar ciertas características de las reivindicaciones y está presente únicamente con propósitos ilustrativos. Sin embargo, el ámbito de la invención se define por todas las características reivindicadas de las reivindicaciones adjuntas.
Los sistemas y dispositivos de comunicación inalámbrica ilustrativos descritos a continuación 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-Avanzada (Evolución a Largo Plazo Avanzada), 3GPP2 UMB (Ultra Banda Ancha Móvil), WiMax, 3GPP NR (Nueva Radio), o algunas otras técnicas de modulación.
En particular, los dispositivos de sistemas de comunicación inalámbrica ilustrativos que se describen a continuación pueden diseñarse para soportar uno o más estándares, como el estándar que se ofrece por un consorcio que llamado "Proyecto de Asociación de 3ra Generación" denominado en la presente memoria como 3GPP, que incluye: El documento TS 23.287 V1.1.0, "Mejoras de la arquitectura para el Sistema 5G (5GS) para soportar los servicios Vehículo a Todo (V2X) (Versión 16)"; TR 38.885 V16.0.0, "NR; Estudio sobre NR Vehículo a Todo (V2X) (Versión 16)"; TS 36.331 V15.3.0, "E-UTRA; Especificación del Protocolo de Control de Recursos de Radio (RRC) (Versión 15)"; y TS 36.323 V15.3.0, " E-UTRA; Especificación del Protocolo de Convergencia de Datos en Paquetes (PDCP) (Versión 15)".
La Figura 1 muestra un sistema de comunicación inalámbrica de acceso múltiple de acuerdo con una realización de la invención. Una red de acceso 100 (AN) incluye 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, solamente 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 mediante el enlace directo 120 y reciben información desde el terminal de acceso 116 mediante el 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 mediante el enlace directo 126 y reciben información desde el terminal de acceso (AT) 122 mediante el 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 luego a la que usa el enlace inverso 118.
Cada grupo de antenas y/o el área en la que se diseñan para comunicarse se denomina 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 mediante 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 diferentes terminales de acceso 116 y 122. También, una red de acceso que usa la conformación de haces para transmitir a terminales de acceso dispersas aleatoriamente a través de su cobertura provoca menos interferencia a los terminales de acceso en las celdas 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 también puede denominarse 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) también puede llamarse equipo de usuario (UE), un dispositivo de comunicación inalámbrica, terminal, terminal de acceso o alguna otra terminología.
La Figura 2 es un diagrama de bloques simplificado de una realización de un sistema transmisor 210 (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 mediante 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 se modulan luego (es decir, se asignan 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 se proporcionan luego 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 proporciona luego Nt flujos de símbolos de modulación para los Nt transmisores (TMTR) del 222a al 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 ascendentemente) las señales analógicas para proporcionar una señal modulada adecuada para la transmisión mediante el canal MIMO. Nt señales moduladas desde los transmisores del 222a al 222t se transmiten luego desde las Nt antenas de la 224a a la 224t, respectivamente.
En el sistema receptor 250, las señales moduladas transmitidas se reciben por las Nr antenas de la 252a a la 252r y la señal recibida desde cada antena 252 se proporciona a un receptor (RCVR) respectivo del 254a al 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 recibe y procesa luego los Nr flujos de símbolos recibidos desde los Nr receptores 254 en base a una técnica de procesamiento particular del receptor para proporcionar Nt flujos de símbolos "detectados". El procesador de datos de RX 260 demodula, desintercala, y decodifica luego cada flujo de símbolos detectado para recuperar los datos de tráfico para el flujo de datos. El procesamiento por el procesador de datos de RX 260 es complementario al que realiza 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 discute a continuación). 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 se procesa luego por un procesador de datos de TX 238, que recibe también 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 al 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 determina luego qué matriz de precodificación usar para determinar los pesos de la conformación de haces y procesa luego el mensaje extraído.
Volviendo a la Figura 3, esta figura muestra un diagrama de bloques funcional simplificado alternativo de un dispositivo de comunicación de acuerdo con una realización de la invención. Como se muestra en la Figura 3, el dispositivo de comunicación 300 en un sistema de comunicación inalámbrica 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, como un teclado o teclado numérico, y puede emitir imágenes y sonidos a través del dispositivo de salida 304, como un monitor o altavoces. El transceptor 314 se usa para recibir y transmitir señales inalámbricas, que suministra señales recibidas al circuito de control 306, y que emite señales que se generan por el circuito de control 306 de forma inalámbrica. El dispositivo de comunicación 300 en un sistema de comunicación inalámbrica también puede utilizarse 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 que se muestra en la Figura 3 de acuerdo con una realización de la invención. En esta realización, el código del programa 312 incluye una capa de aplicación 400, una porción de la Capa 3402, y una porción de la Capa 2404, y se acopla a una porción de la Capa 1 406. La porción de la Capa 3402 realiza en general el control de recursos de radio. La porción de la Capa 2404 realiza en general el control de enlace. La porción de la Capa 1406 realiza en general las conexiones físicas.
El 3GPP TS 23.287 especifica la comunicación V2X, así como la Autorización y el Aprovisionamiento para las comunicaciones V2X como sigue:
5.1 Autorización y Aprovisionamiento para las comunicaciones V2X
5.1.1 Generalidades
En 5GS, los parámetros para las comunicaciones V2X sobre PC5 y puntos de referencia Uu pueden estar disponibles para el UE de las siguientes maneras:
- preconfigurado en el ME; o
- configurado en la UICC; o
- preconfigurado en el ME y configurado en la UICC; o
- proporcionado/actualizado por el Servidor de Aplicaciones V2X a través de PCF y/o punto de referencia V1;
o
- proporcionado/actualizado por la PCF a la UE.
Los principios básicos de la autorización y el aprovisionamiento de servicios para la comunicación V2X sobre el punto de referencia PC5 y el aprovisionamiento para la comunicación V2X sobre el punto de referencia Uu son: - El UE puede autorizarse para usar la comunicación V2X sobre el punto de referencia PC5 por PLMN por la PCF en la HPLMN.
- La PCF en la HPLMN fusiona la información de autorización del hogar y otras PLMN y proporciona al UE la información de autorización final.
- El PCF en la VPLMN o HPLMN puede revocar la autorización (a través de H-PCF en itinerancia) en cualquier momento mediante el uso del procedimiento de Actualización de Configuración del UE para el procedimiento de entrega de política de UE transparente definido en la cláusula 4.2.4.3 de TS 23.502 [7]. - El aprovisionamiento al UE para la comunicación V2X sobre los puntos de referencia PC5 y Uu se controla por la PCF y puede ser activado por el UE. El PCF incluye la Política/parámetros V2X para las comunicaciones V2X sobre el punto de referencia PC5 como se especifica en la cláusula 5.1.2.1 y/o la Política/parámetros V2X para las comunicaciones V2X sobre el punto de referencia Uu como se especifica en la cláusula 5.1.3.1 en una Sección de Política identificada por un Identificador de Sección de Política (PSI) como se especifica en la cláusula 6.1.2.2.2 de TS 23.503 [16].
5.1.2 Autorización y Aprovisionamiento para las comunicaciones V2X sobre el punto de referencia PC5 5.1.2.1 Aprovisionamiento de Políticas/Parámetros
La siguiente información para las comunicaciones V2X sobre el punto de referencia PC5 se proporciona al UE:
1) Política de autorización:
- Cuando el UE es "servido por E-UTRA" o "servido por NR":
- PLMN en las que el UE se autoriza a realizar las comunicaciones V2X sobre el punto de referencia PC5 cuando es "servido por E-UTRA" o "servido por NR".
Para cada PLMN anterior:
- RAT(s) sobre las cuales el UE se autoriza para realizar las comunicaciones V2X sobre el punto de referencia PC5.
- Cuando el UE es "no servido por E-UTRA" y "no servido por NR":
- Indica si el UE se autoriza a realizar las comunicaciones V2X sobre el punto de referencia PC5 cuando "no está servido por E-UTRA" y "no está servido por NR".
- RAT(s) sobre las cuales el UE se autoriza para realizar las comunicaciones V2X sobre el punto de referencia PC5.
2) Parámetros de radio cuando el UE está "no servido por E-UTRA" y "no servido por NR":
- Incluye los parámetros de radio por PC5 RAT (es decir, LTE PC5, NR PC5) con Área(s) Geográfica(s) y una indicación de si son "administrados por el operador" o "no administrados por el operador". El UE utiliza los parámetros de radio para realizar comunicaciones V2X sobre el punto de referencia PC5 cuando está " no servido por E-UTRA " y " no servido por NR " sólo si el UE puede localizarse de forma fiable en la zona geográfica correspondiente. De lo contrario, el UE no se autoriza a transmitir.
Nota del editor: Los parámetros de radio (por ejemplo, las bandas de frecuencias) deben definirse por los WG RAN. La referencia a la memoria descriptiva RAN se agregará cuando se defina en los WG RAN. NOTA 1: Las regulaciones locales definen si una banda de frecuencias es "gestionada por el operador" o "no gestionada por el operador" en un Área Geográfica determinada.
3) Política/parámetros por RAT para la selección del Perfil PC5 Tx:
- El mapeo de tipos de servicio (por ejemplo, PSID o ITS-AID) a los Perfiles Tx.
Nota del editor: Los Perfiles Tx deben definirse por los WG RAN. La referencia a la memoria descriptiva RAN se agregará cuando se defina en los WG RAN.
4) Política/parámetros relacionados con la privacidad:
- La lista de servicios V2X, por ejemplo, PSID o ITS-AID de las aplicaciones V2X, con Áreas Geográficas que requieren soporte de privacidad.
5) Política/parámetros cuando se selecciona LTE PC5:
Igual que se especifica en TS 23.285 [8], cláusula 4.4.1.1.2, elemento 3) Política/parámetros, excepto el mapeo de tipos de servicio a Perfiles Tx y la lista de servicios V2X con Áreas Geográficas que requieren soporte de privacidad.
6) Política/parámetros cuando se selecciona NR PC5:
- El mapeo de tipos de servicio (por ejemplo, PSID o ITS-AID) a frecuencias V2X con Áreas Geográficas. - El mapeo de la(s) ID de la Capa 2 de Destino y los servicios V2X, por ejemplo, PSID o ITS-AID de la aplicación V2X para la difusión.
- El mapeo de la(s) ID de la Capa 2 de Destino y los servicios V2X, por ejemplo, PSID o ITS-AID de la aplicación V2X para la difusión grupal.
- El mapeo de los ID de la Capa 2 de Destino predeterminados para la señalización inicial para establecer la conexión de unidifusión y los servicios V2X, por ejemplo, PSID o ITS-AID de la aplicación V2X.
NOTA 2: El mismo ID de la Capa 2 de Destino predeterminado para la señalización inicial de unidifusión puede asignarse a más de un servicio V2X. En el caso de que diferentes servicios V2X se mapeen a distintos ID de Capa 2 de Destino predeterminados, cuando el UE pretenda establecer un único enlace de unidifusión que pueda utilizarse para más de un servicio V2X, el UE podrá seleccionar cualquiera de los ID de Capa 2 de Destino predeterminados para usarlos en la señalización inicial.
- Configuración del mapeo QoS de PC5:
- Entrada de la capa de aplicación V2X:
- Servicio V2X (por ejemplo, PSID o ITS-AID).
- (Opcional) Requerimientos de la Aplicación V2X para el servicio V2X, por ejemplo, requerimiento de prioridad, requerimiento de confiabilidad, requerimiento de retardo, requerimiento de rango. NOTA 3: Los detalles de los Requerimientos de la Aplicación V2X para el servicio V2X dependen de la implementación y están fuera del ámbito de esta memoria descriptiva.
- Salida:
- Parámetros de QoS de PC5 definidos en la cláusula 5.4.2 (es decir, PQI y condicionalmente otros parámetros como MFBR/GFBR, etc).
- Configuraciones de SLRB, es decir, el mapeo de perfil(es) de QoS de PC5 a SLRB(s), cuando el UE es "no servido por E-UTRA" y "no servido por NR".
- El perfil de QoS de PC5 contiene los parámetros de QoS de PC5 descritos en la cláusula 5.4.2 y el valor de las características de QoS con respecto al Nivel de Prioridad, la Ventana de Promedio, el Volumen de Ráfaga de Datos máximo si el valor predeterminado no se usa como se define en la Tabla 5.4.4-1.
Nota del editor: Las configuraciones de SLRB se determinan por los WG RAN. La referencia a la memoria descriptiva RAN se agregará cuando se defina en los WG RAN.
Nota del editor: Para el perfil QoS de PC5, se necesita la coordinación con los WG RAN.
Nota del editor: Las frecuencias V2X con Área(s) Geográfica(s) se determinan por los WG RAN. La referencia a la memoria descriptiva RAN se agregará cuando se defina en los WG RAN.
5.1.2.2 Principios para aplicar los parámetros para las comunicaciones V2X sobre el punto de referencia PC5 Para la comunicación V2X sobre el punto de referencia PC5, el operador puede preconfigurar los UE con los parámetros de aprovisionamiento necesarios para la comunicación V2X, sin necesidad de que los UE se conecten al 5GC para obtener esta configuración inicial. Se aplica lo siguiente:
- Los parámetros de aprovisionamiento para las comunicaciones V2X sobre el punto de referencia PC5 pueden configurarse en la UICc , en la ME o tanto en la UICC como en la ME.
- Los parámetros de aprovisionamiento de ME no se borrarán cuando se deseleccione o reemplace un USIM. - Si tanto la UICC como la ME contienen el mismo conjunto de parámetros de aprovisionamiento superpuestos, tendrá prioridad el conjunto de parámetros de la UICC.
- Los parámetros de aprovisionamiento de la PCF tendrán prioridad sobre los parámetros preconfigurados en la ME y la UICC.
- El UE deberá usar los recursos de radio para las comunicaciones V2X sobre el punto de referencia PC5 de la siguiente manera:
- Mientras un UE tiene una celda de servicio y se acampa en una celda y el UE tiene la intención de usar para el servicio V2X los recursos de radio (es decir, la frecuencia de la portadora) operados por esta celda, entonces el UE utilizará la descripción del recurso de radio indicada por esta celda en la que el UE se acampa e ignorará cualquier descripción del recurso de radio del mismo recurso de radio proporcionado en el ME o el UICC. Si la celda no proporciona recursos de radio para el servicio V2X, el UE no deberá realizar la transmisión y recepción de mensajes V2X en los recursos de radio operados por esta celda.
- Si el UE tiene la intención de usar los recursos de radio "administrados por el operador" (es decir, frecuencia portadora) para el servicio V2X que no se operan por la celda de servicio del UE, como se especifica en la cláusula 5.1.2.1, o si el UE está fuera de cobertura, el UE deberá buscar una celda en cualquier PLMN que opere los recursos de radio proporcionados (es decir, frecuencia portadora) como se define en TS 36.300 [9] y TS 36.304 [10] (si se selecciona PC5 basado en LTE para la comunicación V2X) o como se define en Ts 38.300 [11] y TS 38.304 [12] (si se selecciona PC5 basado en NR para la comunicación V2X), y:
- Si el UE encuentra tal celda en la PLMN registrada o en una PLMN equivalente a la registrada, y se confirma la autorización para las comunicaciones V2X sobre el punto de referencia PC5 a esta PLMN, el UE deberá usar la descripción del recurso radioeléctrico indicado por dicha celda. Si esa celda no proporciona recursos de radio para el servicio V2X, el UE no deberá realizar la transmisión y recepción de mensajes V2X en esos recursos de radio.
- Si el UE encuentra tal celda, pero no en la PLMN registrada o en una PLMN equivalente a la PLMN registrada, y esa celda pertenece a una PLMN autorizada para las comunicaciones V2X sobre el punto de referencia PC5 y proporciona recursos de radio para el servicio V2X, entonces el UE deberá realizar la selección de PLMN desencadenada por las comunicaciones V2X sobre el punto de referencia PC5, como se define en TS 23.122 [13]. Si el UE tiene una sesión de emergencia en curso a través de IMS, no deberá activar ninguna selección de PLMN debido a la comunicación V2X sobre el punto de referencia PC5.
- Si el UE encuentra tal celda, pero no en una PLMN autorizada para las comunicaciones V2X sobre el punto de referencia PC5, el UE no deberá usar las comunicaciones v 2x sobre el punto de referencia PC5.
- Si el UE no encuentra tal celda en ninguna PLMN, entonces el UE se deberá considerar "no servido por NR o E-UTRA" y usar los recursos de radio proporcionados en el ME o el UICC. Si no existe tal disposición en el ME o en la UICC o la disposición no autoriza las comunicaciones V2X sobre el punto de referencia PC5, el UE no se autoriza a transmitir.
- Si el UE pretende usar recursos de radio "no gestionados por el operador" (es decir, frecuencia portadora) para el servicio V2X, de acuerdo con TS 36.331 [14] o TS 38.331 [15] y como se especifica en la cláusula 5.1.2.1, entonces el UE deberá realizar la comunicación V2X sobre PC5 mediante el uso del recurso aprovisionado en ME o UICC. Si no existe tal disposición en el ME o en la UICC o la disposición no autoriza las comunicaciones V2X sobre el punto de referencia PC5, el UE no se autoriza a transmitir.
- El aprovisionamiento de UE deberá soportar la configuración de Áreas Geográficas.
NOTA 1: Es posible que un UE use otros recursos de radio para el servicio V2X en base al Área Geográfica en lugar de los operados por la celda NG-RAN de servicio, cuando se aprovisiona en el UE, incluso si la celda de servicio del UE ofrece un servicio normal y el SIBxy indica que el servicio (comunicación V2X) está disponible. Esto es para cubrir el escenario cuando, por ejemplo, los recursos de radio usados para las comunicaciones V2X sobre el punto de referencia PC5 no son propiedad de la red de servicio del UE.
Nota del editor: La numeración y la referencia de SIBxy deben actualizarse en base a la definición de los WG's RAN. NOTA 2: Cuando se soporta la operación entre portadoras, de acuerdo con TS 36.331 [14] o TS 38.331 [15], un UE puede recibir instrucciones de su celda de servicio para realizar la comunicación V2X a través de una frecuencia de portadora diferente. En este caso, el UE sigue considerándose "servido por NR o E-UTRA".
NOTA 3: El escenario en el que se detecta una celda y ésta no proporciona soporte para las comunicaciones V2X sobre el punto de referencia PC5 cuando el UE intenta usar una frecuencia portadora configurada para las comunicaciones V2X sobre el punto de referencia PC5, se considera un error de configuración. Por lo tanto, el UE no transmite en esa frecuencia para evitar interferencias en la red.
- Las comunicaciones V2X sobre el punto de referencia PC5 solo se especifican para E-UTRA y NR.
NOTA 4: Está fuera del ámbito de la presente memoria descriptiva definir cómo el UE puede ubicarse en un Área Geográfica específica. Cuando el UE está en cobertura de una RAT 3GPP, puede, por ejemplo, usar información derivada de la PLMN de servicio. Cuando el UE no está en la cobertura de una RAT 3GPP, puede usar otras técnicas, por ejemplo, el Sistema de Satélite de Navegación Global (GNSS). La ubicación proporcionada por el usuario no es una entrada válida.
5.2 Comunicación V2X
5.2.1 Comunicación V2X sobre el punto de referencia PC5
5.2.1.1 Generalidades
Para la comunicación V2X, existen dos tipos de puntos de referencia PC5: el punto de referencia PC5 basado en LTE, como se define en TS 23.285 [8], y el punto de referencia PC5 basado en NR, como se define en la cláusula 4.2.3. Un UE puede usar cualquier tipo de PC5 o ambos para la comunicación V2X en función de los servicios que admita el UE. La comunicación V2X sobre el punto de referencia PC5 admite operaciones de roaming e inter-PLMN. La comunicación V2X sobre el punto de referencia PC5 es compatible cuando el UE es "servido por NR o E-UTRA" o cuando el UE es "no servido por NR o E-UTRA".
Un UE se autoriza a transmitir y recibir mensajes V2X cuando tiene autorización y configuración válidas como se especifica en la cláusula 5.1.2.
La comunicación V2X sobre el punto de referencia PC5 tiene las siguientes características:
- La comunicación V2X sobre el punto de referencia PC5 basado en LTE no tiene conexión, es decir, el modo de difusión en la capa de Estrato de Acceso (AS), y no hay señalización sobre PC5 para el establecimiento de la conexión.
- La comunicación V2X sobre el punto de referencia PC5 basado en NR admite el modo de difusión, el modo de difusión grupal y el modo de unidifusión en la capa AS. El UE indicará el modo de comunicación para un mensaje V2X a la capa AS. Se admite la señalización en el plano de control sobre el punto de referencia PC5 para la administración de la comunicación en modo de unidifusión.
- Soporte de comunicación de servicios V2X entre los UE sobre el plano de usuario PC5.
- Los mensajes V2X se intercambian entre los UE a través del plano de usuario PC5.
- Tanto los mensajes V2X basados en IP como los no basados en IP son compatibles con el punto de referencia PC5.
- Para los mensajes V2X basados en IP, solo se utiliza IPv6. IPv4 no es compatible.
Los identificadores usados en la comunicación V2X sobre el punto de referencia PC5 se describen en la cláusula 5.6.1. El UE decide el tipo de punto de referencia PC5 y perfil Tx a usar para la
transmisión de un paquete particular en base a la configuración descrita en la cláusula 5.1.2. Cuando se selecciona el punto de referencia PC5 basado en LTE, los procedimientos correspondientes de manejo de QoS se definen en TS 23.285 [8]. Cuando se selecciona el punto de referencia PC5 basado en NR, los procedimientos y manejo de QoS se definen en las cláusulas 5.4.1 y 6.3.
Si el UE tiene una sesión de emergencia en curso a través de IMS, la sesión de emergencia en curso a través de IMS deberá tener prioridad sobre la comunicación V2X a través del punto de referencia PC5.
NOTA: La sesión de emergencia a través de la configuración de IMS en base a los requerimientos regulatorios regionales/nacionales apropiados y en las políticas del operador, como se define en TS 23.501 [6].
5.2.1.4 Comunicación en modo de unidifusión a través del punto de referencia PC5
La comunicación en modo de unidifusión solo es compatible con el punto de referencia PC5 basado en NR. La Figura 5.2.1.4-1 ilustra un ejemplo de enlaces de unidifusión PC5.
[La figura 5.2.1.4-1 de 3GPP TS 23.287 V1.1.0, titulada "Ejemplo de enlaces de unidifusión PC5", se reproduce como la Figura 5]
Los siguientes principios se aplican cuando la comunicación V2X se realiza a través del enlace de unidifusión PC5: - Un enlace de unidifusión PC5 entre dos UE permite la comunicación V2X entre uno o más pares de servicios V2X pares en estos UE. Todos los servicios V2X en el UE que usan el mismo enlace de unidifusión PC5 usan el mismo ID de la Capa de Aplicación.
NOTA 1: Un ID de la Capa de Aplicación puede cambiar con el tiempo como se describe en las cláusulas 5.6.1.1 y 6.3.3.2, debido a la privacidad. Esto no provoca el restablecimiento de un enlace de unidifusión PC5. - Un enlace de unidifusión PC5 soporta uno o más servicios V2X (por ejemplo, PSID o ITS-AID) si estos servicios V2X se asocian al menos con el par de ID de capa de aplicación de pares para este enlace de unidifusión PC5. Por ejemplo, como se ilustra en la figura 5.2.1.4-1, el UE A y el UE B tienen dos enlaces de unidifusión PC5, uno entre el ID de la Capa de Aplicación 1/UE A y el ID de la Capa de Aplicación 2/UE B y otro entre el ID de la Capa de Aplicación 3/UE A y el ID de la Capa de Aplicación 4/UE B.
NOTA 2: Un UE de origen no requiere conocer si diferentes ID de la Capa de Aplicación de destino a través de diferentes enlaces de unidifusión PC5 pertenecen al mismo UE de destino.
- Un enlace de unidifusión PC5 soporta la comunicación V2X mediante el uso de un protocolo de una sola capa de red, por ejemplo, IP o no IP.
- Un enlace de unidifusión PC5 soporta el modelo QoS por flujo como se especifica en la cláusula 5.4.1.
Cuando la Capa de Aplicación en el UE inicia la transferencia de datos para un servicio V2X que requiere el modo de comunicación de unidifusión sobre el punto de referencia PC5:
- el UE deberá reutilizar un enlace de unidifusión PC5 existente si el par de ID de la Capa de Aplicación de los pares y el protocolo de la capa de red de este enlace de unidifusión PC5 son idénticos a los requeridos por la capa de aplicación en el UE para este servicio V2X, y modificar el enlace de unidifusión PC5 existente para añadir este servicio V2X como se especifica en la cláusula 6.3.3.4; de cualquier otra manera
- el UE deberá activar el establecimiento de un nuevo enlace de unidifusión PC5 como se especifica en la cláusula 6.3.3.1.
Después del establecimiento exitoso del enlace de unidifusión de PC5, el UE A y el UE B usan el mismo par de ID de la Capa 2 para el posterior intercambio de mensajes de señalización de PC5-S y la transmisión de datos del servicio V2X como se especifica en la cláusula 5.6.1.4. La capa V2X del UE transmisor indica a la capa AS si una transmisión es para un mensaje de señalización PC5-S (es decir, Solicitud/Aceptación de Comunicación Directa, Solicitud/Respuesta de Actualización de Identificador de Enlace, Solicitud/Respuesta de Desconexión, Solicitud/Aceptación de Modificación de Enlace) o datos del servicio V2X.
Para cada enlace de unidifusión PC5, un UE autoasigna un identificador de enlace PC5 distinto que identifica de forma exclusiva el enlace de unidifusión PC5 en el UE durante el tiempo de vida del enlace de unidifusión PC5. Cada enlace de unidifusión de PC5 se asocia con un Perfil de Enlace de unidifusión que incluye:
- tipo(s) de servicio (por ejemplo, PSID o ITS-AID), ID de la Capa de Aplicación e ID de la Capa 2 del UE A; y - ID de la Capa de Aplicación e ID de la Capa 2 del UE B; y
- protocolo de la capa de red usado en el enlace de unidifusión PC5; y
- para cada servicio V2X, un conjunto de Identificadores de Flujo de QoS PC5 (PFI(s)). Cada PFI se asocia con los parámetros de QoS (es decir, PQI y, opcionalmente, Rango).
Por razones de privacidad, los ID de la Capa de Aplicación y los ID de la Capa 2 pueden cambiar como se describe en las cláusulas 5.6.1.1 y 6.3.3.2 durante la vida útil del enlace de unidifusión PC5 y, de ser así, deberán actualizarse en el Perfil del Enlace de Unidifusión en consecuencia. El UE usa el identificador de enlace de PC5 para indicar el enlace de unidifusión de PC5 a la capa de Aplicación V2X, por lo tanto, la capa de Aplicación de V2X identifica el enlace de unidifusión de PC5 correspondiente incluso si hay más de un enlace de unidifusión asociado con un tipo de servicio (por ejemplo, el UE establece múltiples enlaces de unidifusión con múltiples UE para un mismo tipo de servicio).
El Perfil del Enlace de Unidifusión deberá actualizarse en consecuencia después de una modificación del enlace de la Capa 2 para un enlace de unidifusión PC5 establecido, como se especifica en la cláusula 6.3.3.4.
5.2.1.5 Asignación de direcciones IP
Para el modo de unidifusión de la comunicación V2X sobre el punto de referencia PC5, el siguiente mecanismo para La asignación de la dirección IP/prefijo puede usarse:
a) Autoconfiguración de Direcciones sin Estado IPv6 especificada en el RFC 4862 [21] para la asignación del prefijo IPv6, con uno de los dos UE actuando como enrutador por defecto IPv6.
NOTA: El UE que actúa como un enrutador predeterminado de IPv6 se negocia durante el establecimiento del enlace seguro de la Capa 2 intercambiando la Configuración de la Dirección IP como se describe en la cláusula 6.3.3.1.
b) Las direcciones locales de enlace IPv6, como se definen en RFC 4862 [21], se forman por el UE localmente.
Las direcciones locales de enlace IPv6 se intercambian durante el establecimiento de un enlace seguro de la Capa 2 sobre el punto de referencia PC5 como se describe en la cláusula 6.3.3.1. Los UE desactivarán la detección de las direcciones duplicadas después de que se establezca el enlace de la Capa 2.
[...]
6.1.1 Plano de usuario para el punto de referencia NR PC5 que soporta servicios V2X
[La Figura 6.1.1-1 de 3GPP TS 23.287 V1.1.0, titulada "Plano de Usuario para interfaz PC5", se reproduce como la Figura 6]
Los tipos de SDU PDCP IP y No IP se soportan para la comunicación V2X sobre PC5.
Para el tipo de SDU IP PDCP, solo se soporta IPv6. La asignación y configuración de direcciones IP se definen en la cláusula 5.6.11.
La SDU PDCP No IP contiene una cabecera de Tipo No IP, que indica la familia de mensajes V2X usada por la capa de aplicación, por ejemplo, WSMP [18] de la familia IEEE 1609, FNTP definido por ISO [19].
NOTA: La cabecera de Tipo No IP y los valores permitidos se definirán en la memoria descriptiva de la etapa 3. 3GPP TS 38.885 especifica la administración de la QoS para el enlace lateral NR V2X como sigue:
7 Administración de la QoS
La administración de la QoS es relevante para V2X en el contexto de su uso en la asignación de recursos, el control de congestión, la coexistencia en el dispositivo, el control de la potencia y la configuración de SLRB. Los parámetros de la capa física relacionados con la administración de QoS son la prioridad, la latencia, la confiabilidad y el rango de comunicación mínimo requerido (como lo definen las capas superiores) del tráfico que se entrega. Los requerimientos de velocidad de datos también son compatibles con el As . Se necesita una métrica de congestión SL y, al menos en el modo de asignación de recursos 2, los mecanismos para el control de la congestión. Es beneficioso informar la métrica de congestión SL a gNB.
Para SL de unidifusión, difusión grupal y difusión, los parámetros de QoS de los paquetes V2X se proporcionan por las capas superiores al AS. Para SL de unidifusión, los SLRB se (pre) configuran en base a los flujos de señalización y los procedimientos que se muestran en las Figuras 7-1 y 7-2. El modelo QoS por flujo descrito en [6] se asume en las capas superiores.
[La Figura 7-1 de 3GPP TS 38.885 V16.0.0, titulada "Configuración de SLRB para SL de unidifusión (específico de UE)", se reproduce como la Figura 7]
En el Paso 0 de la Figura 7-1, el perfil de QoS de PC5, es decir, un conjunto de parámetros de QoS de PC5 específicos, y la regla de QoS de PC5 para cada flujo de QoS de PC5 se aprovisionan al UE por adelantado mediante la autorización del servicio y los procedimientos de aprovisionamiento como en [6]; similarmente, el perfil de QoS de PC5 para cada flujo de QoS también se proporciona al gNB/ng-eNB por adelantado. Luego, cuando llegan los paquetes, el UE primero puede derivar el identificador de los flujos de QoS de PC5 asociados (es decir, QFI de PC5) en base a las reglas de QoS de PC5 configuradas en el Paso 0, y luego puede informar el QFI(s) de PC5 derivado) al gNB/ng-eNB en el Paso 3. El gNB/ng-eNB puede derivar los perfiles de QoS de estos QFI(s) de PC5 reportados en base al aprovisionamiento de 5GC en el paso 0, y puede señalar las configuraciones de los SLRB asociado con el(los) QFI(s) de PC5 que el UE comunicó a través de la señalización dedicada RRC en el paso 4. Estas configuraciones de SLRB pueden incluir el mapeo de flujo de QoS de PC5 a SLRB, configuraciones de SDAP/PDCP/RLC/LCH, etc. En el Paso 5, el UE en el AS establece los SLRB(s) asociados con los QFI(s) de PC5 del paquete(s) con el UE par según la configuración del gNB/ng-eNB, y mapea los paquetes disponibles a los SLRB(s) establecidos. Entonces puede ocurrir la transmisión SL de unidifusión.
NOTA: Cómo se define el QFI de PC5 depende del WG2 de SA2.
[La Figura 7-2 de 3GPP TS 38.885 V16.0.0, titulada "Configuración de SLRB para SL de unidifusión (basado en la preconfiguración)", se reproduce como la Figura 8]
En la Figura 7-2, tanto las reglas de QoS de PC5 que se usan en las capas superiores para el filtrado como la configuración de SLRB para cada flujo de QoS de PC5 en la capa AS se preconfiguran como en el Paso 0 (ya sea mediante señalización CN, en UICC o preconfigurado en ME [6]). En los pasos 1-3, el UE obtiene el identificador de los flujos de QoS de PC5 asociados para los paquetes que llegan, configura de manera autónoma los SLRB(s) asociados con el UE par en función de la configuración previa y mapea los paquetes) en los SLRB correspondientes en base a sus identificadores de flujo de QoS de PC5 asociados. Entonces puede ocurrir la transmisión SL de unidifusión.
Para la unidifusión de NR SL, el flujo de QoS de PC5 a la asignación de SLRB se realiza en la capa SDAP del UE. Algunas configuraciones de SLRB (que incluyen al menos la longitud de SN, el modo RLC y el perfil QoS de PC5 asociado con cada SLRB) para la unidifusión deben informarse por un UE al UE par en SL, cuando se (pre)configuran en el UE.
Para la transmisión de enlace lateral V2X en SL del difusión grupal y difusión, las configuraciones SLRB se (pre)configuran en base a los flujos de señalización y los procedimientos que se muestran en la Figura 7-3, la Figura 7-4 y la Figura 7-5 a continuación. Para el SL difusión grupal y difusión, se asume el modelo de QoS por paquete descrito en [6] en las capas superiores; particularmente, el PQI y otros posibles parámetros de QoS (si los hay) se establecen por las capas superiores del UE para representar un conjunto de parámetros de QoS de PC5 por paquete, es decir, el perfil de QoS de PC5, que se etiquetan en cada paquete V2X enviado al AS.
3GPP TS 36.331 especifica la siguiente Información de Enlace Lateral del UE relacionada con las comunicaciones de enlace lateral como sigue:
5.10.2 Información de Enlace Lateral del UE
5.10.2.1 Generalidades
[La Figura 5.10.2-1 de 3GPP TS 36.331 V15.3.0, titulada "Información de Enlace Lateral del UE ", se reproduce como la Figura. 9]
El propósito de este procedimiento es informar a E-UTRAN que el UE se interesa o ya no se interesa en recibir comunicación de enlace lateral o descubrimiento, en recibir comunicación de enlace lateral V2X, así como en solicitar la asignación o liberación de recursos de transmisión para anuncios de comunicación de enlace lateral o descubrimiento o brechas de comunicación de enlace lateral V2X o descubrimiento de enlace lateral, en reportar los parámetros relacionados con el descubrimiento de enlace lateral a partir de la información del sistema de celdas interfrecuencia/PLMN y en reportar 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 con capacidad de comunicación de enlace lateral o comunicación de enlace lateral V2X o descubrimiento de enlace lateral que se encuentre en RRC_CONNECTED puede iniciar el procedimiento para indicar que está (interesado en) recibir comunicación de enlace lateral o comunicación de enlace lateral V2X o descubrimiento de enlace lateral en varios casos, que incluyen el establecimiento exitoso de la conexión, el cambio de interés, el cambio a una difusión de PCell SystemInformationBlockTypel8 o SystemInformationBlockTypel9 o SysteminformationBlockType21 que incluye sl-V2X-ConfigCommon. Un UE con capacidad de comunicación de enlace lateral o de comunicación de enlace lateral V2X o de descubrimiento de enlace lateral puede iniciar el procedimiento para solicitar la asignación de recursos dedicados para la transmisión de comunicación de enlace lateral o los anuncios de descubrimiento o la transmisión de comunicación de enlace lateral V2X en cuestión, o para solicitar brechas 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 con capacidad de notificación de parámetros de descubrimiento de enlace lateral entre frecuencias/PLMN puede iniciar el procedimiento para notificar los parámetros relacionados con el descubrimiento de enlace lateral a partir de la información del sistema de celdas entre frecuencias/PLMN.
NOTA 1: Un UE en RRC_IDLE que se configura para transmitir comunicación de enlace lateral/comunicación de enlace lateral V2X/anuncios de descubrimiento de enlace lateral, mientras SystemInformationBlockType18/ SystemInformationBlockType19/ SystemInformationBlockType21 que incluye sl-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 SystemlnformationBlockType21 que incluye sl-V2XVinfigComm se difunde por la PCell
2> garantizar que tenga una versión válida de SystemlnformationBlockType21 y SystemlnformationBlockType26, si se difunde por el PCell;
2> si se configura por la capa superior para recibir la comunicación de enlace lateral
V2X en una frecuencia primera o en una o más frecuencias incluida en v2x-InterFreqlnfoList, si se incluye en SystemlnformationBlockType21 o SystemlnformationBlockType21 de la PCell:
3> si el UE no transmitió un mensaje SidelinkUEInformation desde la última vez que entró en el estado RRC CONNECTED; o
3> si desde la última vez que el UE trasmitió un mensaje SidelinkUEInformation el UE conectado a un PCell no ha difundido el SystemlnformationBlockType21 incluyendo sl-V2X-ConfigCommon; o
3> si la última transmisión del mensaje SidelinkUEInformation no incluye v2x- CommRxInterestedFreqUst; o si la(s) frecuencia(s) configurada(s) por las capas superiores para recibir la comunicación de enlace lateral V2X ha(n) cambiado desde la última transmisión del mensaje SidelinkUEInformation:
4> iniciar la trasmisión del mensaje SidelinkUEInformation para indicar la(s) frecuencia (s) de recepción de la comunicación de enlace lateral V2X de interés de acuerdo con 5.10.2.3;
> si no
3> si la última transmisión del mensaje SidelinkUEInformation incluye v2x CommRxInterestedFreqUst:
4> iniciar la trasmisión del mensaje SidelinkUEInformation para indicar que no se interesa en la recepción de la comunicación de enlace lateral V2X de acuerdo con 5.10.2.3;
2> si se configura por la capa superior para transmitir la comunicación de enlace lateral V2X en una frecuencia primera o en una o más frecuencias incluida en v2x-InterFreqlnfoList, si se incluye en SystemlnformationBlockType21 o SystemlnformationBlockType21 de la PCell:
3> si el UE no transmitió un mensaje SidelinkUEInformation desde la última vez que entró en el estado RRC_CONNECTED; o
3> si desde la última vez que el UE trasmitió un mensaje SidelinkUEInformation el UE conectado a un PCell no ha difundido el SystemlnformationBlockType21 incluyendo sl-V2X-ConfigCommon; o
3> si la última transmisión del mensaje SidelinkUEInformation no incluyó v2x-CommTxResourceReq; o si la información llevada por el v2x-CommTxResourceReq ha cambiado desde la última transmisión del mensaje SidelinkUEInformation:
4> iniciar la trasmisió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 incluyó v2x-Com mTxResource Req:
4> iniciar la trasmisión del mensaje SidelinkUEInformation para indicar que no requiere los recursos de transmisión de la comunicación de enlace lateral V2X de acuerdo con 5.10.2.3;
SidelinkU Elnfo rmatio n
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
MensajeSidelinkUEInformation
— A.SN1 IN IC IA S
S i d c l i r i k U K l n C o r r n a L i o n —v l 4 3 0 - l E 3 : SE ^U b lN C b |
v 2 x C om m R xI n t e r e s h e d F r e q l . i s t . r l 4 ST. V 2X C o m m F r e q L i s t r T 4 O P TT O N A L, p 2 x - C o m m T x T y p e - r l 4 ENUMERATED ( t r a e f O P T IO N A L , v 2 x - C o m m l * x R c s o u r c c R c q - r l 4 S L - V 2 X - C o m jn r x t ’r c q L i s L - r l 4 O P T IO N A L , n o n C r i t. i c d 1 F . x t « n s i » x i S i d e 1 i n k llF T n f o m i d t i o n —v i ¡»30 — T F .s
O P T IO N A L
1
S i de? 1 i rtk lJK I n r e» rm<i 1. i o n —v1 S ^ O - I h SK ülJK N O K |
r e i l a b i l i t y l n í o L i s t S L - r l b SL-ReliabiiityList-rlb O P T IO N A L , n o n C r i t . l e a l E x t e n s i ó n SEQUENCE |) O P T IO N A L
S T .- V 2 X - C c u m F r e q T .i3 t t - r l 4 : : = SRQ IJF.NC E (<5T7.R ( 1 . . m » x F r « q V ? X - r 14 ) l O F TN T FO FR ( 0 . . m * x F r e q V ? X - l - r 14 ) S L - V 2 X - C o M « í i T x F r o q L i a t - r l 4 ; SEQ U B N C E ( S I Z E < 1 . .w a x F i o q V 2 X - i . 14 > ) C F S L - V 2 X - C o n u iT x R « ¿ a o u x c o lk .*q -rl A
S L - V 2 X - C o m m T x R c 5 o u r c c R c q - r 14 : SEQUENCE l
r n r r i p r F r p q n n r a m T x - r 14 TNTF.OER (f) . . m * x F r f » q V ? X - l - r 14 ) O PTT O N A L, v 2 x —T y p c T x S y n c - r l 4 SL-TypcTxSync-r14 OPTIONAL,
v 2 x * D c s t i n a t i o n I n f o L i s t - r 14 SL-Dc3tinationInfoList-rl2 OPTIONAL
* r - A SN PARAR
Figure imgf000014_0001
(continuación)
Figure imgf000015_0001
3GPP TS 36.323 especifica la compresión y descompresión de cabecera realizada en la capa PDCP como sigue: 5.5 compresión y descompresión de cabecera
5.5.1 Perfiles y protocolos de compresión de cabecera soportados
El protocolo de compresión de cabecera en base al marco de trabajo Compresión de Cabecera Robusta (ROHC) [7]. Hay múltiples algoritmos de compresión de cabecera, llamados perfiles, definidos para el marco de trabajo ROHc . Cada perfil es específico para la capa de red particular, la capa de transporte o la combinación de protocolos de la capa superior, por ejemplo, TCP/IP y RTP/UDP/IP.
La definición detallada del canal ROHC se especifica como parte del marco de trabajo ROHC en RFC 5795 [7]. Esto incluye cómo multiplexar diferentes flujos (con cabecera comprimida o no) sobre el canal ROHC, así como cómo asociar un flujo iP específico con un estado de contexto específico durante la inicialización del algoritmo de compresión para ese flujo.
La implementación de la funcionalidad del marco de trabajo ROHC y de la funcionalidad de los perfiles de compresión de cabecera soportados no se cubre en esta memoria descriptiva.
En esta versión de la memoria descriptiva se describe el soporte de los siguientes perfiles:
[La tabla 5.5.1-1 de 3GPP TS 36.323 V15.3.0, titulada "Protocolos y perfiles de compresión de cabecera soportados", se reproduce como la Figura 10]
5.5.2 Configuración de la compresión de cabecera
Las capas superiores pueden configurar entidades PDCP asociadas con DRB, consulte TS 36.331 [3] para usar compresión de cabecera bidireccional (si se configura headerCompression) o solo de enlace ascendente (si se configura) upIinkOnlyHeaderCompression se configura). Si upIinkOnlyHeaderCompression se configura, el UE deberá procesar la PDU de control PDCP recibida para el paquete de retroalimentación ROHC intercalado correspondiente a la compresión de cabecera del enlace ascendente como se especifica en la subcláusula 5.5.6.2, pero no deberá realizar la descompresión de cabecera para la PDU de datos PDCP recibida. Las entidades PDCP asociadas con SLRB pueden configurarse para usar compresión de cabecera para los SDU IP.
5.5.3 Parámetros de protocolo
RFC 5795 tiene parámetros de configuración que son obligatorios y que deben configurarse por capas superiores entre pares compresores y descompresores [7]; estos parámetros definen el canal ROHC. El canal ROHC es un canal unidireccional, es decir, hay un canal para el enlace descendente y otro para el enlace ascendente si headerCompression se configura, y solo hay un canal para el enlace ascendente si se configurauplinkOnlyHeaderCompression. Por lo tanto, hay un conjunto de parámetros para cada canal, y se deberán usar los mismos valores para ambos canales pertenecientes a la misma entidad PDCP si se configura headerCompression.
Estos parámetros se clasifican en dos grupos diferentes, como se define a continuación:
- M: Obligatorio y configurado por capas superiores.
- N/A: No se utiliza en esta memoria descriptiva.
El uso y la definición de los parámetros se deberán especificar a continuación.
- MAX_CID (M): Este es el valor máximo de CID que puede usarse. Siempre se reservará un valor CID para los flujos sin comprimir. El parámetro MAX_CID se configura por capas superiores (CID máx., véase TS 36.331 [3]). - GRANDES_CIDS: Este valor no lo configuran las capas superiores, sino que se deduce del valor configurado de MAX_CID de acuerdo con la siguiente regla:
s i M A X C ID > lS en toncesLA R G E C ID S = T R U E s ino L A R G E C ID S = F A L S E ,
- PERFILES (M): Los perfiles se usan para definir qué perfiles pueden ser usados por el UE.
La lista de perfiles soportados se describe en la sección 5.5.1. El parámetro PERFILES se configura por capas superiores (perfiles para enlace ascendente y enlace descendente, Perfiles rohc en SL-Preconfiguración o SL-V2X-Preconfiguración para enlace lateral, véase TS 36.331 [3]).
- RETROALIMENTACIÓN_PARA (N/A): Esta es una referencia al canal en la dirección opuesta entre dos puntos finales de compresión e indica a qué canal se refiere cualquier retroalimentación enviada. La retroalimentación recibida en un canal ROHC para esta entidad PDCP siempre se referirá al canal ROHC en la dirección opuesta para esta misma entidad PDCP.
- MRRU (N/A): No se usa la segmentación ROHC.
5.5.4 Compresión de cabecera
El protocolo de compresión de cabecera genera dos tipos de paquetes de salida:
- paquetes comprimidos, cada uno asociado con una SDU PDCP
- paquetes independientes no asociados con una SDU PDCP, es decir, paquetes de retroalimentación ROHC intercalados
Un paquete comprimido se asocia con el mismo valor SN y COUNT de PDCP que la SDU de PDCP relacionada. Los paquetes de retroalimentación de ROHC intercalados no se asocian con una SDU de PDCP. No se asocian con un SN PDCP y no se cifran.
NOTA: Si el número MAX_CID de contextos ROHC ya se establece para los flujos comprimidos y un nuevo flujo IP no coincide con ningún contexto ROHC establecido, el compresor debe asociar el nuevo flujo IP con uno de los CID ROHC asignados para los flujos comprimidos existentes o enviar PDCP SDU pertenecientes al flujo IP como paquete sin comprimir.
5.5.5 Descompresión de cabecera
Si la compresión de cabecera se configura por capas superiores para entidades PDCP asociadas con datos del plano u, las PDU de PDCP se descomprimen por el protocolo de compresión de cabecera después de realizar el descifrado como se explica en la subcláusula 5.6
5.5.6 PDU de control PDCP para retroalimentación ROHC intercalada
5.5.6.1 Operación de Transmisión
Cuando el protocolo de compresión de cabecera genera un paquete de retroalimentación ROHC intercalado, el UE deberá:
- enviar a las capas inferiores de la PDU de control de PDCP correspondiente como se especifica en la subcláusula 6.2.5, es decir, sin asociar un SN de PDCP ni realizar cifrado.
5.5.6.2 Operación de Recepción
Al recibir una PDU de control PDCP para un paquete de retroalimentación ROHC intercalado de capas inferiores, el UE deberá:
- entregar el paquete de retroalimentación ROHC intercalado correspondiente al protocolo de compresión de cabecera sin realizar el descifrado.
En LTE, una Configuración de Protocolo de Convergencia de Datos en Paquetes (PDCP) para un portador de radio de datos (DRB) puede contener los siguientes parámetros (como se describe en 3GPP TS 36.331):
- PDCP-Config
El IE PDCP-Config se usa para establecer los parámetros PDCP configurables para portadores de radio de datos.
Elemento de información PDCP-Config
— A SN 1IN IC IA R
P D C P - C o n f ig : : * SEQUEMCE ^
d i s c a r d T i i n c r ENUMERATED l
rwsSO, m a l00 , m s l 50 , m s 300 , m s 500 ,
m s /L O , m s lb O O , i n l i n i t y
OPTTONAT., C on d . C o n f i g u r a r r lc -A N SEQUENCE (
s t a t ú s R e p o r t R e q u ir e d BOOLEAN
OPTIONAL, — C o n d R l c -
r lc - U M SEQUENCE I
p d c p - S N - S i z e ENUNERATED l e n / b i t s , l e n l 2 b i t s )
O PTIO N A L, - - Coi id R lc -
h e a d e r C o m p r e s s io n CIIO ICE (
notUspd N ULL,
r o f ic SEQUENCE i
IN TEC E R ( 1 ..1 6383 ) DEFAULT I b ,
SEQUENCE |
BOOT.RAN,
BOOLEAN,
BOOI.EAN,
ROOT.F.AN,
BOOT.EAN,
ROOT.F.AN,
BOOLEAN,
BOOLEAN,
BOOT.FAN
Figure imgf000017_0001
F.NUMFRATF.n ( a n í i b l K d | OPTTONAT. — C o n d RN
i) ,
| l pdop-SN -S ¡ z e - v 1130 F.NUMERATEO ( I e n l b b i l . s } OPTIONA!. - - C o n d Rlc;-AM 2
11,
| | u l- D a ta 5 p l í t D R B - V ia S C G - r l2 BOOLEAN OPTIONAL, — N e c e s it a Encendido
t - R e o r d e r t n g- r 17. ENUMERATED {
mcO, m s20 , n>340, m s60 , m 380, ro s l00 f ms 120# m s l40 ,
rasl 6U, ranlHU, ras20ü , m s220 , m s240 , m s260 , m s2üü , rosiUO, rasSOO, ras750 , s p a r c l 4 , a p a r o l 3 , s p a r e l 2 , s p a r c l l ,
u p a r c l 0 ,
Figure imgf000018_0001
s e t u p SEQUENCE |
ul-T.WA-DRR-ViaWTAN-rl A ROOT.EAN,
ul-LWA-DataSplitThrcshold-rl4 ENUMERATED (
bO, blOO, b200, b400, b800, bl600f b3200, b6400,
bl2800, b25600, b51200, bl02400, b204800, b409600,
y OPTTONAT. - - Necesita OR
Figure imgf000019_0001
Encendido
OPl'IONAE -- Necesita Encendido
M,
II up lin k D ataC orap ression -rl5 SEQUENCE |
b u l C c rS iz c - r l5 ENUMERATED (.kbylc2, k b y lc i , kbyleO, s p a r e l } ,
d ic l io n a r y - r l5 KKUNEKATGD {sip -SD l*, o p e ra lo r ) O Pl’ION AL, - - Necesita OR
I OPTIONAL,— Cond Rlc-AM2 pdcp-D u plica lion C on C iq-rlB CHOICE |
r o l c a s e NiJT.Tt,
se lu p SEQUENCE \
pdcp-Duplica t í on-rlb ENUMERATF.D Iconíigured, acttvated)
i
| OPTIONAL - - Necesita Encendido
n
— ASM. PARAR
En LTE, los parámetros de enlace lateral para la compresión y descompresión de cabecera se preconfiguran (como se explica en 3GPP TS 36.331) como sigue:
S L - P r e c o n ± i g G e n e r a l - r l 2 : : = SEQUENCE (
— C o n fig u ra c ió n PDCP
r o h c - P r o T i l e s - r l 7 ñKQUKNCE (
p r o f i leOxOQQl - r ! 2 ROOI.RAN,
p r o f i IeOxOOQ2-r]7 BOOLEAN,
p ro i ' i leO xÜ O tH i l ü QOOLEñN,
p r o f i í c 0 x 0 G ( } 6 - r l 2 ÓOOLMN,
p r o f H «O xOJ01-t-T2 ROOI.F’.AN,
p r o f i I « 0 x 0 i a ? . - r l ? FÍOOLEAN,
p r a t i i c 0 x C > l U 4 - r l 2 .. . BOOliEAN
t.
En LTE, los parámetros de enlace lateral para la compresión y descompresión de cabecera se preconfiguran (como se explica en 3GPP TS 36.331). De acuerdo con 3GPP TR 38.885, un UE en RRC Conectado puede enviar una Solicitud de configuración de Portador de Radio de Enlace Lateral (SLRB) a gNB para un flujo de QoS (calidad de servicio) de PC5 usado para las comunicaciones de unidifusión, difusión o difusión grupal en Nueva RAT/Radio (NR) Vehículo a Todo (V2X). En respuesta, el gNB puede proporcionar una configuración SLRB específica para el UE. La configuración SLRB puede incluir una configuración PDCP. Típicamente, los parámetros para la compresión y descompresión de cabecera se incluirán en la configuración de PDCP.
Como se especifica en 3GPP TS 23.287, tanto los mensajes V2X basados en IP como los no basados en IP son soportados por el punto de referencia PC5 en NR V2X. En el caso de los mensajes V2X basados en IP, puede aplicarse compresión y descompresión de cabecera. Dado que el procedimiento de configuración de SLRB especificado en 3GPP TR38.885 no incluye ninguna información que indique si los mensajes V2X basados en IP o no basados en IP se transmitirán en el SLRB en cuestión, el gNB no puede determinar si se debe aplicar o no la compresión y descompresión de cabecera.
Para resolver el problema anterior, el UE puede enviar información que indique que los mensajes V2X basados en IP o no basados en IP se transmitirán en un flujo de QoS de PC5 o en un SLRB que se configurará para el flujo de QoS de PC5 cuando envíe una solicitud de configuración de SLRB al gNB para el flujo de QoS de PC5, de modo que el gNB pueda determinar si se debe aplicar la compresión y descompresión de cabecera al SLRB.
Alternativamente, el UE puede enviar información que indique que se transmitirán los mensajes V2X basados en IP o no basados en IP para un servicio o aplicación V2X (o un destino de la Capa 2 asociado con el servicio o aplicación V2X) cuando envía un mensaje (por ejemplo, SidelinkUEInformación) para informar a gNB que se interesa en la comunicación de enlace lateral V2X. Esta alternativa es factible porque los mensajes V2X basados en IP y no basados en IP no se transmitirán a través del mismo enlace de unidifusión de acuerdo con 3GPP TS 23.287 (es decir, todos los mensajes V2X del mismo servicio o aplicación V2X se basan en IP o no se basan en IP). Dado que el tráfico de un servicio o aplicación V2X se transmite con un destino de la Capa 2, el destino de la Capa 2 asociado con el servicio o aplicación V2X puede usarse para identificar el servicio o aplicación V2X en el UE. Con la información enviada desde el UE, el gNB puede determinar si debe aplicarse o no la compresión y descompresión de cabecera para el flujo de QoS de PC5 o el SLRB. De esta forma, el gNB puede indicar si debe aplicarse la compresión y descompresión de cabecera para un SLRB en una configuración PDCP incluida una configuración SLRB que se usa para configurar el SLRB para el UE. Se observa que un servicio V2X puede ofrecerse por un V2X.
Además, de acuerdo con 3GPP TS 36.323, cada perfil para compresión y descompresión de cabeceras (perfil ROHC (Compresión de Cabecera Robusta)) podría ser específico para la capa de red particular, la capa de transporte o la combinación de los protocolos de la capa superior (por ejemplo, TCP/IP y RTP/UDP/IP). Dado que puede necesitarse aplicar la compresión y descompresión de cabecera para un SLRB, el gNB puede necesitar determinar además qué perfil(es) ROHC debe(n) configurarse para el SLRB. Por lo tanto, el UE puede necesitar transmitir información que indique la capa de red, la capa de transporte o la combinación de protocolos de la capa superior (por ejemplo, TCP/iP y RTP/UDP/IP) usada en la parte superior de un SLRB cuando envía una Solicitud de configuración de SLRB al gNB para un Flujo de QoS de PC5. Alternativamente, el UE puede enviar información que indica la capa de red, la capa de transporte o la combinación de protocolos de la capa superior usada para soportar un servicio o aplicación V2X (o un destino de la Capa 2 asociado con el servicio o aplicación V2X) cuando envía un mensaje (por ejemplo, SidelinkUEInformación) para informar al gNB que se interesa en la comunicación de enlace lateral V2X. Con la información enviada desde el UE, el gNB puede determinar los perfiles ROHC permitidos que se aplicarán o configurarán para el SLRB. De esta forma, el gNB indica el(los) perfil(es) ROHC permitido(s) para una SLRB en una configuración PDCP incluida en una configuración SLRB usada para configurar el SLRB para el UE.
Los perfiles ROHC aplicables también pueden depender de la capacidad del UE, es decir, solo los perfiles ROHC soportados por el UE pueden configurarse para el UE. En caso de unidifusión, deben considerarse las capacidades de los UE de ambos Ue que participan en la unidifusión. Dado que ambos UE pueden intercambiar capacidades de UE entre sí a través de, por ejemplo, mensajes PC5-RRC, un UE (por ejemplo, TX UE) puede transmitir las capacidades de UE de ambos UE sobre los perfiles ROHC soportados al gNB. Es más eficiente en la señalización que el UE transmita esos perfiles comúnmente soportados por ambos UE al gNB.
Las soluciones mencionadas anteriormente se basan en la suposición de que toda la configuración PDCP para un SLRB se configura por el gNB. También es factible que un UE determine si debe aplicarse la compresión y descompresión de cabecera para un SLRB de acuerdo con si los mensajes V2X basados en IP o no basados en IP se transmitirán en un flujo de QoS PC5 o en un SLRB que se configurará para el flujo de QoS PC5. Además, el UE puede determinar los perfiles ROHC para solicitar un SLRB de acuerdo con los perfiles comúnmente soportados por ambos UE que participan en una unidifusión, mientras que parte de los parámetros PDCP (por ejemplo, discardTimer, pdcp-SN-Size, y/o t-Reordering, etc.) se obtienen del gNB. Ambos UE pueden determinar los perfiles ROHC comúnmente soportados intercambiando la capacidad del UE entre sí, por ejemplo, a través de mensajes PC5-RRC.
En caso de difusión o difusión grupal, no se establece un enlace lateral directo entre los UE. Como resultado, una TX de UE no puede reenviar la configuración SLRB o la configuración PDCP a los RX de UE. Una posible solución es que un nodo de red (por ejemplo, Función de Control V2X) proporcione los perfiles ROHC aplicables tanto a TX de Ue como a RX de UE durante la autorización del servicio V2X. En otras palabras, el nodo de red (por ejemplo, la Función de Control V2X) proporciona los perfiles ROHC aplicables a un servicio V2X a un UE cuando el Ue solicita autorización de servicio para un servicio V2X. Esta solución también puede aplicarse a la unidifusión.
La Figura 11 es un diagrama de flujo 1100 de acuerdo con una realización ilustrativa desde la perspectiva de un UE para aplicar la compresión y descompresión de cabecera en un SLRB. En el paso 1105, el UE obtiene al menos un parámetro PDCP para el SLRB de un nodo de red. En el paso 1110, el UE determina si la compresión y descompresión de cabecera se usa para transmitir mensajes V2X en el SLRB de acuerdo con si los mensajes V2X basados en IP o no basados en IP se transmitirán en el SLRB, en el que se usa la compresión y descompresión de cabecera si los mensajes V2X basados en IP van a transmitirse en el SLRB, y la compresión y descompresión de cabecera no se usa si los mensajes V2X no basados en IP van a transmitirse en el SLRB.
Preferentemente, el al menos un parámetro de PDCP puede incluir un discardTimer, un PDCP-SN-Size de PDCP y/o un t-Reordering. Sin embargo, el al menos un parámetro PDCP puede no incluir ningún parámetro usado para determinar si se usa compresión y descompresión de cabecera para transmitir los mensajes V2X en el SLRB.
Preferentemente, el UE podría estar en RRC_CONNECTED. El UE podría transmitir una solicitud de configuración de SLRB para establecer el SLRB al nodo de red. El UE también podría recibir la configuración SLRB desde el nodo de red.
Preferentemente, la configuración del SLRB puede incluir una configuración PDCP para el SLRB. La configuración de PDCP puede incluir al menos un parámetro de PDCP. La solicitud de configuración de SLRB podría transmitirse al nodo de red a través de un mensaje SidelinkUEInformation. El nodo de red podría ser una estación base (por ejemplo, gNB).
Con referencia de vuelta a las Figuras 3 y 4, en una realización ilustrativa de un UE. El primer UE 300 incluye un código del programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código del programa 312 para permitir que el UE (i) obtenga al menos un parámetro PDCP para un SLRB de un nodo de red, y (ii) determine si la compresión y descompresión de cabecera se usan para transmitir mensajes V2X en el SLRB de acuerdo con si los mensajes V2X basados en IP o no basados en IP deben transmitirse en SLRB, en el que la compresión y descompresión de cabecera se usa si los mensajes V2X basados en IP deben transmitirse en SLRB, y la compresión y descompresión de cabecera no se usa si van a transmitirse mensajes V2X no basados en IP en el SLRB. Además, la CPU 308 puede ejecutar el código del programa 312 para realizar todas las acciones y etapas descritos anteriormente u otros descritos en la presente memoria.
La Figura 12 es un diagrama de flujo 1200 de acuerdo con una realización ilustrativa desde la perspectiva de un UE para indicar la información para la configuración de la compresión de cabecera. En el paso 1205, el UE envía la información a un nodo de red, en el que la información indica los mensajes V2X basados en IP o no basados en IP para usar en una SLRB o para soportar una comunicación de enlace lateral V2X (o un servicio V2X). En el paso 1210, el UE recibe una configuración de PDCP para el SLRB, en la que la configuración de PDCP indica si se usa una compresión de cabecera para el SLRB.
Preferentemente, la información podría incluirse en un primer mensaje de RRC usado para solicitar una configuración de SLRB para un flujo de QoS de PC5. La información también podría incluirse en un segundo mensaje RRC que se usa para informar al nodo de red que el UE se interesa en la comunicación de enlace lateral V2X (o el servicio V2X), en el que el segundo mensaje RRC incluye un destino de la Capa 2 asociado con la comunicación de enlace lateral v 2x (o el servicio V2X).
Preferentemente, el SLRB podría usarse para la transferencia de tráfico durante la comunicación de enlace lateral V2X, en el que la comunicación de enlace lateral V2X soporta el servicio V2X. La comunicación de enlace lateral V2X podría ser una comunicación de unidifusión, difusión o difusión grupal.
Preferentemente, el primer mensaje RRC podría ser un mensaje SidelinkUEInformation. El segundo mensaje RRC podría ser un UEAssistanceInformation.
Con referencia de vuelta a las Figuras 3 y 4, en una realización ilustrativa de un UE. El primer UE 300 incluye un código del programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código del programa 312 para permitir que el UE (i) envíe información a un nodo de red, en el que la información indica que los mensajes V2X basados en IP o no basados en IP se usarán en un SLRB o se usarán para soportar una comunicación de enlace lateral V2X (o un servicio V2X), y (ii) para recibir una configuración de PDCP para el SLRB, en el que la configuración de PDCP indica si se usa una compresión de cabecera para el SLRB. Además, la CPU 308 puede ejecutar el código del programa 312 para realizar todas las acciones y etapas descritos anteriormente u otros descritos en la presente memoria.
La Figura 13 es un diagrama de flujo 1300 de acuerdo con una realización ilustrativa desde la perspectiva de un UE para indicar la información para la configuración de la compresión de cabecera. En el paso 1305, el UE envía información a un nodo de red, en el que la información indica una combinación de protocolos usada sobre un SLRB o usada para soportar una comunicación de enlace lateral V2X (o un servicio V2X). En el paso 1310, el UE recibe una configuración PDCP para el SLRB, en la que la configuración PDCP indica los perfiles ROHC permitidos que se usan para el SLRB.
Preferentemente, la combinación de los protocolos puede significar una combinación de los protocolos de la capa de red, la capa de transporte o la capa superior. La información puede incluirse en un primer mensaje RRC usado para solicitar una configuración SLRB para un flujo de QoS de PC5. La información también puede incluirse en un segundo mensaje RRC usado para informar al nodo de red que el UE se interesa en la comunicación de enlace lateral V2X (o el servicio V2X), en el que el segundo mensaje RrC incluye un destino de la Capa 2 asociado con la comunicación de enlace lateral V2X (o el servicio V2X).
Preferentemente, el SLRB puede usarse para la transferencia de tráfico durante la comunicación de enlace lateral V2X, en el que la comunicación de enlace lateral V2X soporta el servicio V2X. La comunicación de enlace lateral V2X podría ser una comunicación de unidifusión, difusión o difusión grupal.
Preferentemente, el primer mensaje RRC puede ser un mensaje SidelinkUEInformation. El segundo mensaje RRC puede ser un UEAssistanceInformation.
Con referencia de vuelta a las Figuras 3 y 4, en una realización ilustrativa de un UE. El UE 300 incluye un código del programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código del programa 312 para permitir que el UE (i) envíe la información a un nodo de red, en el que la información indica una combinación de protocolo que se usa sobre un SLRB o usada para soportar una comunicación de enlace lateral V2X (o un servicio V2X) y (ii) para recibir una configuración de PDCP para el SLRB, en la que la configuración de PDCP indica los perfiles ROHC permitidos que se usan para el SLRB. Además, la CPU 308 puede ejecutar el código del programa 312 para realizar todas las acciones y etapas descritos anteriormente u otros descritos en la presente memoria.
La Figura 14 es un diagrama de flujo 1400 de acuerdo con una realización ilustrativa desde la perspectiva de un UE para determinar una configuración de compresión de cabecera para un SLRB. En el paso 1405, el UE determina si la compresión y descompresión de cabecera se usa para un SLRb de acuerdo con si los mensajes V2X basados en IP o no basados en IP se transmitirán en el SLRB, en el que la compresión y descompresión de cabecera se usa si los mensajes V2X basados en IP se transmitirán en el SLRB y la compresión y descompresión de cabecera no se usa si los mensajes V2X basados en la no-IP se transmitirán en el SLRB.
Con referencia de vuelta a las Figuras 3 y 4, en una realización ilustrativa de un UE. El UE 300 incluye un código del programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código del programa 312 para permitir que el UE determine si se usa compresión y descompresión de cabecera para un SLRB de acuerdo con si los mensajes V2X basados en IP o no basados en IP se transmitirán en el SLRB, en el que la compresión y descompresión de cabecera se usa si los mensajes V2X basados en IP se transmitirán en SLRb y la compresión y descompresión de cabecera no se usa si los mensajes V2X no basados en IP se transmitirán en SLRB. Además, la CPU 308 puede ejecutar el código del programa 312 para realizar todas las acciones y etapas descritos anteriormente u otros descritos en la presente memoria.
La Figura 15 es un diagrama de flujo 1500 de acuerdo con una realización ilustrativa desde la perspectiva de un UE para determinar una configuración de compresión de cabecera para un SLRB. En el paso 1505, el UE determina los perfiles ROHC que se usarán para una SLRB de acuerdo con las capacidades del UE y un UE par, en el que se establece un enlace de unidifusión entre el UE y el UE par y en el que los perfiles ROHC son iguales a los perfiles ROHC comúnmente soportado por el UE y el UE par.
Preferentemente, el UE puede obtener parte de los parámetros PDCP de un nodo de red (por ejemplo, el gNB). La parte de los parámetros PDCP puede incluir al menos discardTimer, pdcp-SN-Size, y/o t-Reordering.
Preferentemente, el UE puede determinar los perfiles de ROHC soportados comúnmente de acuerdo con los perfiles de ROHC soportados por el UE y los perfiles de ROHC soportados por el UE par. Además, el UE puede obtener los perfiles ROHC soportados por el UE par de acuerdo con la capacidad del UE recibida del UE par (por ejemplo, a través de un mensaje PC5-RRC).
Con referencia de vuelta a las Figuras 3 y 4, en una realización ilustrativa de un UE. El UE 300 incluye un código del programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código del programa 312 para permitir que el UE determine los perfiles ROHC que se utilizarán para un SLRb de acuerdo con las capacidades del Ue y un Ue par, en el que se establece un enlace de unidifusión entre el UE y el UE par y en el que los perfiles ROHC son iguales a los perfiles ROHC comúnmente soportados por el UE y el UE par. Además, la CPU 308 puede ejecutar el código del programa 312 para realizar todas las acciones y etapas descritos anteriormente u otros descritos en la presente memoria.
Diversos aspectos de la divulgación se han descrito anteriormente. Debe ser evidente que las enseñanzas en la presente memoria pueden realizarse en una amplia variedad de formas y que cualquier estructura específica, función, o ambas que se divulgan en la presente memoria es simplemente representativa. En base a las enseñanzas en la presente memoria un experto en la técnica debe apreciar que un aspecto divulgado en la presente memoria puede implementarse independientemente de cualesquiera otros aspectos y que dos o más de estos aspectos pueden combinarse de diversos modos. Por ejemplo, puede implementarse un aparato o puede practicarse un procedimiento mediante el uso de cualquier número de los aspectos que se exponen en la presente memoria. Además, tal aparato puede implementarse o tal procedimiento puede practicarse mediante el uso de otra estructura, funcionalidad, o estructura y funcionalidad además de o diferente de uno o más de los aspectos que se exponen en la presente memoria. Como un ejemplo de algunos de los conceptos anteriores, en algunos aspectos pueden establecerse canales concurrentes en base a las frecuencias de repetición del pulso. En algunos aspectos pueden establecerse canales concurrentes en base a la posición o desplazamientos del pulso. En algunos aspectos pueden establecerse canales concurrentes en base a las secuencias de salto de tiempo. En algunos aspectos pueden establecerse canales concurrentes en base a las frecuencias de repetición del pulso, a posición o desplazamientos del pulso, y las secuencias de salto de tiempo.
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 se pueden referenciar a lo largo de la descripción anterior se pueden representar 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 que se describen en relación con los aspectos que se divulgan 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 de fuente o alguna otra técnica), diversas formas de código del programa o diseños que incorporan instrucciones (que pueden denominarse en la presente memoria, para 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 dicha funcionalidad se implementa como hardware o software depende de la aplicación particular y las restricciones de diseño impuestas en el sistema general. Los expertos en la técnica pueden implementar la funcionalidad descrita de diversos modos para cada aplicación particular, pero dichas decisiones de implementación no deben interpretarse como que provocan una desviación del ámbito de la presente divulgación.
Además, los diversos bloques, módulos, y circuitos lógicos ilustrativos descritos en relación con los aspectos divulgados en la presente memoria pueden implementarse dentro de o realizarse por un circuito integrado ("IC"), un terminal de acceso, o un punto de acceso. El IC puede comprender un procesador de propósito general, un procesador de señal digital (DSP), un circuito integrado de aplicación específica (ASIC), un arreglo de puerta programable de campo (FPGA) u otro dispositivo lógico programable, puerta discreta o lógica de transistor, componentes de hardware discretos, componentes eléctricos, componentes ópticos, componentes mecánicos, o cualquier combinación de los mismos diseñados para realizar las funciones descritas en la presente memoria, y pueden ejecutar códigos o instrucciones que se encuentran dentro del IC, fuera del IC, o ambos. Un procesador de propósito general puede ser un microprocesador, pero en la alternativa, el procesador puede ser cualquier procesador convencional, controlador, microcontrolador, o máquina de estado. Un procesador puede implementarse también como una combinación de dispositivos informáticos, por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP, o cualquier otra dicha configuración.
Se entiende que cualquier orden o jerarquía específicos de las etapas en cualquier procedimiento divulgado es un ejemplo de un enfoque de muestra. En base a las preferencias de diseño, se entiende que el orden específico o la jerarquía de los pasos en los procesos puede reordenarse permaneciendo dentro del ámbito de la presente divulgación, como se define en las reivindicaciones adjuntas.
Las etapas de un procedimiento o algoritmo descritas en relación con los aspectos divulgados en la presente memoria pueden realizarse directamente en el hardware, en un módulo de software ejecutado por un procesador, o en una combinación de los dos. Un módulo de software (por ejemplo, que incluye instrucciones ejecutables y datos relacionados) y otros datos pueden encontrarse en una memoria de datos como la memoria RAM, la memoria flash, la memoria ROM, la memoria EPROM, la memoria EEPROM, los registros, un disco duro, un disco extraíble, un CD-ROM, o cualquier otra forma de medio de almacenamiento legible por ordenador conocido en la técnica. Puede acoplarse un medio de almacenamiento de muestra a una máquina tal como, por ejemplo, un ordenador/procesador (que puede denominarse en la presente memoria, por conveniencia, como un "procesador") tal que el procesador pueda leer información (por ejemplo, el código) desde y escribir información al medio de almacenamiento. Un medio de almacenamiento de muestra puede integrarse al procesador. El procesador y el medio de almacenamiento pueden encontrarse en un ASIC. El ASIC puede encontrarse en el equipo de usuario. En la alternativa, el procesador y el medio de almacenamiento pueden encontrarse como componentes discretos en el equipo de usuario. Además, en algunos aspectos cualquier producto de programa por ordenador adecuado puede comprender un medio legible por ordenador que comprende códigos que se relacionan con uno o más de los aspectos de la divulgación. En algunos aspectos un producto de programa por ordenador puede comprender materiales de envase.
Aunque la invención se ha descrito en relación con diversos aspectos, se entenderá que la invención es capaz de modificaciones adicionales. El ámbito de la invención se define por las reivindicaciones adjuntas

Claims (6)

REIVINDICACIONES
1. Un procedimiento para un equipo de usuario, en lo sucesivo también denominado UE, para aplicar la compresión de cabecera en un Portador de Radio de Enlace Lateral, en lo sucesivo también denominado SLRB, que comprende:
transmitir una solicitud a un nodo de red para una configuración de SLRB para establecer el SLRB que se usa para Vehículo a todo, en lo sucesivo también denominado comunicación de enlace lateral V2X, con uno o más otros UE;
recibir (1105) la configuración de SLRB desde el nodo de red, en el que la configuración de SLRB incluye un Protocolo de Convergencia de Datos en Paquetes, en lo sucesivo también denominado PDCP, configuración para el SLRB, y en el que la configuración de PDCP incluye al menos un parámetro de PDCP para el SLRB; y
determinar (1110) si la compresión de cabecera se usa para transmitir los mensajes V2X en el SLRB de acuerdo con si los mensajes V2X de Protocolo de Internet, en lo sucesivo también denominados IP, basados o no basados en IP, se transmitirán en el SLRB, en el que la compresión de cabecera se usa si los mensajes V2X basados en IP van a transmitirse en el SLRB, y la compresión de cabecera no se usa si los mensajes V2X no basados en IP van a transmitirse en el SLRB,
caracterizada porque
la configuración de PDCP no incluye ningún parámetro que se use para determinar si se usa la compresión de cabecera para transmitir los mensajes V2X en el SLRB.
2. El procedimiento de la reivindicación 1, en el que el al menos un parámetro PDCP incluye un discardTimer, un PDCP-SN-Size, y/o un t-Reordering.
3. El procedimiento de la reivindicación 1 o 2, en el que el UE está en RRC_CONNECTED.
4. El procedimiento de una cualquiera de las reivindicaciones 1 a 3, en el que la solicitud de configuración del SLRB se transmite al nodo de red mediante un mensaje SidelinkUEInformation.
5. El procedimiento de una cualquiera de las reivindicaciones 1 a 4, en el que el nodo de red es una estación base.
6. Un equipo de usuario, en lo siguiente denominado también como 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) está configurado para ejecutar un código de programa (312) almacenado en la memoria (310) para realizar los pasos del procedimiento como se define en una cualquiera de las reivindicaciones anteriores.
ES20191025T 2019-08-23 2020-08-14 Procedimiento y aparato para la configuración de la compresión de cabecera para el portador de radio de enlace lateral en un sistema de comunicación inalámbrica Active ES2917823T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201962890852P 2019-08-23 2019-08-23

Publications (1)

Publication Number Publication Date
ES2917823T3 true ES2917823T3 (es) 2022-07-11

Family

ID=72139440

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20191025T Active ES2917823T3 (es) 2019-08-23 2020-08-14 Procedimiento y aparato para la configuración de la compresión de cabecera para el portador de radio de enlace lateral en un sistema de comunicación inalámbrica

Country Status (5)

Country Link
US (1) US10951745B1 (es)
EP (1) EP3787368B1 (es)
KR (1) KR102434217B1 (es)
CN (1) CN112423319B (es)
ES (1) ES2917823T3 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4030738A1 (en) * 2018-03-16 2022-07-20 Acklio Method and apparatus for processing message data
TWI713399B (zh) * 2018-08-03 2020-12-11 華碩電腦股份有限公司 無線通訊系統中用於處理側鏈路接收的方法和設備
ES2973526T3 (es) 2021-01-19 2024-06-20 Lg Energy Solution Ltd Terminal de electrodo, celda de batería cilíndrica, paquete de baterías y vehículo
EP4213296A1 (en) 2021-02-19 2023-07-19 LG Energy Solution, Ltd. Battery, and battery pack and vehicle comprising same
CA3202337A1 (en) 2021-02-19 2022-08-25 Min-Ki Jo Battery, and battery pack and vehicle including the same

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3105957B1 (en) * 2014-02-10 2019-04-03 LG Electronics Inc. Method and apparatus for indicating qos of d2d data in wireless communication system
US9913310B2 (en) * 2014-04-24 2018-03-06 Lg Electronics Inc. Method for establishing layer-2 entities for D2D communication system and device therefor
WO2016076510A1 (en) * 2014-11-10 2016-05-19 Lg Electronics Inc. Method for indicating a ciphering indication for a sidelink radio bearer in a d2d communication system and device therefor
US10687175B2 (en) * 2015-08-14 2020-06-16 Lg Electronics Inc. Method for transmitting and receiving V2X message in wireless communication system, and an apparatus for same
KR102127397B1 (ko) * 2016-03-22 2020-06-26 엘지전자 주식회사 데이터 유닛을 전송하는 방법 및 사용자기기와, 데이터 유닛을 수신하는 방법 및 사용자기기
US10924912B2 (en) * 2017-01-06 2021-02-16 Lg Electronics Inc. Method for transmitting and receiving data through relay in wireless communication system and apparatus therefor
US20180324631A1 (en) * 2017-05-05 2018-11-08 Mediatek Inc. Using sdap headers for handling of as/nas reflective qos and to ensure in-sequence packet delivery during remapping in 5g communication systems
EP3547770B1 (en) * 2017-09-14 2021-12-01 LG Electronics Inc. Method for performing v2x communication in wireless communication system and apparatus therefor
US10855814B2 (en) * 2017-10-20 2020-12-01 Comcast Cable Communications, Llc Non-access stratum capability information
US20190215729A1 (en) * 2018-03-15 2019-07-11 Intel Corporation Session description protocol mechanisms for signaling radio access network capabilities in multimedia telephony sessions
US20200259896A1 (en) * 2019-02-13 2020-08-13 Telefonaktiebolaget Lm Ericsson (Publ) Industrial Automation with 5G and Beyond

Also Published As

Publication number Publication date
CN112423319A (zh) 2021-02-26
US10951745B1 (en) 2021-03-16
EP3787368A1 (en) 2021-03-03
US20210058497A1 (en) 2021-02-25
CN112423319B (zh) 2024-05-14
KR20210024424A (ko) 2021-03-05
EP3787368B1 (en) 2022-04-13
KR102434217B1 (ko) 2022-08-19

Similar Documents

Publication Publication Date Title
ES2897684T3 (es) Procedimientos y aparatos para el establecimiento de canales lógicos de enlace lateral en un sistema de comunicación inalámbrica
ES2924692T3 (es) Procedimiento y aparato para la solicitud de recursos en la transmisión de enlace lateral en un sistema de comunicación inalámbrica
CN110447250B (zh) 用于无线通信系统中层之间交互的方法及其设备
ES2917823T3 (es) Procedimiento y aparato para la configuración de la compresión de cabecera para el portador de radio de enlace lateral en un sistema de comunicación inalámbrica
ES2917776T3 (es) Reporte de información sobre la capacidad del equipo de usuario para la configuración del portador de radio del enlace lateral en un sistema de comunicación inalámbrica
EP3758433A1 (en) Method and apparatus for configuring sidelink communication in a wireless communication system
CN111356113A (zh) 无线通信系统中用于支持一对一侧链路通信的方法和设备
EP3817447A1 (en) Method and apparatus for supporting qos (quality of service) flow to drb (data radio bearer) remapping for sidelink communication in a wireless communication system
ES2908084T3 (es) Procedimiento y aparato para liberar portador de radio de enlace lateral en un sistema de comunicación inalámbrica
ES2930300T3 (es) Procedimiento y aparato para la modificación de la información de calidad de servicio (QoS) en un sistema de comunicación inalámbrica
ES2916801T3 (es) Procedimiento y aparato para el establecimiento de portadores de radio de señalización (SRB) de enlace lateral en un sistema de comunicación inalámbrica
US20210259039A1 (en) Method and apparatus for handling invalid rrc reconfiguration message for sidelink communication in a wireless communication system
ES2932964T3 (es) Procedimiento y aparato para solicitar recursos de transmisión de enlace lateral en un sistema de comunicación inalámbrica
US20220377598A1 (en) Method and apparatus for supporting ue-to-network relay communication in a wireless communication system