Sesiones de PDU soportadas por terminales 5G (NR) (continuación 1)

En 5G, unaSesión del PDUes una conexión lógica entre elUEy elDN(Internet o red empresarial), específicamente para la transmisión de datos (tráfico) y servicios de apoyo como la navegación o la voz (VoNR).

I. Delimitador del preámbulo de Ethernet y del inicio del marcono se enviará a través del 5GS, cuando:

• Para el tráfico de enlace ascendente, la UE eliminará el preámbulo y la secuencia de verificación de cuadros (FCS) del marco Ethernet.
• Para el tráfico de enlace descendente, el anclaje de sesión PDU eliminará el preámbulo y la secuencia de verificación de cuadros (FCS) del marco Ethernet.

II. Direcciones MAC e IP: El 5GC no asignará direcciones MAC o IP a la UE en la sesión PDU. El PSA debe almacenar la dirección MAC recibida de la UE y asociarla con la sesión PDU correspondiente.

III. SMF y VLAN:La SMF en el 5GC puede recibir una lista de etiquetas VLAN permitidas (hasta 16 etiquetas VLAN) desde el DN-AAA, o puede configurar los valores de etiquetas VLAN permitidas localmente.La SMF también puede configurar instrucciones de procesamiento VLAN (e.g., etiquetas LAN que se insertan o eliminan, etiquetas S-TAG que se insertan o eliminan).la SMF determina el método de procesamiento de VLAN para la sesión PDU e instruye a la UPF para que acepte o descarte el tráfico UE en función de las etiquetas VLAN permitidas, y procesar etiquetas VLAN a través de PDR (eliminación de encabezado externo) y FAR (creación de encabezado externo para la política de reenvío de aplicaciones UPF), por ejemplo:

• La UPF puede insertar (para el tráfico de enlace ascendente) y eliminar (para el tráfico de enlace descendente) S-TAG en el N6 o N19 o en la interfaz interna "5G VN Internal" para procesar el tráfico hacia y desde la UE.
• Cuando no hay VLAN en el tráfico hacia la UE, la UPF puede insertar (para el tráfico de enlace ascendente) y eliminar (para el tráfico de enlace descendente) etiquetas VLAN en la interfaz N6.
• Cuando la UPF procesa el tráfico de enlace ascendente o descendente desde la UE, la UPF puede descartar cualquier tráfico de la UE que no contenga ninguna etiqueta VLAN permitida.

IV. Dirección del tráfico (envío): En 5G, esto se puede utilizar para dirigir el tráfico a N6-LAN, y también para el reenvío de tráfico basado en N6 relacionado con los servicios 5GVN, como se describe en la sección 5.29.4Excepto en condiciones específicas relacionadas con el soporte de la sesión PDU a través de W-5GAN, tal como se define en TS 23.316 [84], la UPF no eliminará las etiquetas VLAN enviadas por la UE,ni insertará etiquetas VLAN para el tráfico enviado a la UE; donde:

• Las PDU que contengan etiquetas VLAN solo pueden intercambiarse dentro de la misma VLAN a través del anclaje de sesión de la PDU.
• La UE puede obtener la MTU de la carga útil del marco Ethernet que debe considerar de la SMF durante el establecimiento de la sesión PDU (véase la sección 5).6.10.4).

V. Modo de conexión: La UE puede conectarse a su LAN conectada en modo puente; por lo tanto, las direcciones MAC de origen y destino del enlace ascendente (UL) de diferentes tramas pueden ser diferentes dentro de la misma sesión PDU.Las direcciones MAC de destino del enlace descendente (DL) de diferentes marcos también pueden ser diferentes dentro de la misma sesión PDU.

VI. Asignación de IP y direcciones MAC:Las entidades de la LAN conectadas al 5GS pueden tener direcciones IP asignadas por el DN, pero la capa IP se considera una capa de aplicación y no forma parte de la sesión de Ethernet PDU.El 5GS no admite el uso de direcciones MAC o (si se aplican VLAN) combinaciones de las mismas en múltiples sesiones PDU para el mismo DNN S-NSSAI..

VII. Autenticación UE: En la versión de la especificación R18, solo se autentica la UE conectada al 5GS, no los dispositivos detrás de ella; además:

• La versión de la especificación R18 no garantiza una red Ethernet sin bucles. Los escenarios de implementación deben verificarse individualmente para garantizar que se eviten los bucles Ethernet.
• La versión de la especificación R18 no garantiza que Ethernet responda correctamente y rápidamente a los cambios de topología.Los escenarios de implementación deben verificarse individualmente para comprender cómo responden a los cambios de topología.