ES2882300T3 - Procedimiento y aparato para admitir servicios de vehículo a todo (V2X) en un único enlace de comunicación unívoca con enlace lateral en un sistema de comunicación inalámbrica - Google Patents

Procedimiento y aparato para admitir servicios de vehículo a todo (V2X) en un único enlace de comunicación unívoca con enlace lateral en un sistema de comunicación inalámbrica Download PDF

Info

Publication number
ES2882300T3
ES2882300T3 ES19220167T ES19220167T ES2882300T3 ES 2882300 T3 ES2882300 T3 ES 2882300T3 ES 19220167 T ES19220167 T ES 19220167T ES 19220167 T ES19220167 T ES 19220167T ES 2882300 T3 ES2882300 T3 ES 2882300T3
Authority
ES
Spain
Prior art keywords
service
link
message
communication
side link
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
ES19220167T
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 ES2882300T3 publication Critical patent/ES2882300T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/047—Key management, e.g. using generic bootstrapping architecture [GBA] without using a trusted network node as an anchor
    • H04W12/0471—Key exchange
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • 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
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • 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
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un procedimiento para un primer equipo de usuario, a continuación, también denominado UE, que admite múltiples servicios en un enlace de comunicación unívoca con enlace lateral entre el primer UE y un segundo UE, que comprende: iniciar un primer servicio (2505); establecer el enlace de comunicación unívoca con enlace lateral para el primer servicio (2510); negociar una configuración de seguridad con el segundo UE para cifrar o descifrar datos del primer servicio (2515); iniciar un segundo servicio (2520); y cifrar o descifrar datos del segundo servicio con la configuración de seguridad utilizada por el primer servicio (2525).

Description

DESCRIPCIÓN
Procedimiento y aparato para admitir servicios de vehículo a todo (V2X) en un único enlace de comunicación unívoca con enlace lateral en un sistema de comunicación inalámbrica
Esta divulgación se refiere en general a redes de comunicaciones inalámbricas y, más en particular, a un procedimiento y aparato para admitir servicios de vehículo a todo (V2X) en un único enlace de comunicación unívoca con enlace lateral en un sistema de comunicación inalámbrica.
Con el rápido aumento de la demanda de comunicación de grandes cantidades de datos hacia y desde dispositivos de comunicación móvil, las redes de comunicación de voz móviles tradicionales están evolucionando hacia redes que se comunican con paquetes de datos de protocolo de Internet (IP). Dicha comunicación de paquetes de datos IP puede proporcionar a los usuarios de dispositivos de comunicación móviles servicios de comunicación de voz sobre IP, multimedia, multidifusión y bajo demanda.
Una estructura de red ejemplar es una red de acceso por radio terrestre universal evolucionada (E-UTRAN). El sistema E-UTRAN puede proporcionar un alto rendimiento de datos para realizar los servicios multimedia y de voz sobre IP mencionados anteriormente. La organización de estándares 3GPP está analizando actualmente una nueva tecnología de radio para la próxima generación (por ejemplo, 5G). En consecuencia, se están presentando cambios en el cuerpo actual del estándar 3GPP y se está considerando que evolucionen y finalicen el estándar 3GPP.
SUMARIO
Un procedimiento y un aparato se describen desde la perspectiva de un primer UE (equipo de usuario) para admitir múltiples servicios en un enlace de comunicación unívoca con enlace lateral entre el primer UE y un segundo UE y se definen en las reivindicaciones independientes. Las reivindicaciones dependientes definen modos de realización preferentes de las mismas. En un modo de realización, el primer UE inicia un primer servicio. El primer UE también establece el enlace de comunicación unívoca con enlace lateral para el primer servicio. Además, el primer UE negocia una configuración de seguridad con el segundo UE para cifrar o descifrar datos del primer servicio. Además, el primer UE inicia un segundo servicio. El primer UE también cifra o descifra datos del segundo servicio con la configuración de seguridad utilizada por el primer servicio.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La FIG. 1 muestra un diagrama de un sistema de comunicación inalámbrica de acuerdo con un modo de realización ejemplar.
La FIG. 2 es un diagrama de bloques de un sistema transmisor (también conocido como red de acceso) y un sistema receptor (también conocido como equipo de usuario o UE) de acuerdo con un modo de realización ejemplar.
La FIG. 3 es un diagrama de bloques funcional de un sistema de comunicación de acuerdo con un modo de realización ejemplar.
La FIG. 4 es un diagrama de bloques funcional del código de programa de la FIG. 3 de acuerdo con un modo de realización ejemplar.
La FIG. 5 es una reproducción de la figura 5.4.5.2-1 del 3GPP TS 23.303 V15.1.0.
La FIG. 6 es una reproducción de la figura 6.11.3.1-1 del 3GPP TR 23.786 V1.0.0.
La FIG. 7 es una reproducción de la figura 6.11.3.1-2 del 3GPP TR 23.786 V1.0.0.
La FIG. 8 es una reproducción de la figura 10.4.2.2.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 9 es una reproducción de la tabla 11.4.2.1.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 10 es una reproducción de la tabla 11.4.3.1.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 11 es una reproducción de la tabla 11.4.12A.1.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 12 es una reproducción de la tabla 11.4.13.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 13 es una reproducción de la figura 12.5.1.4.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 14 es una reproducción de la tabla 12.5.1.4.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 15 es una reproducción de la figura 12.5.1.5.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 16 es una reproducción de la tabla 12.5.1.5.1 del 3GPP TR 24.334 V15.2.0.
La FIG. 17 es una reproducción de la figura 6.5.3.3-1 del 3GPP TS 33.303 V15.0.0.
La FIG. 18 es una reproducción de la figura 6.5.5.2-1 del 3GPP TS 33.303 V15.0.0.
La FIG. 19 es un diagrama de acuerdo con un modo de realización ejemplar.
La FIG. 20 es un diagrama de acuerdo con un modo de realización ejemplar.
La FIG. 21 es un diagrama de acuerdo con un modo de realización ejemplar.
La FIG. 22 es un diagrama de acuerdo con un modo de realización ejemplar.
La FIG. 23 es un diagrama de acuerdo con un modo de realización ejemplar.
La FIG. 24 es un diagrama de acuerdo con un modo de realización ejemplar.
La FIG. 25 es un diagrama de flujo de acuerdo con un modo de realización ejemplar.
DESCRIPCIÓN DETALLADA
Los sistemas y dispositivos de comunicación inalámbrica ejemplares descritos a continuación emplean un sistema de comunicación inalámbrica, que admite un servicio de radiodifusión. Los sistemas de comunicación inalámbrica están ampliamente desplegados para proporcionar diversos tipos de comunicación, tales como voz, datos, y así sucesivamente. Estos sistemas pueden estar basados en acceso múltiple por división de código (CDMA), acceso múltiple por división de tiempo (TDMA), acceso múltiple por división ortogonal de frecuencia (OFDMA), acceso inalámbrico 3GPP LTE (Evolución a largo plazo), 3GPP LTE-A o LTE-avanzada (Evolución avanzada a largo plazo), 3GPP2 UMB (Banda Ancha Ultramó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 ejemplares descritos a continuación pueden diseñarse para admitir uno o más estándares, como el estándar ofrecido por un consorcio denominado "Proyecto de Colaboración de Tercera Generación" al que se hace referencia en el presente documento como 3GPP, que incluye:
TS 24.386 V15.1.0, "User Equipment (UE) to V2X control function; protocol aspects"; Nota del presidente 3GPPRAN1 núm. 94; TR23.786 V1.0.0, "Study on architecture enhancements for EPS and 5G System to support advanced V2X services"; TS 23.303 V15.1.0, "Proximity-based services (ProSe); Stage 2"; TR 22.886 V15.0.0, "Study on enhancement of 3GPP Support for 5G V2X Services"; R2-1812975, "Ls on Prioritised Use Cases and Requirements for consideration in Rel-16 NR-V2X"; R2-1815440, "Basic Scenarios and Overal Steps for NR Sidelink design", LG Electronics Inc.; TS 24.334 V15.2.0, "User Equipment (UE) to V2X control function; protocol aspects; Stage 3"; y TS 33.303 V15.0.0, "Proximity-based services (ProSe); Security aspects". Los estándares y documentos enumerados anteriormente se incorporan expresamente en el presente documento por referencia en su totalidad.
La FIG. 1 muestra un sistema de comunicación inalámbrica de acceso múltiple de acuerdo con un modo de realización de la invención. Una red de acceso 100 (AN) incluye grupos de múltiples antenas, uno que incluye la 104 y la 106, otro que incluye la 108 y la 110, y uno adicional que incluye la 112 y la 114. En la FIG. 1 solo se muestran dos antenas para cada grupo de antenas; sin embargo, se puede utilizar un número mayor o menor de antenas para cada grupo de antenas. El terminal de acceso (AT) 116 se comunica con las antenas 112 y 114, donde las antenas 112 y 114 transmiten información al terminal de acceso 116 a través del enlace directo 120 y reciben información desde el terminal de acceso 116 a través del enlace inverso 118. El terminal de acceso (AT) 122 se comunica con las antenas 106 y 108, donde las antenas 106 y 108 transmiten información al terminal de acceso (AT) 122 a través del enlace directo 126 y reciben información desde el terminal de acceso (AT) 122 a través del enlace inverso 124. En un sistema de f Dd , unos enlaces de comunicación 118, 120, 124 y 126 pueden usar diferentes frecuencias para la comunicación. Por ejemplo, un enlace directo 120 puede usar una frecuencia diferente a la usada por un enlace inverso 118.
Cada grupo de antenas, y/o el área en la que están destinadas a comunicarse, se denomina a menudo sector de la red de acceso. En el modo de realización, cada grupo de antenas está diseñado para comunicarse con terminales de acceso en un sector de las áreas cubiertas por la red de acceso 100.
En la comunicación a través de los enlaces directos 120 y 126, las antenas transmisoras de la red de acceso 100 pueden utilizar conformación de haz para mejorar la relación entre señal y ruido de los enlaces directos para los diferentes terminales de acceso 116 y 122. Asimismo, una red de acceso que usa conformación de haz para transmitir a unos terminales de acceso dispersados aleatoriamente por toda su cobertura causa menos interferencia a los terminales de acceso de las células contiguas que una red de acceso que transmite a través de una única antena a todos sus terminales de acceso.
Una red de acceso (AN) puede ser una estación fija o una estación base utilizada para comunicarse con los terminales y también puede denominarse como punto de acceso, nodo B, estación base, estación base mejorada, nodo B evolucionado (eNB) o recibir alguna otra denominación. Un terminal de acceso (AT) también puede denominarse equipo de usuario (UE), dispositivo de comunicación inalámbrica, terminal, terminal de acceso o recibir alguna otra denominación.
La FIG. 2 es un diagrama de bloques simplificado de un modo de realización de un sistema transmisor 210 (también conocido como la red de acceso) y un sistema receptor 250 (también conocido como terminal de acceso (AT) o equipo de usuario (UE)) en un sistema MIMO 200. En el sistema transmisor 210 se proporcionan datos de tráfico para un número de flujos de datos desde una fuente de datos 212 a un procesador de datos de transmisión (TX) 214.
Preferentemente, cada flujo de datos se transmite a través de una antena transmisora respectiva. El procesador de datos de TX 214 da formato, codifica e intercala los datos de tráfico para cada flujo de datos en base a un esquema de codificación particular seleccionado para que ese flujo de datos proporcione datos codificados. Los datos codificados para cada flujo de datos se pueden multiplexar con datos piloto usando técnicas de OFDM. Los datos piloto son típicamente un patrón de datos conocido que se procesa de una manera conocida y que se puede usar en el sistema receptor para estimar la respuesta de canal. Los datos piloto multiplexados y codificados para cada flujo de datos se modulan entonces (es decir, se correlacionan con símbolos) basándose en un sistema de modulación particular (por ejemplo, BPSK, QPSK, M-PSK o M-QAM) seleccionado para ese flujo de datos para proporcionar símbolos de modulación. La velocidad de transferencia de datos, la codificación y la modulación para cada flujo de datos se pueden determinar mediante instrucciones realizadas por el procesador 230.
Los símbolos de modulación para todos los flujos de datos se proporcionan a continuación a un procesador MIMO de TX 220, que puede procesar adicionalmente los símbolos de modulación (por ejemplo, para OFDM). El procesador MIMO de TX 220 proporciona a continuación Nt flujos de símbolos de modulación a Nt transmisores (TMTR) 222a a 222t. En determinados modos de realización, el procesador de MIMO de TX 220 aplica ponderaciones de conformación de haz a los símbolos de los flujos de datos y a la antena desde la cual se está transmitiendo el símbolo.
Cada transmisor 222 recibe y procesa un respectivo flujo de símbolos para proporcionar una o más señales analógicas, y acondiciona más (por ejemplo, amplifica, filtra y eleva en frecuencia) las señales analógicas para proporcionar una señal modulada adecuada para su transmisión a través del canal de MIMO. Nt señales moduladas desde los transmisores 222a a 222t se transmiten a continuación desde Nt antenas 224a a 224t, respectivamente.
En el sistema receptor 250, las señales moduladas transmitidas se reciben por Nr antenas 252a a 252r, y la señal recibida desde cada antena 252 se proporciona a un receptor (RCVR) respectivo 254a a 254r. Cada receptor 254 acondiciona (por ejemplo, filtra, amplifica y reduce en frecuencia) una señal recibida respectiva, digitaliza la señal acondicionada para proporcionar muestras y procesa más las muestras para proporcionar un flujo de símbolos "recibido" correspondiente.
Un procesador de datos de RX 260 recibe y procesa a continuación los Nr flujos de símbolos recibidos desde Nr receptores 254 en base a una técnica particular de procesamiento de receptor para proporcionar Nt flujos de símbolos "detectados". A continuación, el procesador de datos de RX 260 desmodula, desintercala y descodifica cada flujo de símbolos detectado para recuperar los datos de tráfico para el flujo de datos. El procesamiento por el procesador de datos de RX 260 es complementario al realizado por el procesador de MIMO de TX 220 y el procesador de datos de TX214 en el sistema transmisor 210.
Un procesador 270 determina periódicamente qué matriz de precodificación va a usar (analizado más adelante). El procesador 270 formula un mensaje de enlace inverso que comprende una parte de índice de matriz y una parte de valor de rango.
El mensaje de enlace inverso puede comprender diversos tipos de información con respecto al enlace de comunicación y/o al flujo de datos recibido. A continuación, el mensaje de enlace inverso se procesa por un procesador de datos de TX 238, que también recibe datos de tráfico para un número de flujos de datos desde una fuente de datos 236, se modula por un modulador 280, se acondiciona por los transmisores 254a a 254r y se transmite de vuelta al sistema transmisor 210.
En el sistema transmisor 210, las señales moduladas del sistema receptor 250 se reciben mediante las antenas 224, se acondicionan mediante los receptores 222, se desmodulan mediante un desmodulador 240 y se procesan mediante un procesador de datos de RX 242 para extraer el mensaje de enlace inverso transmitido por el sistema receptor 250. A continuación, el procesador 230 determina qué matriz de precodificación va a usar para determinar las ponderaciones de conformación de haz y después procesa el mensaje extraído.
Volviendo a la FIG. 3, esta FIG. muestra un diagrama de bloques funcional simplificado alternativo de un dispositivo de comunicación de acuerdo con un modo de realización de la invención. Como se muestra en la FIG. 3, el dispositivo de comunicación 300 en un sistema de comunicación inalámbrica se puede utilizar para realizar los UE (o At ) 116 y 122 de la FIG. 1 o la estación base (o AN) 100 de la FIG. 1, y el sistema de comunicación inalámbrica 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 central de procesamiento (CPU) 308, una memoria 310, un código de programa 312 y un transceptor 314. El circuito de control 306 ejecuta el código de programa 312 en la memoria 310 a través de la CPU 308, controlando así una operación del dispositivo de comunicaciones 300. El dispositivo de comunicaciones 300 puede recibir señales introducidas por un usuario a través del dispositivo de entrada 302, como un teclado o un teclado numérico, y puede emitir imágenes y sonidos a través del dispositivo de salida 304, tal como un monitor o altavoces. El transceptor 314 se utiliza para recibir y transmitir señales inalámbricas, suministrando las señales recibidas al circuito de control 306 y emitiendo las señales generadas por el circuito de control 306 de forma inalámbrica. El dispositivo de comunicación 300 en un sistema de comunicación inalámbrica también se puede utilizar para realizar el AN 100 de la FIG. 1.
La FIG. 4 es un diagrama de bloques simplificado del código de programa 312 que se muestra en la FIG. 3 de acuerdo con un modo de realización de la invención. En este modo de realización, el código de programa 312 incluye una capa de aplicación 400, una porción de capa 3402 y una porción de capa 2404, y está acoplado a una porción de capa 1406. La porción de capa 3402 en general realiza el control de recursos de radio. La porción de capa 2404 en general realiza el control de enlace. La porción de capa 1406 en general realiza conexiones físicas.
La sección 5.4.4.23 del 3GPP TS 23.303 establece:
5.4.5.2 Establecimiento de un enlace de capa 2 seguro a través de PC5
En la figura 5.4.5.2-1 se representa el procedimiento para el establecimiento de un enlace de capa 2 seguro a través de PC5.
Los UE que participan en una comunicación aislada (sin retransmisor) unívoca negocian los mecanismos de asignación de direcciones IP y, opcionalmente, intercambian direcciones IPv6 locales de enlace si es necesario durante el procedimiento de establecimiento de enlace.
[La figura 5.4.5.2-1 del 3GPP TS 23.303 V15.1.0, titulada "Establecimiento de enlace de capa 2 seguro a través de PC5" se reproduce como la FIG. 5]
1. El UE-1 envía un mensaje Petición de Comunicación Directa al UE-2 para desencadenar la autenticación mutua. Este mensaje incluye la información del usuario. Si el enlace está configurado para la comunicación unívoca aislada (ninguno de los UE es un retransmisor), el UE-1 indicará en el mensaje si puede actuar como servidor DHCPv4, enrutador IPv6 o ambos. Si el UE-1 no admite ninguno de los mecanismos de asignación de direcciones IP, incluirá una dirección IPv6 local de enlace en el mensaje. NOTA 1: El iniciador de enlace (UE-1) necesita conocer el ID de capa 2 de la entidad par (UE-2) para realizar la etapa 1. Como ejemplo, el iniciador del enlace puede aprender el ID de capa 2 de la entidad par al ejecutar primero un procedimiento de detección o al haber participado en una comunicación directa ProSe de uno a varios, incluida la entidad par.
2. El UE-2 inicia el procedimiento de autenticación mutua. La finalización satisfactoria del procedimiento de autenticación completa el establecimiento del enlace de capa 2 seguro a través de PC5. Como parte de esta etapa, el UE-2 incluye la información del usuario en una respuesta al UE-1. Si el enlace está configurado para la comunicación unívoca aislada (ninguno de los UE es un retransmisor), el UE-2 indicará al UE-1 en el mensaje de respuesta si puede actuar como servidor DHCPv4, enrutador IPv6 o ambos. Si el UE-2 no admite ninguno de los mecanismos de asignación de direcciones IP y el UE-1 ha incluido una dirección IPv6 local de enlace en la etapa 1, el UE-2 incluirá una dirección IPv6 local de enlace sin conflicto en el mensaje de respuesta. Si tanto el UE-1 como el UE-2 han seleccionado utilizar la dirección IPv6 local de enlace, deberán deshabilitar la detección de direcciones duplicadas definida en RFC 4862 [6]. NOTA 2: Cuando el UE-1 o el UE-2 indican el soporte del enrutador DHCPv4 o IPv6, el procedimiento de configuración de la dirección correspondiente se llevará a cabo después del establecimiento del enlace de capa 2, y se ignorarán las direcciones IPv6 del enlace local. NOTA 3: Para utilizar direcciones IPv6 de enlace local, las aplicaciones que utilizan comunicación directa aislada unívoca ProSe utilizan identificadores de capa de aplicación que son compatibles con DNS de multidifusión como se especifica en RFC 6762 [34]. Para aprovechar el mDNS, la capa superior debe conocer el uso de la dirección de enlace local sobre el enlace L2, ya que el FQDN utilizado será diferente.
El 3GPP TR 23.786 establece:
6.11 Solución núm. 11: Solución de unidifusión o multidifusión para la comunicación eV2X sobre el punto de referencia PC5
6.11.1 Descripción funcional
Esta solución aborda el problema clave núm. 1 sobre la admisión de la comunicación grupal eV2X, el problema clave núm. 9 sobre el soporte de la comunicación de unidifusión/multidifusión a través de PC5 y el problema clave núm. 4 sobre la admisión de la mejora sobre el marco de QoS de PC5 para eV2X, centrándose en los aspectos siguientes:
- Identificadores para la comunicación de unidifusión, p. ej. ID L2;
- Protocolo de señalización para admitir la comunicación de unidifusión/multidifusión;
- Soporte de QoS y configuraciones de capa AS;
- Asociaciones de seguridad;
- Procedimientos para el establecimiento y mantenimiento de enlaces.
6.11.2 Descripción de la solución
6.11.2.2 Protocolo de señalización para admitir la comunicación de unidifusión/multidifusión
Para la comunicación de unidifusión o multidifusión, existe la necesidad de que se intercambie algún mensaje de control entre los UE implicados para establecer el enlace o grupo. Por lo tanto, se requiere algún protocolo de señalización.
En la comunicación unívoca ProSe definida en TS 23.303 [8], se introdujo un protocolo de señalización PC5 (cláusula 5.1.1.5.2), que se ejecuta sobre la capa PDCP. Aunque está definido para el uso de ProSe, los mensajes podrían extenderse para ser utilizados en la comunicación v 2x . El diseño detallado del protocolo debe revisarse en base a los procedimientos de operación de unidifusión reales.
Otro enfoque alternativo es ejecutar RRC a través de PC5. Como el protocolo de señalización PC5 se usa en cualquier caso a través de PDCP, el protocolo RRC se puede usar para sustituirlo. Aunque no todas las características de RRC son necesarias para el funcionamiento de PC5, los mensajes de RRC pertinentes de V2X seleccionados se pueden extender y usar, por ejemplo, InformaciónUEEnlacelateral, etc. La ventaja de ello es la unificación potencial de los protocolos de señalización de control para Uu y PC5.
Por tanto, en esta solución se introduce un protocolo de señalización a través de PC5 para la gestión de comunicaciones de unidifusión/multidifusión.
6.11.2.2 Asociaciones de seguridad
La comunicación de unidifusión o multidifusión también puede necesitar protección en la capa de enlace. La comunicación unívoca ProSe admite el establecimiento de un enlace L2 seguro, como se define en TS 33.303 [11]. Sin embargo, dentro del contexto de la comunicación V2X, cada UE tiene los certificados correspondientes para la protección de seguridad. Por lo tanto, puede ser necesario mejorar o ajustar el protocolo de establecimiento de enlace seguro L2 existente para admitir el uso de dichas asociaciones de seguridad.
El manejo exacto de seguridad se debe analizar y decidir por SA3. El diseño de SA2 debe alinearse con esas decisiones cuando estén disponibles.
6.11.2.5 Procedimientos para el establecimiento y mantenimiento de enlaces
TS 23.303 [8] ha definido los procedimientos para el establecimiento y mantenimiento de un enlace L2 seguro a través de PC5, como en la cláusula 5.4.5. Estos procedimientos se pueden mejorar y adaptar para el uso de V2X, sujeto a las decisiones anteriores con respecto a la elección del protocolo de señalización, manejo de seguridad, etc. Sin embargo, se requieren algunas consideraciones adicionales para el V2X en cuanto al manejo de enlace/grupo. En la comunicación V2X, no todos los UE prestarán soporte a o utilizarán la comunicación de unidifusión. Además, es posible que no todos los servicios se ejecuten en el mismo canal o RAT (por ejemplo, V2X LTE V2X frente a V2X NR). Con V2X, no hay un canal de detección como el de ProSe (es decir, PC5-D), y no se supone que la configuración de la red sea para uso de seguridad pública. Por lo tanto, para admitir el establecimiento del enlace, existe la necesidad de un anuncio de servicio para informar a la entidad par de la existencia del UE y la capacidad del UE para la comunicación de unidifusión, por ejemplo, el canal a operar, o los servicios admitidos, etc.
Dicho anuncio de servicio debería hacerse accesible a todos los UE que estén interesados en utilizar el servicio. Por ejemplo, dicho anuncio podría configurarse para enviarse a través de un canal dedicado, de manera similar a cómo se maneja el anuncio de servicio WAVE (WSA), o agregado en los mensajes periódicos desde los UE admitidos. NOTA 1: El anuncio de servicio se maneja en la capa superior y está fuera del alcance de SA2.
Para el mantenimiento del enlace de la capa 2, se necesita la funcionalidad de mantener activo para detectar eso cuando los UE no están en el alcance de comunicación directa, de modo que puedan continuar con la liberación implícita del enlace de la capa 2. NOTA 2: Se deja a la Etapa 3 el determinar cómo se admite la funcionalidad de mantener activo.
6.11.3 Procedimientos
6.11.3.1 Establecimiento de enlace de capa 2 a través de PC5
El procedimiento de establecimiento de enlace de capa 2 definido en TS 23.303 [8] cláusula 5.4.5.2 puede reutilizarse para el establecimiento de enlace de unidifusión eV2X con las siguientes adaptaciones:
- Los mensajes pueden convertirse en un mensaje de señalización RRC en lugar de un mensaje de señalización PC5, depende de la decisión de RAN WG.
- El "establecimiento de enlace de capa 2 orientado al UE" funciona como se indica a continuación y la figura 6.11.3.1-1 muestra el procedimiento:
- El mensaje Petición de Comunicación Directa puede ser enviado por el UE-1 con mecanismo de radiodifusión, es decir, a una dirección de radiodifusión asociada con la aplicación en lugar del ID L2 del UE-2. El identificador superior del UE-2 se incluye en el mensaje Petición de Comunicación Directa para permitir que el UE-2 decida si responde a la petición. El ID L2 de origen de este mensaje debe ser el ID L2 de unidifusión del UE-1.
- El mensaje Petición de Comunicación Directa se debe transmitir utilizando el establecimiento de capa AS por defecto, por ejemplo, el establecimiento de radiodifusión, que puede entender el UE-2.
- El UE-2 usa el ID L2 de origen del mensaje Petición de Comunicación Directa recibido como ID L2 de destino en la señalización posterior al UE-1, y usa su propio ID L2 de unidifusión como el ID L2 de origen. El UE-1 obtiene el ID L2 del UE-2 para las comunicaciones futuras, para la señalización y el tráfico de datos.
[La figura 6.11.3.1-1 del 3GPP TR 23.786 V1.0.0, titulada "Procedimiento de establecimiento de enlace de capa 2 orientado al UE" se reproduce como la FIG. 6]
- El "establecimiento de enlace de capa 2 orientado al servicio V2X" funciona igual que el "establecimiento de enlace de capa 2 orientado al UE" con las siguientes diferencias y la figura 6.11.3.1-2 muestra el procedimiento: - La información sobre el servicio V2X que solicita el establecimiento del enlace L2, es decir, la información sobre el servicio V2X anunciado se incluye en el mensaje Petición de Comunicación Directa para permitir que otros UE decidan si responden a la petición.
- Los UE que estén interesados en utilizar el servicio V2X anunciado por el mensaje Petición de Comunicación Directa pueden responder a la petición (el UE-2 y el UE-4 en la figura 6.11.3.1-2).
- Después de establecer el enlace de capa 2 con otros UE(s) como se describe anteriormente, los nuevos UE pueden entrar en proximidad con el UE-1, es decir, el alcance de comunicación directa del UE-1. En este caso, el UE-1 puede iniciar el procedimiento de establecimiento de enlace de la capa 2 orientado al servicio V2X, ya que conoce el (los) nuevo(s) UE a partir de los mensajes de la capa de aplicación enviados por el (los) UE. O el nuevo UE puede iniciar el procedimiento de establecimiento de enlace de capa 2 orientado al servicio V2X. Por lo tanto, el UE-1 no tiene que seguir enviando un mensaje Petición de Comunicación Directa periódicamente para anunciar el servicio V2X que desea para establecer un enlace L2 con otro UE de unidifusión.
[La figura 6.11.3.1-2 del 3GPP TR 23.786 V1.0.0, titulada "Procedimiento de establecimiento de enlace de capa 2 orientado al servicio V2X" se reproduce como la FIG. 7]
El enlace de capa 2 admite el tráfico que no es IP. No se llevará a cabo ningún procedimiento de negociación y asignación de direcciones IP.
Contenido 6.11.3.2 del mensaje de señalización para el establecimiento de enlace
La información transportada en el mensaje Petición de Comunicación Directa que se define en TS 24.334 [13] requiere al menos las siguientes actualizaciones:
- Para el "establecimiento de enlace de capa 2 orientado al UE",
- La información del usuario debe incluir el ID del UE de destino (ID de la capa superior del UE-2), además del ID del UE iniciador (ID de la capa superior del UE-1). NOTA: La etapa 3 puede decidir si estos ID se pueden transportar en el mismo IE o en IE separados, por ejemplo, el ID de estación/ID de temperatura del vehículo solo necesita ser de 4 octetos.
- Para el "establecimiento de enlace de capa 2 orientado al servicio V2X",
- La información anunciada del servicio V2X debe incluir la información sobre el servicio V2X que solicita el establecimiento del enlace L2, por ejemplo, PSID o ITS-AID de la aplicación V2X. La compartición de sensores, etc., puede ser el caso del servicio V2X.
- La configuración de la dirección IP, que se especifica como obligatoria para ProSe, debe permitir una indicación de que no se utilizará ninguna IP, de modo que el UE receptor (por ejemplo, el UE-2) no iniciará ningún procedimiento de configuración de IP para este enlace en particular.
- Los IE dedicados a la seguridad se deben revisar mediante SA3, ya que el mecanismo de seguridad para eV2X puede ser diferente y requiere diferentes IE.
- Información de configuración adicional con respecto al enlace, por ejemplo, cuando se utiliza un mensaje de RRC, puede haber configuraciones de capa AS.
6.11.3.4 Aspectos de seguridad para el enlace de capa 2
Como las aplicaciones eV2X tienen certificados de seguridad asociados, el enlace de unidifusión puede reutilizarlos para derivar la asociación de seguridad para proteger la señalización o los datos del enlace de unidifusión.
3GPP TS 24.334 establece:
10.4.2 Procedimiento de configuración del enlace directo
10.4.2.1 General
El procedimiento de configuración del enlace directo se utiliza para establecer un enlace directo seguro entre dos UE habilitados para ProSe. El UE que envía el mensaje de petición se denomina "UE iniciador" y el otro UE se denomina "UE de destino".
Si la configuración del enlace directo es para la comunicación directa aislada unívoca ProSe, es decir, cuando ninguno de los dos UE es un retransmisor ProSe del UE a la red, ambos UE deben haber obtenido por adelantado la clave pública del KMS (servidor de gestión de claves) y un conjunto de credenciales asociadas con la identidad del UE (como se define en el IETF RFC 6507 [39] y el iEt F Rf C 6508 [40]), como se especifica en el 3GPP TS 33.303 [6].
10.4.2.2 Iniciación del procedimiento de configuración del enlace directo mediante el UE iniciador
El UE iniciador deberá cumplir las siguientes condiciones previas antes de iniciar este procedimiento:
- se recibe una petición de las capas superiores para establecer un enlace directo con el UE de destino y no existe ningún enlace entre el UE iniciador y ese UE de destino;
- el identificador de la capa de enlace para el UE iniciador (es decir, el ID de la capa 2 utilizado para la comunicación de unidifusión) está disponible (por ejemplo, preconfigurado o autoasignado);
- el identificador de la capa de enlace para el UE de destino (es decir, el ID de la capa 2 utilizado para la comunicación de unidifusión) está disponible para el UE iniciador (p. ej., preconfigurado u obtenido mediante detección directa ProSe); y
- el UE iniciador está autorizado para la comunicación directa ProSe en la PLMN de servicio, o tiene una autorización válida para la comunicación directa ProSe cuando no está servido por E-UTRAN.
El UE iniciador inicia el procedimiento de establecimiento del enlace directo generando un mensaje PETICIÓN_COMUNICACIÓN_DIRECTA con:
- la Información de usuario establecida en:
- la Información de usuario del UE iniciador recibida desde las capas superiores si el UE de destino no es un UE ProSe retransmisor del UE a la red;
- el ID PRUK recibido desde el PKMF si el UE de destino es un UE ProSe retransmisor del UE a la red, el UE iniciador ha recibido una PRUK desde el PKMF para este retransmisor, y un intento de conectarse a este retransmisor no ha sido rechazado a causa de no se reconoce el ID PRUK;
- el IMSI del UE iniciador si el UE de destino es un UE ProSe retransmisor del UE a la red y el UE iniciador no ha recibido un PRUK desde el PKMF para este retransmisor; o
- el IMSI del UE iniciador si el UE de destino es un UE ProSe retransmisor del UE a la red y el UE iniciador ha recibido un PRUK desde el PKMF para este retransmisor, pero se ha rechazado un intento de conectarse a este retransmisor a causa de que el ID PRUK no se reconoce;
- un IE Configuración de la dirección IP establecido en uno de los siguientes valores:
- "Servidor DHCPv4" si el UE iniciador solo admite el mecanismo de asignación de direcciones IPv4, es decir, que actúa como un servidor DHCPv4;
- "Enrutador IPv6" si el UE iniciador solo admite el mecanismo de asignación de la dirección IPv6, es decir, que actúa como un Enrutador IPv6;
- "Servidor DHCPv4 y enrutador IPv6" si el UE iniciador admite los mecanismos de asignación de direcciones IPv4 e IPv6; o
- "no se admite la asignación de direcciones" si el UE iniciador no admite ni el mecanismo de asignación de la dirección IPv4 ni el mecanismo de asignación de la dirección IPv6;
- un IE Dirección IPv6 de enlace local formado localmente en base al IETF RFC 4862 [15] si el IE Configuración de la dirección IP se establece en "no se admite la asignación de direcciones" y el enlace está configurado para la comunicación aislada unívoca; NOTA1: el UE puede reutilizar una dirección IP IPv6 de enlace local para múltiples enlaces de comunicación unívoca aislados.
- un IE Período de inactividad máximo para indicar el período de inactividad máximo del UE solicitante a través de este enlace directo; NOTA 2: el valor del IE Período de inactividad máximo se puede calcular en base a los ajustes locales del UE, como el temporizador de mantener activo T4102 (véase 10.4.3), el temporizador de retransmisión T4101 (véase 10.4.3) y el número máximo de retransmisiones permitidas para el mensaje COMUNICACIÓN_DIRECTA_MANTENERACTIVO.
- un IE Nonce_1 establecido en el valor nonce de 128 bits generado por el UE iniciador con el propósito de establecer la clave de la sesión a través de este enlace directo;
- un IE Capacidades de seguridad del UE establecido para indicar la lista de algoritmos que el UE iniciador admite para el establecimiento de seguridad de este enlace directo;
- un IE MSB ID del Kü-sess establecido en los 8 bits más significativos del ID Ko-sess; y
- Opcionalmente, un IE ID Kd se establece en el ID conocido de Kd que se ha establecido previamente si el UE iniciador tiene un Kd existente con el UE de destino.
Si la configuración del enlace directo es para la comunicación directa aislada unívoca ProSe, el mensaje PETICIÓN_COMUNICACIÓN_DIRECTA también incluirá los siguientes parámetros:
- el IE Firma se establece en la firma ECCSI calculada con los siguientes elementos de información, como se especifica en el 3GPP TS 33.303 [6]:
- Información de usuario; y
- Nonce_1.
Si no, si la configuración del enlace para el UE remoto en la comunicación ProSe directa del retransmisor Prose del UE a la red, el mensaje PETICIÓN_COMUNICACIÓN_DIRECTA también incluirá el IE Código de servicio de retransmisor establecido en el código de servicio de retransmisor del retransmisor de destino.
Después de que se genera el mensaje PETICIÓN_COMUNICACIÓN_DIRECTA, el UE iniciador pasará este mensaje a las capas inferiores para su transmisión junto con el ID de la capa 2 del UE iniciador (para la comunicación de unidifusión) y el ID de la capa 2 del UE de destino (para la comunicación de unidifusión), y comenzará el temporizador T4100. El UE no enviará un nuevo mensaje PeTICIÓN_COMUNICACIÓN_DIRECt A al mismo UE de destino mientras el temporizador T4100 esté en funcionamiento.
[La figura 10.4.2.2.1 del 3GPP TR 24.334 V15.2.0, titulada "Procedimiento de configuración del enlace directo" se reproduce como la FIG. 8]
10.4.2.3 Procedimiento de configuración del enlace directo aceptado por el UE de destino
Al recibir un mensaje PETICIÓN_COMUNICACIÓN_DIRECTA, el UE de destino almacenará el par de los ID de capa 2 (para la comunicación de unidifusión) utilizados en el transporte de este mensaje proporcionado por las capas inferiores y los asociará con un contexto de enlace directo.
El UE de destino luego verifica el IE Información de usuario incluido en el mensaje PETICIÓN_COMUNICACIÓN_DIRECTA y determina si esta petición se puede aceptar o no. Luego, el UE de destino examina el IE Configuración de la dirección IP para ver si hay al menos una opción de configuración de la dirección IP común admitida tanto por el UE iniciador como por el UE de destino. Si la verificación anterior es satisfactoria, el UE de destino invocará el procedimiento de control del modo de seguridad directo como se especifica en la subcláusula 10.4.5 para establecer una asociación de seguridad entre el UE de destino y el UE iniciador. Solo después de la finalización del procedimiento de autenticación del enlace y un establecimiento satisfactorio de la asociación de seguridad, el UE de destino enviará un mensaje ACEPTAR_COMUNICACIÓN_DIRECTA al UE iniciador.
El UE de destino incluirá un IE Configuración de la dirección IP establecido en uno de los siguientes valores: - "Servidor DHCPv4" si el UE de destino solo admite el mecanismo de asignación de direcciones IPv4 y el UE de destino puede actuar como servidor DHCP;
- "Enrutador IPv6" si el UE de destino solo admite el mecanismo de asignación de direcciones IPv4 y el UE de destino puede actuar como enrutador IPv6;
- "Servidor DHCPv4 y enrutador IPv6" si el UE de destino admite los mecanismos de asignación de direcciones IPv4 e IPv6; o
- "no se admite la asignación de direcciones" si el UE de destino no admite ni la asignación de la dirección IPv4 ni la asignación de la dirección IPv6;
Si el IE Configuración de la dirección IP se establece en "no se admite la asignación de direcciones" y el mensaje PETICIÓN_COMUNICACIÓN_DIRECTA recibido incluía un IE Dirección IPv6 de enlace local, el u E de destino incluirá un IE Dirección IPv6 de enlace local establecido en la dirección IPv6 de enlace local formada localmente. NOTA: el UE puede reutilizar una dirección IP IPv6 de enlace local para múltiples enlaces de comunicación unívoca aislados.
Un UE ProSe retransmisor del UE a la red deberá admitir al menos uno de los mecanismos de asignación de direcciones IP.
Si el UE de destino actúa como un UE ProSe retransmisor del UE a la red y la conexión PDN para la retransmisión asociada con el ID UE ProSe retransmisor no se ha establecido todavía o se necesita una conexión PDN adicional utilizada para la retransmisión cuando el UE ProSe retransmisor del UE a la red envía el mensaje ACEPTAR_COMUNICACIÓN_DIRECTA al UE remoto, el UE ProSe retransmisor del UE a la red iniciará el procedimiento de conectividad PDN solicitado por el UE enviando el mensaje PETICIÓN CONECTIVIDAD PDN que incluye el APN que está asociado con el ID UE ProSe retransmisor como se especifica en el 3GPP TS 24.301 [11].
Si el UE de destino es un UE ProSe retransmisor del UE a la red, el UE de destino creará un temporizador de inactividad T4108 con el valor proporcionado en el IE Período de inactividad máximo incluido en el mensaje PETICIÓN_COMUNICACIÓN_DIRECTA, y pondrá en marcha el temporizador T4108 cuando haya no más mensajes para enviar sobre el enlace que se va a establecer. Una vez que se inicia el temporizador T4108, si se produce alguna actividad de comunicación antes de que se agote el temporizador T4108, el UE detendrá el temporizador T4108 y lo restablecerá con el valor inicial, a menos que se proporcione un nuevo valor en un IE Período de inactividad máximo en un mensaje COMUNICACIÓN_DiRe CTA_m An TENERACTIVO.
Si el UE de destino es un UE ProSe retransmisor del UE a la red, y la PLMN de servicio lo ha configurado para informar el IMEI o IMEISV de los UE remotos servidos por el retransmisor en base al procedimiento de autorización de servicio especificado en la cláusula 5, el UE ProSe retransmisor del UE a la red iniciará un procedimiento de petición de información de UE remoto (como se especifica en la subcláusula 10.7.2) para solicitar el IMEI o IMEISV del UE remoto tras el establecimiento satisfactorio del enlace directo.
10.4.2.4 Finalización del procedimiento de configuración del enlace directo por parte del UE iniciador
Al recibir el mensaje ACEPTAR_COMUNICACIÓN_DIRECTA, el UE iniciador detendrá el temporizador T4100. A partir de este momento, el UE iniciador utilizará el enlace establecido para todas las comunicaciones unívocas (que incluyen los mensajes de señalización PC5 adicionales) al UE de destino.
10.4.6 Configuración de la dirección IP
10.4.6.1 General
El procedimiento de configuración de la dirección IP se realiza después del establecimiento del enlace directo para permitir la conectividad IP entre los UE en cada extremo del enlace directo.
Cuando se completa el procedimiento de configuración de la dirección IP para un UE remoto, el UE ProSe retransmisor del UE a la red realizará el procedimiento de informe de UE remoto como se especifica en el 3GPP TS 24.301 [11].
10.4.6.2 Selección de la versión de IP
Cuando ninguno de los dos UE en el enlace directo actúa como un retransmisor ProSe del UE a la red, los dos UE seleccionarán la versión de IP (IPv4 o IPv6) que se utilizará en base a las siguientes reglas:
- Si el UE de destino en el procedimiento de establecimiento del enlace directo (véase la subcláusula 10.4.2) ha indicado "Servidor DHCPv4" en el IE Configuración de la dirección IP, entonces el UE iniciador en el procedimiento de establecimiento del enlace directo (véase la subcláusula 10.4.2) iniciará la configuración de la dirección IPv4 con el procedimiento DHCPv4 que actúa como un cliente DHCP;
- si el UE de destino en el procedimiento de configuración del enlace directo ha indicado "Enrutador IPv6" en el IE Configuración de la dirección IP, entonces el UE iniciador en el procedimiento de configuración del enlace directo iniciará la configuración de la dirección IPv6 con la configuración automática de la dirección IPv6 sin estado que actúa como un proveedor de alojamiento IPv6;
- si el UE de destino en el procedimiento de configuración del enlace directo ha indicado "Servidor DHCPv4 y enrutador IPv6" en el IE Configuración de la dirección IP, entonces el UE iniciador en el procedimiento de configuración del enlace directo elegirá la versión de IP e iniciará el procedimiento de configuración de la dirección, que actúa como un cliente o proveedor de alojamiento;
- si el UE de destino en el procedimiento de configuración del enlace directo ha indicado "no se admite la asignación de direcciones" en el IE Configuración de la dirección IP y el UE iniciador ha indicado "Servidor DHCPv4", "Enrutador IPv6" o "Servidor DHCPv4 y enrutador IPv6" en el IE Configuración de la dirección IP, entonces el UE de destino deberá:
a) iniciar la configuración de la dirección IPv4 con el procedimiento DHCPv4 que actúa como un cliente DHCP, si el UE iniciador ha indicado "Servidor DHCPv4";
b) iniciar la configuración de la dirección IPv6 con la configuración automática de la dirección IPv6 sin estado que actúa como un proveedor de alojamiento IPv6 si el UE iniciador ha indicado "Enrutador IPv6"; y
c) elegir la versión de IP e iniciar el procedimiento de configuración de la dirección IP correspondiente como cliente o proveedor de alojamiento, si el otro UE ha indicado "Servidor DHCPv4 y enrutador IPv6"; y
- si ambos UE han indicado "no se admite la asignación de direcciones" en el IE Configuración de la dirección IP, entonces los UE utilizarán direcciones de enlace local IPv6 formadas localmente como se define en RFC 4862 [15].
Cuando uno de los dos UE en el enlace directo actúa como un retransmisor ProSe del UE a la red, los dos UE seleccionarán la versión de IP (IPv4 o IPv6) que se utilizará en base a las siguientes reglas:
- si el UE ProSe retransmisor del UE a la red ha indicado "Servidor DHCPv4" en el IE Configuración de la dirección IP, el UE remoto iniciará la configuración de la dirección IPv4 con el procedimiento DHCPv4 que actúa como un cliente DHCP;
- si el UE ProSe retransmisor del UE a la red ha indicado "Enrutador IPv6" en el IE Configuración de la dirección IP, el UE remoto iniciará la configuración de la dirección IPv6 con la configuración automática de la dirección IPv6 sin estado que actúa como un proveedor de alojamiento IPv6; y
- si el UE ProSe retransmisor del UE a la red ha indicado "Servidor DHCPv4 y enrutador IPv6" en el IE Configuración de la dirección IP, el UE remoto elegirá la versión de IP e iniciará el procedimiento de configuración de la dirección IP correspondiente como cliente o proveedor de alojamiento. Especialmente, si el UE remoto tiene la intención de utilizar el UE ProSe retransmisor del UE a la red para la comunicación de misión crítica (por ejemplo, MCPTT), el UE remoto iniciará la configuración automática de la dirección IPv6 sin estado que actúa como un proveedor de alojamiento IPv6.
10.4.6.3 Configuración de la dirección IPv4 con DHCPv4
La configuración de la dirección IPv4 con DHCPv4 se llevará a cabo de la siguiente manera:
1. El cliente DHCP envía un mensaje DHCPDISCOVER;
2. El servidor DHCP envía el mensaje DHCPOFFER con la dirección IPv4 asignada al cliente. La dirección IPv4 proporcionada corresponderá a un alcance de la dirección IPv4 local configurado en el servidor DHCP;
3. Cuando el cliente DHCP recibe la oferta de concesión, envía un mensaje DHCPREQUEST que contiene la dirección IPv4 recibida.
4. El servidor DHCP envía un mensaje DHCPACK al UE cliente. Este mensaje incluye la duración de la concesión y cualquier otra información de configuración que el cliente pueda haber solicitado.
5. Al recibir el mensaje DHCPACK, se completa la configuración de la dirección IPv4.
NOTA: El cliente DHCPv4 puede omitir la fase de detección de DHCPv4 y enviar un mensaje de petición de DHCPv4 en radiodifusión como el primer mensaje de acuerdo con el proceso de renovación de DHCPv4.
Si el enlace directo está configurado para la comunicación unívoca entre un UE remoto y un UE retransmisor del UE a la red, después de que el UE remoto libera la dirección IPv4 usando DHCPv4 o el tiempo de concesión de la dirección IPv4 se agota, el UE ProSe retransmisor del UE a la red esperará un tiempo específico de implementación del retransmisor antes de asignar la misma dirección IPv4 a otro UE remoto.
10.4.6.4 Configuración de la dirección IPv6 con la configuración automática de la dirección IPv6 sin estado El procedimiento del protocolo de configuración automática de la dirección IPv6 sin estado se llevará a cabo de la siguiente manera:
1. el UE que actúa como un proveedor de alojamiento IP enviará un mensaje Solicitud del Enrutador para solicitar un mensaje Anuncio del Enrutador como se especifica en el IETF RFC 4862 [15].
2. Al recibir el mensaje Solicitud del Enrutador, el otro UE enviará un mensaje Anuncio del Enrutador IPv6 como se especifica en el IETF RFC 4862 [15], que actúa como una interfaz publicitaria como se especifica en el IETF RFC 4861 [33]. Los mensajes Anuncio del Enrutador deben contener un prefijo IPv6, que se combinará con el identificador de interfaz para formar la dirección IPv6.
3. El UE que recibe el mensaje de anuncio del enrutador recupera la dirección del enrutador a partir del campo de dirección IP de origen del mensaje y forma su propia dirección IP con el prefijo y el identificador de interfaz como se especifica en el IETF RFC 4862 [15].
Si el enlace directo está configurado para la comunicación unívoca entre un UE remoto y un retransmisor de UE a red, el retransmisor de UE a red obtendrá el prefijo IPv6 asignado al UE remoto a través de la función de delegación del prefijo desde la red como se define en el 3GPP TS 23.401 [34] antes de enviar el prefijo IPv6 al UE remoto. Después de que el UE remoto recibe el mensaje Anuncio del Enrutador, construye una dirección IPv6 completa a través de la configuración automática de la dirección IPv6 sin estado de acuerdo con el IETF RFC 4862 [15]. Sin embargo, el UE remoto no utilizará ningún identificador definido en el TS 23.003 [4] como base para generar el identificador de interfaz. Por privacidad, el UE remoto puede cambiar el identificador de interfaz usado para generar la dirección IPv6 completa, como se define en el 3GPP TS 23.221 [35] sin implicar a la red. El UE remoto utilizará la dirección IPv6 configurada automáticamente mientras envía paquetes en esta conexión PDN creada implícitamente.
Si el enlace directo está configurado para la comunicación unívoca entre un UE remoto y un retransmisor del UE a la red y se requiere soporte para aplicaciones de misión crítica y control de políticas para UE remotos, al UE remoto se le asignará un prefijo /64 IPv6 a partir de un prefijo IPv6 más corto mediante el retransmisor del UE a la red. NOTA: Para admitir el control de políticas por UE remoto, se usa la asignación de un Prefijo /64 IPv6 a partir de un prefijo IPv6 más corto mediante el retransmisor del UE a la red. El soporte del formato de filtro TFT extendido que incluye el filtro de atributo de paquetes TFT Dirección local y máscara, como se define en el 3GPP TS 24.008 [30], es necesario en el retransmisor del UE a la red y en la red.
11.4.2 PETICIÓN_COMUNICACIÓN_DIRECTA
11.4.2.1 Definición de mensaje
Este mensaje es enviado por un UE a otro UE par para establecer un enlace directo. Véase la tabla 11.4.2.1.1. Tipo de mensaje: PETICIÓN_COMUNICACIÓN_DIRECTA
[La tabla 11.4.2,1.1 del 3GPP TR 24.334 V15.2.0, titulada "Contenido del mensaje PETICIÓN_COMUNICACIÓN_DIRECTA" se reproduce como la FIG. 9]
11.4.3 ACEPTAR_COMUNICACIÓN_DIRECTA
11.4.3.1 Definición de mensaje
El UE envía este mensaje a otro UE par para indicar que se ha aceptado la petición de establecimiento del enlace directo correspondiente. Véase la tabla 11.4.3.1.1.
Tipo de mensaje: ACEPTAR_COMUNICACIÓN_DIRECTA
[La tabla 11.4.3.1.1 del 3GPP TR 24.334 V15.2.0, titulada "Contenido del mensaje ACEPTAR_COMUNICACIÓN_DIRECTA" se reproduce como la FIG. 10]
11.4.12A COMANDO_MODO_SEGURIDAD_DIRECTA
11.4.12A.1 Definición de mensaje
Este mensaje es enviado por un UE de control a un UE par para establecer la seguridad de un enlace directo. Véase la tabla 11.4.12A.1.1.
Tipo de mensaje: COMANDO_MODO_SEGURIDAD_DIRECTA
[La tabla 11.4.12A.1.1 del 3GPP TR 24.334 V15.2.0, titulada "Contenido del mensaje COMANDO_MODO_SEGURIDAD_DIRECTA" se reproduce como la FIG. 11]
11.4.13 MODO_SEGURIDAD_DIRECTA_COMPLETA
11.4.13.1 Definición de mensaje
Este mensaje es enviado por un UE par a un UE de control para confirmar el establecimiento de la seguridad para un enlace directo. Véase la tabla 11.4.13.1.
Tipo de mensaje: MODO_SEGURIDAD_DIRECTA_COMPLETA
[La tabla 11.4.13.1 del 3GPP TR 24.334 V15.2.0, titulada "Contenido del mensaje MODO_SEGURIDAD_DIRECTA_COMPLETA" se reproduce como la FIG. 12]
12.5.1.4 Configuración de dirección IP
El propósito del elemento de información Configuración de la dirección IP es indicar las opciones de configuración para la dirección IP utilizada por el UE a través de este enlace directo.
La configuración de la dirección IP es un elemento de información de tipo 3. El IEI del IE Configuración de la dirección IP es 2.
El elemento de información Configuración de la dirección IP se codifica como se muestra en la figura 12.5.1.4.1 y la tabla 12.5.1.4.1.
[La figura 12.5.1.4.1 del 3GPP TR 24.334 V15.2.0, titulada "Elemento de información Configuración de la dirección IP" se reproduce como la FIG. 13]
[La tabla 12.5.1.4.1 del 3GPP TR 24.334 V15.2.0, titulada "Elemento de información Configuración de la dirección IP" se reproduce como la FIG. 14]
12.5.1.5 Dirección IPv6 de enlace local
El elemento de información de dirección IPv6 de enlace local contiene una dirección IPv6 de enlace local.
La dirección IPv6 de enlace local es un elemento de información de tipo 3. El IEI del IE Dirección IPv6 de enlace local es 3.
El elemento Dirección IPv6 de enlace local está codificado como se muestra en la figura 12.5.1.5.1 y la tabla 12.5.1.5.1.
[La figura 12.5.1.5.1 del 3GPP TR 24.334 V15.2.0, titulada "Elemento de información Configuración de la dirección IP" se reproduce como la FIG. 15]
[La tabla 12.5.1.5.1 del 3GPP TR 24.334 V15.2.0, titulada "Elemento de información Dirección IPv6" se reproduce como la FIG. 16]
3GPP TS 33.303 establece:
6.5 Seguridad para la comunicación directa unívoca ProSe
6.5.1 General
Los procedimientos de comunicación directa unívoca ProSe se describen en el TS 23.303 [2]. La comunicación directa unívoca ProSe es utilizada por dos UE que desean intercambiar tráfico directamente o cuando un UE remoto se conecta a un retransmisor ProSe retransmisor del UE a la red.
Los requisitos de seguridad se resumen en la sección 6.5.2. En la sección 6.5.3 se ofrece una descripción general de la comunicación directa unívoca ProSe. Los procedimientos de autenticación y establecimiento de claves para las comunicaciones unívocas básicas se describen en la sección 6.5.4. En la sección 6.5.5 se describe el establecimiento de seguridad general que se utiliza en todos los casos de uso.
La funcionalidad de esta cláusula solo se puede admitir en los UE de seguridad pública habilitados para ProSe.
6.5.2 Requisitos de seguridad
Los siguientes son los requisitos de seguridad para la comunicación directa unívoca ProSe:
Un UE habilitado para ProSe utilizará diferentes contextos de seguridad para la comunicación unívoca ProSe con diferentes UE habilitados para ProSe.
Se prestará soporte al cifrado de la señalización del enlace directo y se podrá utilizar. El cifrado de la señalización del enlace directo es una opción de configuración.
Se prestará soporte a, y se podrá utilizar, el cifrado en el plano de usuario del enlace directo.
Se prestará soporte a, y se utilizará, la protección de la integridad de la señalización de enlace directo y la protección de reproducción.
Los paquetes en el plano de usuario del enlace directo entre los UE no estarán protegidos por integridad.
El establecimiento de la seguridad entre los UE estará protegido de los ataques de intermediario.
El sistema debe admitir la autenticación mutua de los UE de seguridad pública fuera de la cobertura de la red. El compromiso de un único UE no debe afectar a la seguridad de los demás.
Las credenciales de autenticación deben almacenarse de forma segura en el UE.
6.5.3 Descripción general de la comunicación directa unívoca ProSe
6.5.3.3 Descripción general de alto nivel del establecimiento de seguridad
[La figura 6.5.3.3-1 del 3GPP TS 33.303 V15.0.0, titulada "Descripción general del establecimiento de seguridad de las comunicaciones directas unívocas ProSe" se reproduce como la FIG. 17]
La figura 6.5.3.3-1 proporciona una descripción general de alto nivel del establecimiento de seguridad. En este flujo, la autenticación y el establecimiento de la clave se produce durante las etapas 1 a 3 con el requisito de que el UE_2 debe conocer Kd al final de la etapa 2. La etapa 2 puede incluir varios mensajes, y estos mensajes dependen del tipo de clave(s) a largo plazo. Se proporcionan más detalles sobre esto en la subcláusula 6.5.4. El establecimiento real de un contexto de seguridad se produce durante las etapas 1, 3 y 4. Se proporcionan más detalles sobre esto en la subcláusula 6.5.5.
La protección de integridad y confidencialidad se aplica en la capa PDCP. Los detalles de esto se dan en la subcláusula 6.5.6.
6.5.4 Autenticación directa y establecimiento de claves
6.5.4.1 General
Existen diversos procedimientos que las comunicaciones directas unívocas ProSe pueden utilizar para proporcionar autenticación y establecimiento de Kd. Estos procedimientos pueden variar de un caso a otro y la descripción de cualquier autenticación directa necesaria y señalización para el establecimiento de la clave que se necesite además del mensaje Comando Modo de Seguridad Directo y Completo se cubrirá con cada caso específico.
NOTA: Ninguno de los casos incluidos en esta versión requiere ninguna señalización de autenticación directa y establecimiento de clave.
6.5.5 Procedimientos para el establecimiento de seguridad
6.5.5.1 General
Existen dos casos diferentes en los que se puede establecer un contexto de seguridad; para establecer una nueva conexión y restablecer una clave de una conexión en curso. Estos casos se describen en las siguientes subcláusulas.
6.5.5.2 Establecimiento de seguridad durante el establecimiento de la conexión
La subcláusula describe cómo se establece la seguridad durante el establecimiento de la conexión. El flujo de señalización se muestra en la figura 6.5.5.2-1.
[La figura 6.5.5.2-1 del 3GPP TS 33.303 V15.0.0, titulada "Establecimiento de seguridad en el establecimiento de la conexión" se reproduce como la FIG. 18]
1. El UE_1 ha enviado una petición de comunicación directa al UE_2. Este mensaje incluirá Nonce_1 (para la generación de claves de sesión), las capacidades de seguridad del UE_1 (la lista de algoritmos que el UE_1 aceptará para esta conexión) y los 8 bits más significativos del ID Ko-sess. Estos bits se elegirán de manera que el UE_1 pueda identificar localmente un contexto de seguridad creado por este procedimiento. El mensaje también puede incluir un Kd ID si el UE_1 tiene un Kd existente con el UE con el que intenta comunicarse. La ausencia del parámetro ID Kd indica que el UE_1 no tiene un Kd para el UE_2. El mensaje también contendrá la información necesaria para establecer un Kd a partir de las claves pertinentes a largo plazo que se encuentran en el UE (véase la subcláusula 6.X.4). La identificación a largo plazo es la información que necesita el UE_2 para recuperar la clave a largo plazo correcta.
2. El UE_2 puede iniciar un procedimiento de establecimiento de clave y autenticación directa con el UE_1. Esto es obligatorio si el UE_2 no tiene el par de ID Kd y Kd indicados en la etapa 1, y se necesita señalización para establecer las claves para el caso de uso particular.
3. El UE_2 envía el Comando Modo de Seguridad Directo al UE_1. Incluirá los bits más significativos del ID Kd si se genera un Kd nuevo, Nonce_2 para permitir que se calcule una clave de sesión y el parámetro Chosen_algs para indicar qué algoritmos de seguridad usarán los UE para proteger los datos. Los bits del ID Kd incluidos identificarán de forma única el Kd en el UE_2. El UE_2 también devolverá las capacidades de seguridad del UE_1 para proporcionar protección contra ataques de degradación. El UE_2 también incluye los 8 bits menos significativos del ID KD-sess en los mensajes. Estos bits se eligen para que el UE_2 pueda identificar localmente un contexto de seguridad creado por este procedimiento. El UE_2 calcula Ko-Sess a partir de Kd y Nonce_1 y Nonce_2 (véase el Anexo A.9) y luego deriva las claves de confidencialidad e integridad en base a los algoritmos elegidos (Anexo A.4). El UE_2 entonces protege la integridad del Comando Modo de Seguridad Directo antes de enviarlo al UE_1. El UE_2 está entonces listo para recibir tanto la señalización como el tráfico en el plano de usuario protegido con el nuevo contexto de seguridad. El UE_2 formará el ID Ko-sess a partir de los bits más significativos que ha recibido en el mensaje 1 y los bits menos significativos que ha enviado en el mensaje 3.
4. Al recibir el Comando Modo de Seguridad Directo, el UE_1 calculará Ko-sess y las claves de confidencialidad e integridad de la misma manera que el UE_2. El UE_1 comprobará que las capacidades de seguridad del UE_1 devueltas son las mismas que las que envió en la etapa 1. El UE_1 también comprobará la protección de integridad en el mensaje. Si ambas comprobaciones pasan, el UE_1 está listo para enviar y recibir señalización y tráfico de usuario con el nuevo contexto de seguridad. Si los bits más significativos del ID Kd se han incluido en el Comando Modo de Seguridad Directo, el UE_1 generará los bits menos significativos del ID Kd de manera que estos bits identifiquen de forma única a Kd en el UE_1 y almacenarán el ID Kd completo con Kd. El UE_1 enviará un mensaje Modo de Seguridad Directa Completo de integridad protegida y confidencialidad protegida (con el algoritmo elegido que puede ser el algoritmo nulo) al UE_2. El UE_1 incluirá los bits menos significativos del ID Kd en este mensaje. El UE_1 formará el ID Ko-sess a partir de los bits más significativos que ha enviado en el mensaje 1 y los bits menos significativos que ha recibido en el mensaje 3.
5. El UE_2 comprueba la protección de integridad en el Modo de Seguridad Directa Completo recibido. Si esto pasa, el UE_2 ahora está listo para enviar datos en el plano de usuario y señalización de control protegida con el nuevo contexto de seguridad. El UE_2 elimina cualquier contexto de seguridad antiguo que tenga para el UE_1. El UE_2 formará el ID Kd a partir de los bits más significativos que ha enviado en la etapa 3 y los bits menos significativos que ha recibido en el Modo de Seguridad Directa Completo. El UE_2 almacenará el ID Kd completo con Kd.
De acuerdo con el 3GPP TR 23.786, el UE-1 podría realizar un procedimiento de establecimiento de enlace de capa 2 con el UE-2 si el UE-1 tiende a comunicarse con el UE-2 a través de la comunicación unívoca con enlace lateral. Durante el establecimiento del enlace de capa 2, el UE-1 podría transmitir un mensaje Petición de Comunicación Directa al UE-2. Posiblemente, el mensaje Petición de Comunicación Directa podría incluir:
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Configuración de dirección IP;
- Información de seguridad;
- Parámetros de QoS de PC5 solicitados.
Tras la recepción del mensaje Petición de Comunicación Directa, el UE-2 podría transmitir un mensaje Aceptar Comunicación Directa al UE1. El mensaje Aceptar Comunicación Directa podría incluir:
- Parámetros de QoS de PC5 aceptados.
Como se analiza en el 3GPP TS 24.334, el contenido del mensaje Petición de Comunicación Directa se ha especificado con los siguientes elementos:
- Información de usuario;
- Configuración de dirección IP;
- Dirección IPv6 de enlace local.
De acuerdo con el 3GPP TS 24.334, un UE de destino luego verifica un IE Información de usuario incluido en un mensaje PETICIÓN_COMUNICACIÓN_DIRECTA tras la recepción del mensaje PETICIÓN_COMUNICACIÓN_DIRECTA y determina si esta petición puede aceptarse o no. Luego, el UE de destino examina un IE Configuración de la dirección IP incluido en el mensaje PETICIÓN_COMUNICACIÓN_DIRECTA para ver si hay al menos una opción de configuración de la dirección IP común admitida tanto por un UE iniciador como por el UE de destino. Si la comprobación anterior es satisfactoria, el UE de destino invocará un procedimiento de control del modo de seguridad directo para establecer una asociación de seguridad entre el UE de destino y el UE iniciador. Solo después de la finalización del procedimiento de autenticación del enlace y un establecimiento satisfactorio de la asociación de seguridad, el Ue de destino enviará un mensaje ACEPTAR_COMUNICACIÓN_DIRECTA al UE iniciador.
Además, el contenido del mensaje Aceptar Comunicación Directa se ha especificado con los siguientes elementos: - Configuración de dirección IP.
Si el UE de destino ha indicado "Enrutador IPv6" en la Configuración de la dirección IP en el mensaje ACEPTAR_COMUNICACIÓN_DIRECTA, entonces el UE iniciador iniciará la configuración de la dirección IPv6 con la configuración automática de la dirección IPv6 sin estado que actúa como un proveedor de alojamiento IPv6. Si el UE de destino ha indicado "no se admite la asignación de direcciones" en la configuración de la dirección IP y el UE iniciador ha indicado que podría ser un servidor DHCPv4 o un enrutador IPv6 en la configuración de la dirección IP, entonces el UE de destino iniciará la configuración de la dirección IPv6 con la configuración automática de la dirección IPv6 sin estado que actúa como un proveedor de alojamiento IPv6.
Como se analiza en el 3GPP TS 33.303, se ha especificado un establecimiento de seguridad en el establecimiento de la conexión para la comunicación unívoca con enlace lateral. En consecuencia, el UE-1 que desea participar en una comunicación unívoca con enlace lateral con el UE-2 envía un mensaje Petición de Comunicación Directa que incluye los siguientes parámetros:
- Información de usuario del UE-1;
- Una firma ECCSI del mensaje Petición de Comunicación Directa.
Tras la recepción del mensaje Petición de Comunicación Directa, el UE-2 verifica la carga útil de la firma SIGN (la firma ECCSI). Si la prueba de verificación es satisfactoria, el UE-2 presenta la identidad autenticada ("Información de usuario del UE-1") al usuario del UE-2. Si el usuario del UE-2 decide aceptar la petición, el UE-2 envía un mensaje Comando Modo de Seguridad Directa que incluye los siguientes parámetros:
- Información de usuario del UE-2;
- Una firma ECCSI del mensaje Respuesta de Comunicación Directa (el mensaje de Comando Modo de Seguridad Directa);
- SAKKE
Tras la recepción del mensaje Modo de Seguridad Directa, el UE-1 verifica la carga útil de la firma SIGN (la firma ECCSI del mensaje Respuesta de Comunicación Directa). Si la prueba de verificación es satisfactoria, descifra la carga útil de SAKKE para extraer el SSV que se utiliza como KD (clave raíz) de la que se pueden derivar otras claves. Tras el procesamiento satisfactorio del mensaje Comando Modo de Seguridad Directa, el UE-1 responde con un Modo de Seguridad Directa Completo al UE-2.
En base a la introducción anterior, en la figura 19 se podría ilustrar un diagrama de flujo ejemplar de un procedimiento de establecimiento de enlace directo para la comunicación unívoca con enlace lateral.
Cuando se inicializa un servicio (por ejemplo, un primer servicio V2X), el UE1 podría realizar una primera transmisión del enlace lateral al UE2. En la primera transmisión del enlace lateral, se podría incluir un mensaje Petición de Comunicación Directa.
En la primera transmisión del enlace lateral o en el mensaje Petición de Comunicación Directa, se podría incluir una o múltiples informaciones que se enumeran a continuación:
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Configuración de la dirección IP (utilizada para indicar si el UE1 podría ser un enrutador IPv6);
- Información de seguridad;
- Parámetros de QoS de PC5 solicitados;
- Información de usuario del UE1;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa.
Tras la recepción del mensaje Petición de Comunicación Directa, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podría incluir un mensaje Comando Modo de Seguridad Directa.
En la segunda transmisión del enlace lateral o en el mensaje Comando Modo de Seguridad Directa, se podría incluir una o múltiples informaciones que se enumeran a continuación:
- Información de usuario del UE2;
- Una firma ECCSI del mensaje Respuesta de Comunicación Directa (el mensaje de Comando Modo de Seguridad Directa);
- SAKKE
Tras la recepción del mensaje Comando Modo de Seguridad Directa, el UE1 podría realizar una tercera transmisión del enlace lateral al UE2. En la tercera transmisión del enlace lateral, se podría incluir un mensaje Modo de Seguridad Directa Completo.
Tras la recepción del mensaje Modo de Seguridad Directa Completo, el UE2 podría realizar una cuarta transmisión del enlace lateral al UE1. En la cuarta transmisión del enlace lateral, se podría incluir un mensaje Aceptar Comunicación Directa.
En la cuarta transmisión del enlace lateral o en el mensaje Aceptar Comunicación Directa, se podría incluir una o múltiples informaciones que se enumeran a continuación:
- Parámetros de QoS PC5 aceptados;
- Configuración de la dirección IP (utilizada para indicar si el UE2 podría ser un enrutador IPv6).
Si el UE2 pudiera ser un enrutador IPv6, el UE1 podría realizar una quinta transmisión del enlace lateral al UE2. En la quinta transmisión del enlace lateral, se podría incluir un mensaje Solicitud del Enrutador (que podría ser un primer mensaje de configuración de IP utilizado para solicitar o pedir una dirección IP (para el UE1)). Tras la recepción del mensaje Solicitud del Enrutador, el UE2 podría realizar una sexta transmisión del enlace lateral al UE1. En la sexta transmisión del enlace lateral, se podría incluir un mensaje Anuncio del Enrutador (que podría ser un segundo mensaje de configuración de IP usado para derivar o configurar la dirección IP (para el UE1)). Si el UE2 no pudiera ser un enrutador IPv6, el UE2 podría realizar una quinta transmisión del enlace lateral al UE1. En la quinta transmisión del enlace lateral, se podría incluir un mensaje Solicitud del Enrutador (que podría ser un primer mensaje de configuración de IP utilizado para solicitar o pedir una dirección IP (para el UE2)). Tras la recepción del mensaje Solicitud del Enrutador, el UE1 podría realizar una sexta transmisión del enlace lateral al UE2. En la sexta transmisión del enlace lateral, se podría incluir un mensaje Anuncio del Enrutador (que podría ser un segundo mensaje de configuración de IP usado para derivar o configurar la dirección IP (para el UE2)). De acuerdo con el 3GPP TR 23.786, los parámetros de QoS de PC5 podrían incluirse en un mensaje Petición de Comunicación Directa durante un procedimiento de establecimiento de enlace, lo que implica que la comunicación SL unívoca entre dos UE puede admitir solo un servicio V2X. Dado que la comunicación SL unívoca entre dos UE se puede utilizar para múltiples servicios V2X simultáneamente, los UE crearán múltiples enlaces directos si los UE siguen el procedimiento de establecimiento de enlace introducido en el 3GPP TR 23.786, TS 24.334 y TS 33.303. Por ejemplo, después de que se ha establecido un enlace de comunicación unívoca SL entre dos UE para un (muy) primer servicio V2X (por ejemplo, un servicio V2X no urgente), puede producirse una situación urgente. Por tanto, es necesario activar un segundo servicio V2X (por ejemplo, un servicio V2X urgente) entre estos dos UE a través de otro enlace de comunicación unívoca SL. Como resultado, esta situación podría provocar una sobrecarga de señalización que podría ilustrarse en la FIG. 20 ejemplar.
Durante el procedimiento de establecimiento de enlace directo para el primer servicio V2X, tanto el UE1 como el UE2 comprenden la información/capacidad del UE (por ejemplo, Información de usuario, parámetro de QoS de PC5, Configuración de la dirección IP (utilizado para indicar si el UE puede ser un Enrutador IPv6), Capacidades de seguridad del UE, etc.) entre sí. Por lo tanto, podrían considerarse algunos procedimientos para fusionar la señalización en una única transmisión del enlace lateral para reducir la sobrecarga de señalización en un procedimiento de establecimiento de enlace directo para los siguientes servicios V2X (por ejemplo, el segundo servicio V2X).
I. Dirección 1: La asociación de seguridad entre el UE1 y el UE2 podría ser por servicio V2X.
En esta dirección, una primera asociación de seguridad podría asociarse con el primer servicio V2X. Además, una segunda asociación de seguridad podría asociarse con el segundo servicio V2X.
Caso 1: El UE2 es un enrutador IPv6 (de acuerdo con la configuración de la dirección IP negociada durante el procedimiento de establecimiento de enlace para el primer servicio V2X)
Se podrían ilustrar ejemplos de diagrama de flujo en la FIG. 21 ejemplar. Cuando se inicializa un servicio (por ejemplo, el segundo servicio V2X), el UE1 podría realizar una primera transmisión del enlace lateral al UE2. Opción 1 en la FIG. 21 - En la primera transmisión del enlace lateral, se podrían incluir un mensaje Petición de Comunicación Directa y un mensaje Solicitud del Enrutador. En la primera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación (para el segundo servicio V2X):
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Información de seguridad;
- Parámetros de QoS de PC5 solicitados;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa (y/o el mensaje Solicitud del Enrutador);
- Un primer mensaje de configuración de IP utilizado para solicitar/preguntar una dirección IP (para el UE1). Tras la recepción de la primera transmisión del enlace lateral, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podría incluir un mensaje Comando Modo de Seguridad Directa y un mensaje Anuncio del Enrutador. En la segunda transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Información de usuario del UE2;
- Una firma ECCSI del mensaje Respuesta de Comunicación Directa (el mensaje Comando Modo de Seguridad Directa y/o el mensaje Anuncio del Enrutador);
- SAKKE;
- Un segundo mensaje de configuración de IP utilizado para derivar o configurar la dirección IP (para el UE1). Tras la recepción de la segunda transmisión del enlace lateral, el UE1 podría realizar una tercera transmisión del enlace lateral al UE2. En la tercera transmisión del enlace lateral, se podría incluir un mensaje Modo de Seguridad Directa Completo.
Tras la recepción del mensaje Modo de Seguridad Directa Completo, el UE2 podría realizar una cuarta transmisión del enlace lateral al UE1. En la cuarta transmisión del enlace lateral, se podría incluir un mensaje Aceptar Comunicación Directa. En la cuarta transmisión del enlace lateral o en el mensaje Aceptar Comunicación Directa, se podría incluir una o múltiples informaciones que se enumeran a continuación:
- Parámetros de QoS de PC5 aceptados.
Opción 2 en la FIG. 21 - En la primera transmisión del enlace lateral, se podrían incluir un mensaje Petición de Comunicación Directa y un mensaje Solicitud del Enrutador. En la primera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación (para el segundo servicio V2X):
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Información de seguridad;
- Parámetros de QoS de PC5 solicitados;
- Información de usuario del UE1;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa (y/o el mensaje Solicitud del Enrutador);
- Un primer mensaje de configuración de IP utilizado para solicitar o pedir una dirección IP (para el UE1).
Tras la recepción de la primera transmisión del enlace lateral, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podría incluir un mensaje Comando Modo de Seguridad Directa. En la segunda transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Información de usuario del UE2;
- Una firma ECCSI del mensaje Respuesta de Comunicación Directa (el mensaje de Comando Modo de Seguridad Directa);
- SAKKE
Tras la recepción de la segunda transmisión del enlace lateral, el UE1 podría realizar una tercera transmisión del enlace lateral al UE2. En la tercera transmisión del enlace lateral, se podría incluir un mensaje Modo de Seguridad Directa Completo.
Tras la recepción del mensaje Modo de Seguridad Directa Completo, el UE2 podría realizar una cuarta transmisión del enlace lateral al UE1. En la cuarta transmisión del enlace lateral, se podrían incluir un mensaje Aceptar Comunicación Directa y un mensaje Anuncio del Enrutador. En la cuarta transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Parámetros de QoS PC5 aceptados;
- Un segundo mensaje de configuración de IP utilizado para derivar o configurar la dirección IP (para el UE1). Opción 3 en la FIG. 21 - En la primera transmisión del enlace lateral, se podría incluir un mensaje Petición de Comunicación Directa. En la primera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación (para el segundo servicio V2X):
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Información de seguridad;
- Parámetros de QoS de PC5 solicitados;
- Información de usuario del UE1;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa.
Tras la recepción de la primera transmisión del enlace lateral, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podría incluir un mensaje Comando Modo de Seguridad Directa. En la segunda transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Información de usuario del UE2;
- Una firma ECCSI del mensaje Respuesta de Comunicación Directa (el mensaje de Comando Modo de Seguridad Directa);
- SAKKE
Tras la recepción del mensaje Comando Modo de Seguridad Directa, el UE1 podría realizar una tercera transmisión del enlace lateral al UE2. En la tercera transmisión del enlace lateral, se podría incluir un mensaje Modo de Seguridad Directa Completo y un mensaje Solicitud del Enrutador. En la tercera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Un primer mensaje de configuración de IP utilizado para solicitar o pedir una dirección IP (para el UE1).
Tras la recepción de la tercera transmisión del enlace lateral, el UE2 podría realizar una cuarta transmisión del enlace lateral al UE1. En la cuarta transmisión del enlace lateral, se podrían incluir un mensaje Aceptar Comunicación Directa y un mensaje Anuncio del Enrutador. En la cuarta transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Parámetros de QoS PC5 aceptados;
- Un segundo mensaje de configuración de IP utilizado para derivar o configurar la dirección IP (para el UE1). Después de completar las transmisiones de enlace lateral anteriores, el UE1 y UE2 podrían iniciar la transferencia de tráfico V2X para el segundo servicio V2X a través de la comunicación unívoca con enlace lateral.
Caso 2: El UE2 no admite la asignación de direcciones IP (de acuerdo con la configuración de la dirección IP negociada durante el procedimiento de establecimiento del enlace para el primer servicio V2X)
Se podrían ilustrar ejemplos de diagrama de flujo en la FIG. 22 ejemplar. Cuando se inicializa un servicio (por ejemplo, el segundo servicio V2X), el UE1 podría realizar una primera transmisión del enlace lateral al UE2. Opción 1 en la FIG. 22 - En la primera transmisión del enlace lateral, se podría incluir un mensaje Petición de Comunicación Directa. En la primera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación (para el segundo servicio V2X):
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Información de seguridad;
- Parámetros de QoS de PC5 solicitados;
- Información de usuario del UE1;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa (y/o el mensaje Solicitud del Enrutador).
Tras la recepción de la primera transmisión del enlace lateral, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podría incluir un mensaje Comando Modo de Seguridad Directa y un mensaje Solicitud del Enrutador. En la segunda transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Información de usuario del UE2;
- Una firma ECCSI del mensaje Respuesta de Comunicación Directa (el mensaje Comando Modo de Seguridad Directa y/o el mensaje Anuncio del Enrutador);
- SAKKE;
- Un primer mensaje de configuración de IP utilizado para solicitar o pedir una dirección IP (para el UE2).
Tras la recepción de la segunda transmisión del enlace lateral, el UE1 podría realizar una tercera transmisión del enlace lateral al UE2. En la tercera transmisión del enlace lateral, se podría incluir un mensaje Modo de Seguridad Directa Completo y un mensaje Anuncio del Enrutador. En la tercera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Un segundo mensaje de configuración de IP utilizado para derivar o configurar la dirección IP (para el UE2). Tras la recepción de la tercera transmisión del enlace lateral, el UE2 podría realizar una cuarta transmisión del enlace lateral al UE1. En la cuarta transmisión del enlace lateral, se podría incluir un mensaje Aceptar Comunicación Directa. En la cuarta transmisión del enlace lateral o en el mensaje Aceptar Comunicación Directa, se podría incluir una o múltiples informaciones que se enumeran a continuación:
- Parámetros de QoS de PC5 aceptados.
Opción 2 en la FIG. 22 - En la primera transmisión del enlace lateral, se podría incluir un mensaje Petición de Comunicación Directa. En la primera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación (para el segundo servicio V2X):
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Información de seguridad;
- Parámetros de QoS de PC5 solicitados;
- Información de usuario del UE1;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa (y/o el mensaje Solicitud del Enrutador).
Tras la recepción de la primera transmisión del enlace lateral, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podría incluir un mensaje Comando Modo de Seguridad Directa. En la segunda transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Información de usuario del UE2;
- Una firma ECCSI del mensaje Respuesta de Comunicación Directa (el mensaje de Comando Modo de Seguridad Directa);
- SAKKE
Tras la recepción de la segunda transmisión del enlace lateral, el UE1 podría realizar una tercera transmisión del enlace lateral al UE2. En la tercera transmisión del enlace lateral, se podría incluir un mensaje Modo de Seguridad Directa Completo.
Tras la recepción del mensaje Modo de Seguridad Directa Completo, el UE2 podría realizar una cuarta transmisión del enlace lateral al UE1. En la cuarta transmisión del enlace lateral, se podrían incluir un mensaje Aceptar Comunicación Directa y un mensaje Solicitud del Enrutador. En la cuarta transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Parámetros de QoS PC5 aceptados;
- Un primer mensaje de configuración de IP utilizado para solicitar o pedir una dirección IP (para el UE2).
Tras la recepción de la cuarta transmisión del enlace lateral, el UE1 podría realizar una quinta transmisión del enlace lateral al UE2. En la quinta transmisión del enlace lateral, se podría incluir un mensaje Anuncio del Enrutador. En la quinta transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Un segundo mensaje de configuración de IP utilizado para derivar o configurar la dirección IP (para el UE2). Después de completar las transmisiones de enlace lateral anteriores, el UE1 y UE2 podrían iniciar la transferencia de tráfico V2X para el segundo servicio V2X a través de la comunicación unívoca con enlace lateral.
II. Dirección 2: La configuración de seguridad entre el UE1 y el UE2 podría ser por comunicación unívoca con enlace lateral.
En esta dirección, el primer servicio V2X y el segundo servicio V2X comparten una configuración de seguridad común. Además, la señalización adicional utilizada para negociar la configuración de seguridad (por ejemplo, el Comando Modo de Seguridad Directa y el Modo de Seguridad Directa Completo) para los siguientes servicios V2X (por ejemplo, el segundo servicio V2X) puede no ser necesaria.
Caso 1: El UE2 es un enrutador IPv6 (de acuerdo con la configuración de la dirección IP negociada durante el procedimiento de establecimiento de enlace para el primer servicio V2X)
Un ejemplo de diagrama de flujo de servicios se podría ilustrar en la FIG. 23 ejemplar. Cuando se inicializa un servicio (por ejemplo, el segundo servicio V2X), el UE1 podría realizar una primera transmisión del enlace lateral al UE2.
En la primera transmisión del enlace lateral, se podrían incluir un mensaje Petición de Comunicación Directa y un mensaje Solicitud del Enrutador. Dado que el primer servicio V2X y el segundo servicio V2X son admitidos en un enlace de comunicación unívoca SL y comparten la misma asociación de seguridad, lo que se requiere absolutamente para el segundo inicio del servicio V2X podría ser la negociación de QoS entre el UE1 y el UE2. Por lo tanto, es posible que no se necesite parte de los elementos de información incluidos en la Petición de Comunicación Directa y/o Aceptar Comunicación Directa, por ejemplo, Información del usuario, Capacidades de seguridad del UE, Configuración de la dirección IP (utilizada para indicar si el UE puede ser un Enrutador IPv6), y/o etc. En la primera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación (para el segundo servicio V2X):
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Parámetros de QoS de PC5 solicitados;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa (y/o el mensaje Solicitud del Enrutador);
- Un primer mensaje de configuración de IP utilizado para solicitar o pedir una dirección IP (para el UE1).
Tras la recepción de la primera transmisión del enlace lateral, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podrían incluir un mensaje Aceptar Comunicación Directa y un mensaje Anuncio del Enrutador. En la segunda transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Parámetros de QoS PC5 aceptados;
- Un segundo mensaje de configuración de IP utilizado para derivar/configurar la dirección IP (para el UE1). Después de completar las transmisiones de enlace lateral anteriores, el UE1 y UE2 podrían iniciar la transferencia de tráfico V2X para el segundo servicio V2X a través de la comunicación unívoca con enlace lateral.
Caso 2: El UE2 no admite la asignación de direcciones IP (de acuerdo con la configuración de la dirección IP negociada durante el procedimiento de establecimiento del enlace para el primer servicio V2X)
Un ejemplo de diagrama de flujo de servicios se podría ilustrar en la FIG. 24 ejemplar. Cuando se inicializa un servicio (por ejemplo, el segundo servicio V2X), el UE1 podría realizar una primera transmisión del enlace lateral al UE2.
En la primera transmisión del enlace lateral, se podría incluir un mensaje Petición de Comunicación Directa. Dado que el primer servicio V2X y el segundo servicio V2X son admitidos en un enlace de comunicación unívoca SL y comparten la misma asociación de seguridad, lo que se requiere absolutamente para el segundo inicio del servicio V2X podría ser la negociación de QoS entre el u E1 y el u E2. Por lo tanto, es posible que no se necesite parte de los elementos de información incluidos en la Petición de Comunicación Directa y/o Aceptar Comunicación Directa, por ejemplo, Información del usuario, Capacidades de seguridad del UE, Configuración de la dirección IP (utilizada para indicar si el UE puede ser un Enrutador IPv6), y/o etc. En la primera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación (para el segundo servicio V2X):
- Una identidad de capa superior del UE1;
- Una identidad de capa superior del UE2;
- Una identidad de servicio para una aplicación V2X;
- Una identidad de una aplicación V2X;
- Parámetros de QoS de PC5 solicitados;
- Dirección IPv6 de enlace local;
- Una firma ECCSI del mensaje Petición de Comunicación Directa (y/o el mensaje Solicitud del Enrutador).
Tras la recepción de la primera transmisión del enlace lateral, el UE2 podría realizar una segunda transmisión del enlace lateral al UE1. En la segunda transmisión del enlace lateral, se podrían incluir un mensaje Aceptar Comunicación Directa y un mensaje Solicitud del Enrutador. En la segunda transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Parámetros de QoS PC5 aceptados;
- Un primer mensaje de configuración de IP utilizado para solicitar/preguntar una dirección IP (para el UE2). Tras la recepción de la segunda transmisión del enlace lateral, el UE1 podría realizar una tercera transmisión del enlace lateral al UE2. En la tercera transmisión del enlace lateral, se podría incluir un mensaje Anuncio del Enrutador. En la tercera transmisión del enlace lateral, se podría incluir una o múltiples informaciones enumeradas a continuación:
- Un segundo mensaje de configuración de IP utilizado para derivar/configurar la dirección IP (para el UE2). Después de completar las transmisiones de enlace lateral anteriores, el UE1 y UE2 podrían iniciar la transferencia de tráfico V2X para el segundo servicio V2X a través de la comunicación unívoca con enlace lateral.
Independientemente de cualquier procedimiento o invención analizado anteriormente, la conexión para la comunicación unívoca con enlace lateral podría ser un enlace de nivel AS entre dispositivos (o vehículos). Preferentemente, la conexión para la comunicación unívoca con enlace lateral podría ser una conexión de RRC entre dispositivos (o vehículos). Independientemente de cualquier procedimiento o invención analizado anteriormente, el UE podría ser un vehículo.
La FIG. 25 es un diagrama de flujo 2500 de acuerdo con un modo de realización ejemplar desde la perspectiva de un primer UE que admite múltiples servicios en un enlace de comunicación unívoca con enlace lateral entre el primer UE y un segundo UE. En la etapa 2505, el primer UE inicia un primer servicio. En la etapa 2510, el primer UE establece el enlace de comunicación unívoca con enlace lateral para el primer servicio. En la etapa 2515, el primer UE negocia una configuración de seguridad con el segundo UE para cifrar o descifrar datos del primer servicio. En la etapa 2520, el primer UE inicia un segundo servicio. En la etapa 2525, el primer UE cifra o descifra datos del segundo servicio con la configuración de seguridad utilizada por el primer servicio.
Preferentemente, el primer UE puede negociar la configuración de seguridad con el segundo UE durante el establecimiento del enlace de comunicación unívoca con enlace lateral con el segundo UE. La configuración de seguridad puede incluir al menos una clave de seguridad.
Preferentemente, el primer UE puede crear al menos un primer canal de tráfico de enlace lateral (STCH) o portadora de radio de enlace lateral (SLRB) para el primer servicio. El primer UE también puede crear al menos un segundo STCH o SLRB para el segundo servicio.
Preferentemente, el primer UE puede representar datos de un primer flujo de QoS o flujo de tráfico del primer servicio a uno del al menos un primer STCh o SLRB para su transmisión de acuerdo con una primera información de representación configurada mediante un nodo de red. El primer UE también puede representar datos de un segundo flujo de QoS o flujo de tráfico del segundo servicio a uno del al menos un primer STCH (o SLRB) o uno del al menos un segundo STCH (o SLRB) para la transmisión de acuerdo con una segunda información de representación configurada mediante un nodo de red. El nodo de red podría ser una estación base, por ejemplo, gNB.
En referencia de nuevo a las FIG. 3 y 4, en un modo de realización ejemplar de un primer UE para admitir múltiples servicios en un enlace de comunicación unívoca con enlace lateral entre el primer UE y un segundo UE, el dispositivo 300 incluye un código de programa 312 almacenado en la memoria 310. La CPU 308 podría ejecutar el código de programa 312 para permitir que el primer UE (i) inicie un primer servicio, (ii) establezca el enlace de comunicación unívoca con enlace lateral para el primer servicio, (iii) negocie una configuración de seguridad con el segundo UE para cifrar o descifrar datos del primer servicio, (iv) inicie un segundo servicio, y (v) cifre o descifre datos del segundo servicio con la configuración de seguridad utilizada por el primer servicio. Además, la CPU 308 puede ejecutar el código de programa 312 para realizar todas las acciones y etapas descritos anteriormente u otros descritos en el presente documento.
Se han descrito diversos aspectos de la divulgación anteriormente. Debería ser evidente que las enseñanzas del presente documento se pueden expresar en una amplia variedad de formas y que cualquier estructura o función específica, o ambas, que se divulguen en el presente documento son meramente representativas. En base a las enseñanzas en el presente documento, un experto en la técnica debería apreciar que un aspecto divulgado en el presente documento se puede implementar independientemente de cualquier otro aspecto, y que dos o más de estos aspectos se pueden combinar de diversas maneras. Por ejemplo, un aparato se puede implementar o un procedimiento se puede llevar a la práctica usando un número cualquiera de los aspectos expuestos en el presente documento. Además, un aparato de este tipo se puede implementar o un procedimiento de este tipo se puede llevar a la práctica usando otra estructura, funcionalidad, o estructura y funcionalidad, además de, o diferente de, uno o más de los aspectos expuestos en el presente documento. Como ejemplo de algunos de los conceptos anteriores, en algunos aspectos pueden establecerse canales simultáneos en base a frecuencias de repetición de pulsos. En algunos aspectos pueden establecerse canales simultáneos en base a los desfases o la posición de los pulsos. En algunos aspectos pueden establecerse canales simultáneos en base a secuencias de saltos de tiempo. En algunos aspectos pueden establecerse canales simultáneos en base a frecuencias de repetición de pulsos, desfases o posiciones de los pulsos y secuencias de salto de tiempo.
Los expertos en la técnica entenderán que la información y las señales se pueden representar usando cualquiera de una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, las instrucciones, los comandos, la información, las señales, los bits, los símbolos y los chips que se pueden haber mencionado a lo largo de la descripción anterior se pueden representar mediante tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticos, o cualquier combinación de los mismos.
Los expertos en la técnica apreciarán además que los diversos bloques lógicos, módulos, procesadores, medios, circuitos y etapas de algoritmo ilustrativos, descritos en relación con los aspectos divulgados en el presente documento pueden implementarse como hardware electrónico (por ejemplo, una implementación digital, una implementación analógica o una combinación de las dos que pueda diseñarse utilizando codificación de fuente o alguna otra técnica), como diversas formas de código de programa o de diseño que incluyan instrucciones (que pueden denominarse en el presente documento, por comodidad, "software" o "módulo de software") o como combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, anteriormente se han descrito, en general, diversos componentes, bloques, módulos, circuitos y etapas ilustrativos desde el punto de vista de su funcionalidad. Que dicha funcionalidad se implemente como hardware o software depende de las restricciones particulares de aplicación y de diseño impuestas al sistema global. Los expertos en la técnica pueden implementar la funcionalidad descrita de formas variadas para cada aplicación particular, pero no se debe interpretar que dichas decisiones de implementación suponen apartarse del alcance de la presente divulgación.
Además, los diversos bloques lógicos, módulos y circuitos ilustrativos descritos en relación con los aspectos divulgados en el presente documento se pueden implementar dentro de, o realizar mediante, un circuito integrado ('IC"), un terminal de acceso o un punto de acceso. El IC puede comprender un procesador de propósito general, un procesador de señales digitales (DSP), un circuito integrado específico de la aplicación (ASIC), una matriz de puertas programables in situ (FPGA) u otro dispositivo lógico programable, lógica discreta de puertas o transistores, componentes de hardware discretos, componentes eléctricos, componentes ópticos, componentes mecánicos o cualquier combinación de los mismos diseñada para realizar las funciones que se describen en el presente documento, y puede ejecutar códigos o instrucciones que residen dentro del IC, fuera del IC o ambas cosas. Un procesador de propósito general puede ser un microprocesador pero, como alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también se puede implementar como una combinación de dispositivos informáticos, por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP, o cualquier otra configuración de este tipo.
Se debe entender que cualquier orden o jerarquía de etapas específicos en cualquier proceso divulgado es un ejemplo de enfoque de muestra. En base a las preferencias de diseño, se entiende que el orden o jerarquía de etapas específicos en los procesos se pueden reorganizar al mismo tiempo que se mantienen dentro del alcance de la presente divulgación. Las reivindicaciones de procedimiento adjuntas presentan elementos de las diversas etapas en un orden de muestra y no se pretenden limitar al orden o la jerarquía específicos presentados.
Las etapas de un procedimiento o algoritmo descrito en conexión con los aspectos divulgados en el presente documento se pueden materializar directamente en hardware, en un módulo de software ejecutado por un procesador o en una combinación de los dos. Un módulo de software (por ejemplo, incluyendo instrucciones ejecutables y datos relacionados) y otros datos pueden residir en una memoria de datos, como una memoria RAM, una memoria flash, una memoria ROM, una memoria EPROM, una memoria EEPROM, registros, un disco duro, un disco extraíble, un CD-ROM o cualquier otra forma de medio de almacenamiento legible por ordenador conocido en la técnica. Se puede acoplar a una máquina un medio de almacenamiento de muestra tal como, por ejemplo, un ordenador/procesador (que en el presente documento se puede denominar, por conveniencia, un "procesador") de modo que el procesador pueda leer información (por ejemplo, código) del y escribir información en el medio de almacenamiento. Un medio de almacenamiento de muestra puede estar integrado en el procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un equipo de usuario. De forma alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un equipo de usuario. Además, en algunos aspectos, cualquier producto de programa informático adecuado puede comprender un medio legible por ordenador que comprende códigos relacionados con uno o más de los aspectos de la divulgación. En algunos aspectos, un producto de programa informático puede incluir materiales de embalaje.
Aunque la invención se ha descrito en relación con diversos aspectos, se comprenderá que la invención es capaz de otras modificaciones. Esta solicitud está destinada a cubrir cualquier variación, uso o adaptación de la invención siguiendo, en general, los principios de la invención, e incluyendo tales desviaciones de la presente divulgación, dentro de la práctica conocida y habitual dentro de la técnica a la que pertenece la invención.

Claims (14)

REIVINDICACIONES
1. Un procedimiento para un primer equipo de usuario, a continuación, también denominado UE, que admite múltiples servicios en un enlace de comunicación unívoca con enlace lateral entre el primer UE y un segundo UE, que comprende:
iniciar un primer servicio (2505);
establecer el enlace de comunicación unívoca con enlace lateral para el primer servicio (2510);
negociar una configuración de seguridad con el segundo UE para cifrar o descifrar datos del primer servicio (2515); iniciar un segundo servicio (2520); y
cifrar o descifrar datos del segundo servicio con la configuración de seguridad utilizada por el primer servicio (2525).
2. El procedimiento de la reivindicación 1, en el que el primer UE negocia la configuración de seguridad con el segundo UE durante el establecimiento del enlace de comunicación unívoca con enlace lateral con el segundo UE.
3. El procedimiento de la reivindicación 1 o 2, en el que la configuración de seguridad incluye al menos una clave de seguridad:
4. El procedimiento de cualquiera de las reivindicaciones 1 a 3, que comprende, además:
crear al menos un primer canal de tráfico de enlace lateral, a continuación, también denominado STCH, o portador de radio de enlace lateral, a continuación, también denominado SLRB, para el primer servicio.
5. El procedimiento de cualquiera de las reivindicaciones 1 a 4, que comprende, además:
crear al menos un segundo STCH o SLRB para el segundo servicio.
6. El procedimiento de una cualquiera de las reivindicaciones 1 a 5, que comprende, además:
representar datos de una primera calidad de servicio, a continuación, también denominada como QoS, flujo o flujo de tráfico del primer servicio a uno de al menos un primer STCH o SLRB para la transmisión de acuerdo con una primera información de representación configurada mediante un nodo de red.
7. El procedimiento de una cualquiera de las reivindicaciones 1 a 6, que comprende, además:
representar datos de un segundo flujo de QoS o flujo de tráfico del segundo servicio a uno del al menos primer STCH o SLRB o a uno del al menos segundo STCH o SLRB para la transmisión de acuerdo con una segunda información de representación configurada mediante un nodo de red.
8. Un primer equipo de usuario, a continuación, también denominado UE, para establecer un enlace de comunicación unívoca con enlace lateral entre el primer UE y un segundo UE, que comprende:
un circuito de control (306);
un procesador (308) instalado en el circuito de control (306); y
una memoria (310) instalada en el circuito de control (306) y acoplada de forma operativa al procesador (308); en el que el procesador (308) está configurado para ejecutar un código de programa (312) almacenado en la memoria (310) para:
iniciar un primer servicio;
establecer el enlace de comunicación unívoca con enlace lateral para el primer servicio;
negociar una configuración de seguridad con el segundo UE para cifrar o descifrar datos del primer servicio; iniciar un segundo servicio; y
cifrar o descifrar datos del segundo servicio con la configuración de seguridad utilizada por el primer servicio.
9. El primer UE de la reivindicación 8, en el que el procesador está configurado para ejecutar un código de programa almacenado en la memoria para:
negociar la configuración de seguridad con el segundo UE durante el establecimiento del enlace de comunicación unívoca con enlace lateral con el segundo UE.
10. El primer UE de la reivindicación 8 o 9, en el que la configuración de seguridad incluye al menos una clave de seguridad.
11. El primer UE de una cualquiera de las reivindicaciones 8 a 10, en el que el procesador está configurado para ejecutar un código de programa almacenado en la memoria para:
crear al menos un primer canal de tráfico de enlace lateral, a continuación, también denominado STCH, o portador de radio de enlace lateral, a continuación, también denominado SLRB, para el primer servicio.
12. El primer UE de una cualquiera de las reivindicaciones 8 a 11, en el que el procesador está configurado para ejecutar un código de programa almacenado en la memoria para:
crear al menos un segundo STCH o SLRB para el segundo servicio.
13. El primer UE de una cualquiera de las reivindicaciones 8 a 12, en el que el procesador está configurado para ejecutar un código de programa almacenado en la memoria para:
representar datos de una primera calidad de servicio, a continuación, también denominado QoS, flujo o flujo de tráfico del primer servicio a uno del al menos primer STCH o SLRB para su transmisión de acuerdo con una primera información de representación configurada mediante un nodo de red.
14. El primer UE de una cualquiera de las reivindicaciones 8 a 13, en el que el procesador está configurado para ejecutar un código de programa almacenado en la memoria para:
representar datos de un segundo flujo de QoS o flujo de tráfico del segundo servicio a uno del al menos primer STCH o SLRB o uno del al menos segundo STCH o SLRB para la transmisión de acuerdo con una segunda información de representación configurada mediante un nodo de red.
ES19220167T 2019-01-04 2019-12-31 Procedimiento y aparato para admitir servicios de vehículo a todo (V2X) en un único enlace de comunicación unívoca con enlace lateral en un sistema de comunicación inalámbrica Active ES2882300T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201962788450P 2019-01-04 2019-01-04

Publications (1)

Publication Number Publication Date
ES2882300T3 true ES2882300T3 (es) 2021-12-01

Family

ID=69055903

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19220167T Active ES2882300T3 (es) 2019-01-04 2019-12-31 Procedimiento y aparato para admitir servicios de vehículo a todo (V2X) en un único enlace de comunicación unívoca con enlace lateral en un sistema de comunicación inalámbrica

Country Status (5)

Country Link
US (1) US11457355B2 (es)
EP (1) EP3678450B1 (es)
KR (1) KR102303882B1 (es)
CN (1) CN111417092B (es)
ES (1) ES2882300T3 (es)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7027892B2 (ja) * 2016-02-03 2022-03-02 ソニーグループ株式会社 端末装置および通信方法
WO2020145676A1 (ko) * 2019-01-10 2020-07-16 엘지전자 주식회사 무선 통신 시스템에서 상향링크 전송을 수행하는 방법 및 이에 대한 장치
JP7201823B2 (ja) * 2019-01-18 2023-01-10 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 他の周波数スペクトラムでのｖ２ｘサービス調整のためのサービス情報
JP7273523B2 (ja) * 2019-01-25 2023-05-15 株式会社東芝 通信制御装置および通信制御システム
US11252777B2 (en) * 2019-01-27 2022-02-15 Qualcomm Incorporated Coordinating radio resource control signaling with upper layer direct link establishment procedures
US20220117017A1 (en) * 2019-02-14 2022-04-14 Lg Electronics Inc. Identification of sidelink connection associated with multiple sessions
WO2020175604A1 (ja) * 2019-02-27 2020-09-03 パナソニックＩｐマネジメント株式会社 無線通信端末装置及びその無線通信方法
CN113711567A (zh) * 2019-03-26 2021-11-26 Idac控股公司 用于通过pc5接口进行安全无线电资源控制(rrc)信令以用于单播通信的方法、装置和系统
CN109921898A (zh) * 2019-03-28 2019-06-21 新华三技术有限公司 IPv6无状态地址生成方法及装置
CN111615219B (zh) * 2019-04-30 2022-02-22 维沃移动通信有限公司 一种pc5链路建立方法、设备及系统
US11206640B2 (en) 2019-05-22 2021-12-21 At&T Intellectual Property I, L.P. Private local network access, authentication, and association for 5G or other next generation network
JP6833906B2 (ja) * 2019-05-28 2021-02-24 Ｎｅｃプラットフォームズ株式会社 無線システム、無線システムの制御方法および無線システムの制御プログラム
CN112351431B (zh) * 2019-08-09 2023-06-30 华为技术有限公司 一种安全保护方式确定方法及装置
US11533613B2 (en) * 2019-08-16 2022-12-20 Qualcomm Incorporated Providing secure communications between computing devices
CN114125835B (zh) * 2019-11-17 2025-08-01 Oppo广东移动通信有限公司 侧链路安全配置过程
BR112022015258A2 (pt) * 2020-02-03 2022-09-20 Ericsson Telefon Ab L M Método implementado em um primeiro equipamento de usuário, sistema compreendendo instruções de programas de computador, e, primeiro equipamento de usuário
US20230077297A1 (en) * 2020-02-17 2023-03-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and Apparatus for Privacy Protection
CN120416854A (zh) * 2020-02-17 2025-08-01 三星电子株式会社 用于在v2x通信系统中处理安全性策略的方法和装置
US20230109855A1 (en) * 2020-03-04 2023-04-13 Lg Electronics Inc. Direct communication
US11825330B2 (en) 2020-03-13 2023-11-21 Qualcomm Incorporated Techniques for quality of service support in sidelink communications
US11689957B2 (en) * 2020-03-13 2023-06-27 Qualcomm Incorporated Quality of service support for sidelink relay service
EP4111720B1 (en) * 2020-04-01 2025-04-23 Apple Inc. Vehicle-to-everything (v2x) security policy negotiation between peer user equipments (ues)
US12526615B2 (en) * 2020-07-30 2026-01-13 Qualcomm Incorporated User plane protocol design for new radio (NR) sidelink discovery message
CN114079915B (zh) * 2020-08-06 2024-11-22 华为技术有限公司 确定用户面安全算法的方法、系统及装置
WO2022032506A1 (en) * 2020-08-12 2022-02-17 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for non-ip traffic communication by ue-to-ue relay
CN114079881B (zh) * 2020-08-13 2024-05-17 华为技术有限公司 一种通信方法及装置
CA3189502A1 (en) * 2020-08-14 2022-02-17 He Li Communication method, apparatus, and system
WO2022052087A1 (en) * 2020-09-14 2022-03-17 Qualcomm Incorporated Sidelink reliability enhancements
ES2942038T3 (es) * 2020-09-21 2023-05-29 Asustek Comp Inc Procedimiento y aparato para admitir la comunicación de la retransmisión de UE a red en un sistema de comunicación inalámbrica
US11432354B2 (en) 2020-09-21 2022-08-30 Asustek Computer Inc. Method and apparatus for supporting UE-to-network relay communication in a wireless communication system
CN116325845B (zh) * 2020-10-01 2025-08-08 华为技术有限公司 一种安全通信方法、装置及系统
CN112235734B (zh) * 2020-10-14 2022-04-08 大唐高鸿智联科技(重庆)有限公司 广播模式下的单播业务实现方法、装置及设备
KR20230107814A (ko) * 2020-11-25 2023-07-18 엘지전자 주식회사 사이드링크 통신에서 빠른 통신 연결 회복 방법 및 이를 위한 장치
CN116762470A (zh) * 2021-01-11 2023-09-15 华为技术有限公司 一种生成设备间通信的密钥的方法、系统和装置
US12317354B2 (en) * 2021-02-11 2025-05-27 Qualcomm Incorporated Link recovery between sidelink user equipments based at least in part on keep-alive messages
TW202236872A (zh) * 2021-03-10 2022-09-16 美商高通公司 車聯萬物（ｖ２ｘ）資訊的通訊方法和系統
US11716596B2 (en) 2021-03-10 2023-08-01 Qualcomm Incorporated Methods and systems for communication vehicle-to-everything (V2X) information
US12267895B2 (en) * 2021-07-02 2025-04-01 Mediatek Singapore Pte. Ltd. Security mechanism for connection establishment over multi-hop sidelinks
EP4546838A4 (en) * 2022-06-27 2025-08-20 Beijing Xiaomi Mobile Software Co Ltd Key generation method and apparatus, communication device, and storage medium
KR20240057379A (ko) * 2022-10-24 2024-05-02 성균관대학교산학협력단 5G 차량 대 사물 통신 상에서 동작하는 IPv6 네트워크를 위한 기본적 지원을 제공하는 장치 및 방법
CN117998361A (zh) * 2022-11-07 2024-05-07 华为技术有限公司 通信方法、通信装置、及存储介质
CN116830623A (zh) * 2023-02-10 2023-09-29 北京小米移动软件有限公司 侧链路通信方法及装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105981433B (zh) * 2014-02-10 2019-09-10 Lg电子株式会社 无线通信系统中指示d2d数据的qos的方法和装置
US10079822B2 (en) * 2014-06-30 2018-09-18 Intel IP Corporation Techniques for securely receiving critical communication content associated with a critical communication service
EP3585128A1 (en) * 2014-11-10 2019-12-25 Lg Electronics Inc. Device for indicating a ciphering indication
US9699154B2 (en) * 2015-01-19 2017-07-04 Intel IP Corporation Systems, methods and devices for direct communication using a PC5 protocol
US10051470B2 (en) * 2015-03-23 2018-08-14 Qualcomm Incorporated Schedule selection and connection setup between devices participating in a NAN data link
GB2538802A (en) * 2015-05-29 2016-11-30 Nordic Semiconductor Asa Wireless communication
EP3125643B1 (en) * 2015-07-31 2019-04-03 Panasonic Intellectual Property Corporation of America Improved scheduling mechanism for prose relays serving remote ues
WO2017048095A1 (ko) * 2015-09-16 2017-03-23 엘지전자 주식회사 무선 통신 시스템에서 단말의 사이드링크 동작 방법 및 상기 방법을 이용하는 단말
EP3148285B1 (en) * 2015-09-25 2019-04-17 Panasonic Intellectual Property Corporation of America Improved radio bearer mapping for proximity services ue to network relay with associated priority signalling
US10439682B2 (en) * 2016-08-19 2019-10-08 FG Innovation Company Limited Access mechanism for proximity-based service UE-to-network relay service
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
US10939288B2 (en) * 2018-01-14 2021-03-02 Qualcomm Incorporated Cellular unicast link establishment for vehicle-to-vehicle (V2V) communication
US10880895B2 (en) * 2018-05-27 2020-12-29 Brian Gordaychik Variable length downlink control information formats for next generation radio technologies

Also Published As

Publication number Publication date
US11457355B2 (en) 2022-09-27
KR102303882B1 (ko) 2021-09-23
US20200221298A1 (en) 2020-07-09
CN111417092B (zh) 2023-03-24
KR20200085651A (ko) 2020-07-15
EP3678450A1 (en) 2020-07-08
CN111417092A (zh) 2020-07-14
EP3678450B1 (en) 2021-05-26

Similar Documents

Publication Publication Date Title
US11457355B2 (en) Method and apparatus for supporting vehicle-to-everything (V2X) services on single one-to-one sidelink communication link in a wireless communication system
ES2942038T3 (es) Procedimiento y aparato para admitir la comunicación de la retransmisión de UE a red en un sistema de comunicación inalámbrica
ES2940896T3 (es) Procedimiento y aparato para admitir la comunicación de la retransmisión de UE a red en un sistema de comunicación inalámbrico
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
KR102755302B1 (ko) 무선 통신 시스템에서 ue-대-ue 릴레이 통신을 수행하기 위한 사이드링크 무선 베어러를 설정하기 위한 방법 및 장치
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
US20230007455A1 (en) Method and apparatus for receiving pc5 signaling (pc5-s) messages in a wireless communication system
ES2903227T3 (es) Procedimientos y aparatos para gestionar un cambio de identificador de enlace lateral en un sistema de comunicación inalámbrica
US10419994B2 (en) Non-access stratum based access method and terminal supporting the same
ES2914606T3 (es) Procedimiento y aparato para realizar un procedimiento para actualizar identidades de capa 2
ES3056562T3 (en) Method and apparatus for performing link identifier update procedure in a wireless communication system
US10595254B2 (en) Non-access stratum based access method and terminal supporting the same
US20230007447A1 (en) Method and apparatus for transmitting pc5-s messages in a wireless communication system
US12225553B2 (en) Method and apparatus for supporting unicast link establishment for sidelink positioning in a wireless communication system
US20230389094A1 (en) Method and apparatus for realizing local id allocation for ue-to-ue relay communication in a wireless communication system
KR102963827B1 (ko) 무선 통신 시스템에서 ue-대-ue 릴레이에서 네트워크 보조 보안 설정을 지원하기 위한 방법 및 장치
CN117858002A (zh) 支持单播链路建立以用于侧链路定位的方法和用户设备
HK40051830A (en) Method and apparatus for sidelink signaling radio bearer (srb) establishment in a wireless communication system
HK40051830B (zh) 无线通信系统中侧链路信令无线电承载建立的方法和设备