CHINA Shenzhen Olax Technology CO.,Ltd Noticias de la empresa

NETCONF es el nombre completo del Protocolo de Configuración de Red, que es un protocolo de gestión de red que permite al NMS (Sistema de Gestión de Red) emitir, modificar y eliminar la configuración de los dispositivos de red conectados (enrutadores, eNodeB, gNodeB, DU, CU o RU). NETCONF está desarrollado y estandarizado por IETF; mientras que para O-RAN, está bajo la responsabilidad del WG (Grupo de Trabajo 4).   1. El protocolo NETCONF utiliza la codificación de datos XML (Lenguaje de Marcado Extensible) para procesar datos de configuración y mensajes de protocolo; se basa en el concepto de servidor y cliente y utiliza el mecanismo RPC (Llamada a Procedimiento Remoto) para lograr la comunicación entre el servidor y el cliente. El proceso cliente se ejecuta en el NMS, que puede ser un script o una aplicación, y el servidor es un dispositivo de red típico.   2. Las características de NETCONF son las siguientes: Adopta un marco de protocolo en capas, lo que lo hace más adecuado para redes bajo demanda, automatizadas y basadas en la nube. Se utiliza para emitir, modificar y eliminar configuraciones en dispositivos de red. XML (Lenguaje de Marcado Extensible) se utiliza para la codificación de datos de configuración y mensajes de protocolo. Basado en el concepto de servidor y cliente, el NMS actúa como cliente y el dispositivo de red actúa como servidor. La comunicación entre servidores y clientes se logra utilizando el mecanismo RPC (Llamada a Procedimiento Remoto). Las operaciones se ejecutan en función del modelo YANG, lo que reduce las fallas de la red causadas por errores de configuración manual. NETCONF satisface las necesidades de la automatización de la red. Proporciona mecanismos de seguridad como autenticación y autorización para garantizar la transmisión segura de mensajes. También proporciona mecanismos de transacción, que admiten la clasificación, el almacenamiento y la migración de datos, la confirmación por fases y el aislamiento de la configuración. Admite la entrega, verificación y reversión de configuraciones integrales, minimizando el impacto en los servicios de red. Permite a los proveedores definir sus propias operaciones de protocolo para implementar capacidades de gestión únicas.     3. ¿Por qué se necesita NETCONF? Un requisito clave de las redes en la nube es la automatización de la red para el aprovisionamiento rápido y bajo demanda de servicios y la gestión automatizada de operaciones. Los enfoques tradicionales como CLI y SNMP no pueden satisfacer este requisito. Tienen las siguientes limitaciones, que NETCONF aborda.     3.1. Desventajas de CLI: Primero, la configuración es compleja. Segundo, lo siguiente: Las CLI varían según el proveedor, lo que requiere que los usuarios aprendan y adapten los scripts CLI para cada proveedor. La estructura y la sintaxis de CLI cambian con frecuencia, lo que dificulta el mantenimiento de los scripts CLI. La salida de comandos no está estructurada, es impredecible y fácilmente modificable, lo que dificulta el análisis automático de los scripts CLI.     3.2 Desventajas de SNMP: SNMP no admite transacciones, lo que resulta en una configuración ineficiente. SNMP utiliza el Protocolo de Datagramas de Usuario (UDP), que no proporciona una transmisión de datos confiable y secuenciada y carece de mecanismos de seguridad efectivos. SNMP carece de un mecanismo para enviar transacciones de configuración. SNMP gestiona la configuración del dispositivo de forma individual y no admite la configuración a nivel de red ni la colaboración de configuración de múltiples dispositivos.

  En el sistema 5G, una Solicitud de Cambio de Ruta (PATH SWITCH REQUEST) es una solicitud para que el terminal (UE) establezca una conexión de señalización con el 5GC y, si corresponde, solicite que la bajada del portador de transporte NG-U se cambie a un nuevo nodo de servicio. Esta solicitud puede fallar por varias razones; 3GPP la define en TS 38.413 de la siguiente manera.   I. Fallo de la Operación de Solicitud de Ruta   Como se muestra en la Figura 8.4.4.3-1 a continuación, el fallo de una solicitud suele ser respondido por el AMF después de que el nodo NG-RAN emite una "PATH SWITCH REQUEST".       II. Los escenarios de fallo de la operación de solicitud son típicamente los siguientes:   Si el 5GC no logra cambiar el punto de terminación de bajada del portador de transporte NG-U al nuevo punto de terminación (de servicio) para todos los recursos de la sesión PDU, el AMF debe enviar un mensaje PATH SWITCH REQUEST FAILURE al nodo NG-RAN.   El nodo NG-RAN debe liberar los flujos QoS correspondientes y considerar las Sesiones PDU indicadas en el IE Lista de Liberación de Recursos de Sesión PDU contenido en el mensaje PATH SWITCH REQUEST FAILURE como liberadas.   El valor de causa correspondiente para cada Sesión PDU liberada está contenido en el IE Transferencia Fallida de Solicitud de Cambio de Ruta en el mensaje PATH SWITCH REQUEST FAILURE.   III. Operaciones Anormales de Solicitud   Si el AMF recibe un mensaje que contiene múltiples IE ID de Sesión PDU configurados con el mismo valor (en el IE Recurso de Sesión PDU a Cambiar en la lista de bajada), el AMF debe enviar un mensaje PATH SWITCH REQUEST FAILURE al nodo NG-RAN. Además,   Como excepción, el AMF puede generar un IE Transferencia Fallida de Solicitud de Cambio de Ruta.   Si se recibe un IE NSSAI Parcialmente Permitido en un mensaje PATH SWITCH REQUEST ACKNOWLEDGE, y el número total de S-NSSAIs contenidos en el NSSAI Permitido y el NSSAI Parcialmente Permitido excede 8, el nodo NG-RAN debe considerar que el procedimiento ha fallado.   Si algún S-NSSAI presente en el IE NSSAI Parcialmente Permitido también está presente en el IE NSSAI Permitido, el nodo NG-RAN debe considerar que el procedimiento ha fallado.

La Transferencia de Estado RAN es el proceso de transferir la información de estado de enlace ascendente y descendente de un terminal (UE) desde un nodo de red de acceso por radio (RAN) de origen a un nodo RAN de destino en una red 5G. Esto ocurre típicamente durante escenarios de handover o conectividad dual. Durante este proceso, el AMF transmite información sobre datos de enlace descendente (por ejemplo, el número de paquetes reenviados), junto con el estado SN y el número de secuencia y el número de hipermarco (HFN) del PDCP (Protocolo de Convergencia de Datos por Paquetes) para datos de enlace ascendente y descendente, al RAN de destino.   I. Transferencia de Estado RAN de Enlace Ascendenter tiene como objetivo habilitar handovers sin pérdida sobre NG-RAN. El proceso de transferencia utiliza señalización relacionada con el UE. El proceso específico se muestra en la Figura 8.4.6.2-1 a continuación, donde:   El nodo NG-RAN de origen inicia este proceso al dejar de asignar SN PDCP para SDUs de enlace descendente y enviar un mensaje UPLINK RAN STATUS TRANSFER al AMF cuando considera que el estado del transmisor/receptor está congelado. Para cada DRB para el cual la preservación del estado PDCP-SN y HFN es aplicable, el nodo NG-RAN de origen debe incluir el IE DRB ID, el IE UL COUNT y el IE DL COUNT en el IE DRB Subject Status Transfer List dentro del IE RAN Status Transfer Transparent Container del mensaje UPLINK RAN STATUS TRANSFER. Para cada DRB para el cual el nodo NG-RAN de origen ha aceptado una solicitud de reenvío de enlace ascendente del nodo NG-RAN de destino, el nodo NG-RAN de origen también puede incluir las SDUs de enlace ascendente faltantes y recibidas en el IE UL PDCP SDUs del mensaje UPLINK RAN STATUS TRANSFER.   II. Transferencia de Estado RAN de Enlace Descendente tiene como objetivo implementar procedimientos de transferencia de handover sin pérdida basados en NG-RAN utilizando señalización relacionada con el UE. El proceso específico se muestra en la Figura 8.4.7.2-1 a continuación, donde:     El AMF inicia este procedimiento enviando un mensaje DOWNLINK RAN STATUS TRANSFER al nodo NG-RAN de destino. El nodo NG-RAN de destino que realiza este handover de acuerdo con TS 38.300 y utilizando una configuración completa debe ignorar la información recibida en este mensaje. Para cada DRB en el IE RAN Status Transfer Transparent Container que está sujeto al IE State Transfer List, el nodo NG-RAN de destino no debe transmitir ningún paquete de datos de enlace ascendente con un PDCP-SN inferior al valor del IE UL Count Value. Para cada DRB en el IE RAN Status Transfer Transparent Container que está sujeto al IE State Transfer List, el nodo NG-RAN de destino debe usar el valor del IE DL COUNT Value del primer paquete de datos de enlace descendente al que aún no se le ha asignado un PDCP-SN. Si al menos un DRB en el IE RAN Status Transfer Transparent Container del mensaje DOWNLINK RAN STATUS TRANSFER contiene el estado de recepción del IE UL PDCP SDUs, el nodo NG-RAN de destino puede usarlo en los mensajes de informe de estado enviados al UE a través de la interfaz de radio.

  El propósito del proceso PATH SWITCH REQUEST es establecer una conexión de señalización relacionada con la UE con el 5GC y, si corresponde, solicitar que el punto de terminación de enlace descendente del portador de transporte NG-U se cambie a un nuevo punto de terminación. 3GPP define los procesos relevantes de 5G en TS38.413 después de habilitar las tecnologías IAB, slicing, posicionamiento y ranging de la siguiente manera:   I. Procesamiento de autorización IAB   Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE contiene el IE de Autorización IAB, el nodo NG-RAN (si es compatible) almacenará la información de autorización IAB recibida en el contexto de la UE y la utilizará como se especifica en TS 38.401.   Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE contiene el IE de Autorización IAB móvil, el nodo NG-RAN (si es compatible) almacenará el estado de autorización IAB móvil recibido en el contexto de la UE del Mobile IAB-MT. Si el IE de Autorización IAB móvil del Mobile IAB-MT se establece en "No autorizado", el nodo NG-RAN (si es compatible) se asegurará de que el nodo IAB móvil no sirva a ninguna UE.   II. NSSAI y Ranging y Posicionamiento   Si el IE "NSSAI parcialmente permitido" se incluye en el mensaje Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE), el nodo NG-RAN (si es compatible) inferirá la porción de slice de red parcialmente permitida para la UE a partir de él, almacenará y reemplazará cualquier "NSSAI parcialmente permitido" recibido previamente, y lo utilizará como se especifica en TS 23.501.   Si el IE "Información del servicio de localización de ranging y sidetrack" se incluye en el mensaje Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE), el nodo NG-RAN (si es compatible) actualizará la información del servicio de localización de ranging y sidetrack de la UE en consecuencia. Si el IE "Autorización de posicionamiento de ranging y sidetrack" en el IE de Información del servicio de posicionamiento de ranging y sidetrack se establece en "No autorizado", el nodo NG-RAN (si es compatible) debe tomar medidas para garantizar que la UE ya no tenga acceso a los servicios de posicionamiento de ranging y sidetrack.   III. Procedimiento de informe de transición inactiva RRC   Si el IE de Solicitud de informe de transición inactiva RRC se incluye en el mensaje Path Switch Request Acknowledgement y se establece en "Informe de estado de conexión RRC único", y la UE está en el estado RRC_CONNECTED, el nodo NG-RAN (si es compatible) debe enviar un mensaje de Informe de transición inactiva RRC al AMF para informar el estado RRC de la UE.   Si el IE de Solicitud de informe de transición inactiva RRC se incluye en el mensaje PATH SWITCH REQUEST ACKNOWLEDGE y se establece en "Informe de estado de conexión RRC único", y la UE está en estado RRC_INACTIVE, el nodo NG-RAN (si es compatible) enviará un mensaje de Informe de transición inactiva RRC al AMF, y un mensaje posterior de Informe de transición inactiva RRC al cambiar el estado RRC a RRC_CONNECTED.   Si el IE de Solicitud de informe de transición inactiva RRC se incluye en el mensaje PATH SWITCH REQUEST ACKNOWLEDGE y se establece en "Informe de transición de estado posterior", el nodo NG-RAN (si es compatible) enviará un mensaje de INFORME DE TRANSICIÓN INACTIVA RRC al AMF para informar el estado RRC de la UE, y un mensaje posterior de INFORME DE TRANSICIÓN INACTIVA RRC para informar el estado RRC de la UE al entrar o salir la UE del estado RRC_INACTIVE.   IV. Procedimiento de notificación de recursos de sesión PDU   Si el IE de Transferencia de reconocimiento de solicitud de cambio de ruta del mensaje PATH SWITCH REQUEST ACKNOWLEDGE contiene parámetros relacionados con la QoS (por ejemplo, IE de Presupuesto de retardo de paquete CN de enlace descendente o IE de Presupuesto de retardo de paquete CN de enlace ascendente), pero el nodo NG-RAN no puede aceptar los parámetros con éxito, el nodo NG-RAN continuará utilizando los valores antiguos (si los hay) recibidos del nodo NG-RAN de origen. Si es compatible, el nodo NG-RAN notificará al AMF enviando un mensaje de NOTIFICACIÓN DE RECURSOS DE SESIÓN PDU.    

  El propósito del proceso de solicitud de ruta de transferencia es establecer la conexión de señalización relevante entre el terminal (UE) y el 5GC y, si corresponde, solicitar que el punto de terminación de enlace descendente del portador de transporte NG-U se cambie a un nuevo punto de terminación. Para la transferencia de servicios relacionados con el UE en la interfaz PC5 en Sildlink, 3GPP lo define en TS38.413 de la siguiente manera:   I. Procesamiento de QoS PC5 La solicitud de ruta en la transferencia de la interfaz PC5 en Sildlink se define de la siguiente manera:   Si el mensaje de Reconocimiento de Solicitud de Cambio de Ruta (PATH SWITCH REQUEST ACKNOWLEDGE) contiene el IE de parámetro de QoS PC5, el nodo NG-RAN deberá (si es compatible) usarlo como se define en TS 23.287. Si el mensaje de Reconocimiento de Solicitud de Cambio de Ruta (PATH SWITCH REQUEST ACKNOWLEDGE) contiene el IE de parámetro de QoS A2X PC5, el nodo NG-RAN deberá (si es compatible) usarlo como se define en TS 23.256. Si el mensaje de Reconocimiento de Solicitud de Cambio de Ruta incluye el IE de Lista de Conjuntos de Parámetros de QoS Alternativos, el nodo NG-RAN deberá (si es compatible) usarlo como se especifica en TS 23.502. II. Solicitud de ruta en modo CE-B y CIoT de plano de usuario La transferencia se define de la siguiente manera:   Si el mensaje de Reconocimiento de Solicitud de Cambio de Ruta incluye el IE de Restricción de Modo CE-B, el IE de Restricción de Cobertura Mejorada no está configurado en "restringido", y la información de Restricción de Cobertura Mejorada almacenada en el contexto del UE no está configurada en "restringido", el nodo NG-RAN deberá (si es compatible) almacenar esta información en el contexto del UE y usarla como se define en TS 23.501. Si el mensaje de Reconocimiento de Solicitud de Cambio de Ruta incluye el IE de Indicador de Soporte CIoT de Plano de Usuario del UE, el nodo NG-RAN deberá (si es compatible) almacenar esta información en el contexto del UE y asumir que el UE es compatible con la Optimización 5GS de CIoT de Plano de Usuario como se especifica en TS 23.501. Si el mensaje de Reconocimiento de Solicitud de Cambio de Ruta incluye el IE de ID de Capacidad de Radio del UE, el nodo NG-RAN deberá (si es compatible) usarlo como se especifica en TS 23.501 y TS 23.502. III. Actividad esperada del UE de la sesión PDU y solicitud de ruta en MDT La transferencia se define de la siguiente manera: Para cada sesión PDU, si el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA incluye el IE "Comportamiento de Actividad Esperada del UE de la Sesión PDU", el nodo NG-RAN deberá (si es compatible) procesar esta información como se especifica en TS 23.501. Si el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA incluye el IE "Lista PLMN MDT basada en la gestión", el nodo NG-RAN deberá almacenarlo en el contexto del UE y, si es compatible, usar esta lista para permitir la selección posterior del UE para MDT basada en la gestión como se define en TS 32.422. Si el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA incluye el IE "Lista de Modificación PLMN MDT basada en la gestión", el nodo NG-RAN (si es compatible) deberá usar esta lista para sobrescribir cualquier información de lista PLMN MDT basada en la gestión almacenada previamente en el contexto del UE y usar la información recibida para permitir la selección posterior del UE para MDT basada en la gestión como se define en TS 32.422. Si el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA incluye el IE de Información de Asistencia de Sincronización Temporal, el nodo NG-RAN (si es compatible) deberá almacenar esta información en el contexto del UE y usarla como se define en TS 23.501. IV. Solicitud de ruta en 5G ProSe La transferencia se define de la siguiente manera: Si el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA incluye el IE Autorizado 5G ProSe, el nodo NG-RAN (si es compatible) deberá actualizar su información de autorización ProSe para el UE en consecuencia. Si la Información de Autorización 5G ProSe (IE Autorizado 5G ProSe) contiene uno o más IE configurados en "No autorizado", el nodo NG-RAN (si es compatible) debe tomar medidas para garantizar que el UE ya no tenga acceso a los servicios 5G ProSe asociados. Si el IE de Parámetros de QoS PC5 5G ProSe se incluye en el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA, el nodo NG-RAN (si es compatible) debe usarlo como se define en TS 23.304. Si el IE de Información de Suscripción del UE Aéreo se incluye en el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA, el nodo NG-RAN (si es compatible) debe almacenar esta información o sobrescribir cualquier información almacenada previamente en el contexto del UE y usarla como se define en TS 38.300. Si el IE de Tasa de Bits Máxima Agregada PC5 del UE 5G ProSe se incluye en el mensaje de RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA, el nodo NG-RAN deberá (si es compatible) realizar las siguientes acciones: Reemplazar la Tasa de Bits Máxima Agregada PC5 del UE 5G ProSe proporcionada previamente (si está disponible en el contexto del UE) con el valor recibido; Usar el valor recibido para las comunicaciones de enlace lateral para el UE asociado en el modo de programación de red para el servicio 5G ProSe.

  1.Divisiones de corte de redEn la era 4G (LTE) tradicional, las redes de telecomunicaciones se han convertido en un entorno de trabajo en el que los usuarios pueden dividir una red en casos de uso independientes, cada uno adaptado para proporcionar servicios especializados.APN (número de registro)(Nombres de puntos de acceso) fueron la primera forma de corte de red en redes móviles, permitiendo a los operadores dividir sus redes en función de los requisitos de servicio.   2.Sección de red 5G, definidas por 3GPP, cuentan con instancias de red independientes con control independiente y procesamiento de plano de usuario.que solo se utiliza en 5G con arquitectura independiente (SA).   3.Elementos e identificadores de red: Las implementaciones de segmentación en 5G incluyen funciones de red como el equipo del usuario (UE), la red de acceso por radio de próxima generación (NG-RAN), las funciones de plano de control (por ejemplo, AMF, PCF, SMF),y las funciones del plano de usuario (e.g., UPF). Cada sección de red está identificada por unS-NSSAI(Slice Service Type), que incluye unaTipo de servicio de corte (SST)Los operadores de red pueden utilizar el sistema de distribución de datos estándar para indicar el servicio al que se aplica el segmento de red.TSSvalores tales como: 1 para la banda ancha móvil mejorada, 2 para comunicaciones de baja latencia de alta fiabilidad, 3 para el IoT masivo, 4 en el caso del vehículo a todo (V2X), 5 para comunicaciones de tipo máquina de alto rendimiento. También pueden utilizar valores SST definidos localmente y no estandarizados.   4.Soporte para la división de la red terminal: para terminales 5G (UE) SA (independientes) configurados con el USRP (UE Routing Policy),pueden seleccionar S-NSSAI para el corte de la red (servicios) en función de la aplicación deseada (dependiendo de los requisitos de calidad de servicio de la aplicación)Por ejemplo, el primer Galaxy S24 Ultra de Samsung equipado con el URSP permite la selección de rebanadas y la ejecución del servicio dentro del sistema 5G.   5.Soporte para el corte de la red del sistema:Asignación(Detección y control) está habilitado (una función dentro de los elementos de la red central 5G PCF (Función de control de políticas) y SMF (Función de gestión de sesiones)).AsignaciónSe utiliza para identificar aplicaciones o tráfico en el lado de la red, aplicar políticas como calidad de servicio, facturación o redirección e implementar la clasificación y priorización del tráfico en tiempo real.   6.Ejemplos de despliegue comercial de corte de red: Singapur Telecomunicaciones (Singtel) ha lanzadoSingtel 5G+, una innovación avanzada de "slicing de red" que ofrece un nuevo estándar de conectividad y una experiencia priorizada a través de tres características clave: Singtel 5G+: La única red que utiliza la banda de espectro de 700 MHz, ofreciendo una cobertura óptima en todo el país, incluso en interiores. Singtel 5G+ Mejorado: Cobertura más amplia y velocidades más rápidas, con velocidades consistentes de hasta 2x. Prioridad 5G+ de Singtel: canales de red prioritarios con velocidades 4 veces más rápidas, siempre priorizando los servicios y detectando los nuevos

3GPP define lo siguiente en TS 38.413 con respecto a la restricción de cobertura mejorada, el tiempo de conexión extendido, la autorización del servicio V2X y el procesamiento de la solicitud de ruta de transferencia para terminales de agregación de enlace lateral en el sistema 5G:   I. Restricción de cobertura mejorada y tiempo de conexión extendido   Si el mensaje Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) incluye el IE de restricción de cobertura mejorada, el nodo NG-RAN DEBERÍA (si es compatible) almacenar esta información en el contexto del UE y usarla como se define en TS 23.501.   Si el mensaje Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) incluye el IE de tiempo conectado extendido, el nodo NG-RAN DEBERÍA (si es compatible) usarlo como se define en TS 23.501.   Si el mensaje Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) incluye un IE de información de diferenciación del UE, el nodo NG-RAN (si es compatible) debe almacenar esta información en el contexto del UE para su uso posterior de acuerdo con TS 23.501.   II. Autorización del servicio NR V2X   Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE incluye un IE de autorización del servicio NR V2X, el nodo NG-RAN (si es compatible) debe actualizar su información de autorización del servicio NR V2X para el UE en consecuencia.   Si el IE de autorización del servicio NR V2X incluye uno o más IE configurados en "No autorizado", el nodo NG-RAN (si es compatible) debe tomar medidas para garantizar que el UE ya no tenga acceso a los servicios asociados.   Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE incluye un IE de autorización del servicio LTE V2X, el nodo NG-RAN (si es compatible) debe actualizar su información de autorización del servicio LTE V2X para el UE en consecuencia. Si el IE de autorización del servicio LTE V2X contiene uno o más IE configurados en "No autorizado", el nodo NG-RAN (si es compatible) debe tomar medidas para garantizar que el UE ya no tenga acceso a los servicios asociados.   Si el IE de autorización del servicio NR A2X contiene uno o más IE configurados en "No autorizado", el nodo NG-RAN (si es compatible) debe tomar medidas para garantizar que el UE ya no tenga acceso a los servicios asociados.   Si el mensaje Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) contiene un IE de autorización del servicio LTE A2X, el nodo NG-RAN (si es compatible) debe actualizar su información de autorización del servicio LTE A2X para el UE en consecuencia.   Si el IE de autorización del servicio LTE A2X contiene uno o más IE configurados en "No autorizado", el nodo NG-RAN (si es compatible) debe tomar medidas para garantizar que el UE ya no tenga acceso a los servicios asociados.   III. Procesamiento de enlace lateral y agregación   Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE contiene el IE de velocidad de bits máxima agregada de enlace lateral del UE NR, el nodo NG-RAN (si es compatible) debe realizar las siguientes operaciones: Reemplazar la velocidad de bits máxima agregada de enlace lateral del UE proporcionada anteriormente (si está disponible en el contexto del UE) con el valor recibido; Usar el valor recibido para las comunicaciones de enlace lateral con el UE asociado en el modo de programación de la red de servicio NR V2X.   Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE contiene el IE de velocidad de bits máxima agregada de enlace lateral del UE LTE, el nodo NG-RAN (si es compatible) debe realizar las siguientes operaciones: Reemplazar la velocidad de bits máxima agregada de enlace lateral del UE proporcionada anteriormente (si está disponible en el contexto del UE) con el valor recibido; Usar el valor recibido para las comunicaciones de enlace lateral con el UE asociado en el modo de programación de la red de servicio LTE V2X. Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE incluye el IE de velocidad de bits máxima agregada PC5 del UE NR A2X, el nodo NG-RAN (si es compatible) debe realizar las siguientes operaciones: Reemplazar la velocidad de bits máxima agregada PC5 del UE NR A2X proporcionada anteriormente (si está disponible en el contexto del UE) con el valor recibido; En el modo programado por la red, usar el valor recibido para las comunicaciones de enlace lateral del servicio NR A2X para el UE asociado. Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE incluye el IE de velocidad de bits máxima agregada PC5 del UE LTE A2X, el nodo NG-RAN (si es compatible) debe realizar las siguientes operaciones: Reemplazar la velocidad de bits máxima agregada PC5 del UE LTE A2X proporcionada anteriormente (si está disponible en el contexto del UE) con el valor recibido; En el modo programado por la red, usar el valor recibido para las comunicaciones de enlace lateral del servicio LTE A2X para el UE asociado.

  En un sistema 5G, una transferencia solicitud de ruta es una solicitud de un terminal (UE) para establecer una conexión de señalización relacionada con el UE con el 5GC y, si corresponde, solicitar que el punto de terminación de enlace descendente del portador de transporte NG-U se cambie a un nuevo punto de terminación. Como 5G admite un número creciente de tipos de servicio, el contenido de las solicitudes de ruta durante las transferencias será cada vez más complejo. 3GPP define esto en TS 38.413 de la siguiente manera.   I. Presupuesto de Retraso de Paquetes   Si el IE de Presupuesto de Retraso de Paquetes CN de Enlace Descendente se incluye en el IE de Transporte de Reconocimiento de Solicitud de Cambio de Ruta del mensaje de Reconocimiento de Solicitud de Cambio de Ruta (PATH SWITCH REQUEST ACKNOWLEDGE), el nodo NG-RAN DEBERÍA (si es compatible) reemplazar el Presupuesto de Retraso de Paquetes CN de Enlace Descendente proporcionado anteriormente (si lo hubiera) y usarlo como se especifica en TS 23.502.   Si el IE de Presupuesto de Retraso de Paquetes CN de Enlace Ascendente se incluye en el IE de Transporte de Reconocimiento de Solicitud de Cambio de Ruta del mensaje de Reconocimiento de Solicitud de Cambio de Ruta, el nodo NG-RAN deberá (si es compatible) reemplazar el Presupuesto de Retraso de Paquetes CN de Enlace Ascendente proporcionado anteriormente (si lo hubiera) y usarlo como se especifica en TS 23.502.   II. Manejo de Datos en Ráfaga   Si el IE de Tiempo de Llegada de Ráfaga de Enlace Descendente se incluye en el IE de Transporte de Reconocimiento de Solicitud de Cambio de Ruta del mensaje de Reconocimiento de Solicitud de Cambio de Ruta, el nodo NG-RAN deberá (si es compatible) reemplazar el valor proporcionado anteriormente (si lo hubiera) y usarlo como se especifica en TS 23.502.   III. Manejo de Información de Asistencia de Red Central e Inactiva RRC   Si la Información de Asistencia de Red Central del IE INACTIVO RRC se incluye en el mensaje de Confirmación de Solicitud de Cambio de Ruta, el nodo NG-RAN (si es compatible) almacenará esta información en el contexto del UE y la usará para las decisiones de estado RRC_INACTIVO y la configuración de RNA del UE y la paginación RAN (si la hubiera), como se describe en TS 38.300.   Si la Información de Asistencia de Red Central del IE INACTIVO RRC incluye el IE MICO All PLMN, el nodo NG-RAN (si es compatible) tratará el área de registro del UE como el PLMN completo e ignorará la lista TAI del IE Inactivo RRC.   Si la Información de Asistencia de Red Central del IE INACTIVO RRC incluye la Indicación de Causa de Paginación del IE de Servicio de Voz, el nodo NG-RAN (si es compatible) la almacenará y la usará como se especifica en TS 38.300.   Si la Información de Asistencia de Red Central del IE INACTIVO RRC incluye el IE de Información de Asistencia PEIPS, el nodo NG-RAN (si es compatible) la almacenará y la usará para subgrupos de paginación de UE en el estado RRC_INACTIVO, como se describe en TS 38.300.   Si el IE de Manejo de Comunicación MT CN se incluye en la Información de Asistencia de Red Central (IE INACTIVO RRC), el nodo NG-RAN deberá (si es compatible) almacenar este IE y posteriormente puede solicitar a la CN que realice el manejo de la comunicación MT, como se describe en TS 23.502, dependiendo de la implementación.   Si el IE de Ajuste de Parámetros RAN Asistido por CN se incluye en el mensaje de Reconocimiento de Solicitud de Cambio de Ruta (PATH SWITCH REQUEST ACKNOWLEDGE), el nodo NG-RAN puede usar este IE como se describe en TS 23.501.   Si el IE de Solicitud de Informe de Transición INACTIVO RRC se incluye en el mensaje de Reconocimiento de Solicitud de Cambio de Ruta (PATH SWITCH REQUEST ACKNOWLEDGE), el nodo NG-RAN deberá (si es compatible) almacenar esta información en el contexto del UE.   V. Procesamiento de EPS y SRVCC   Si el mensaje PATH SWITCH REQUEST ACKNOWLEDGE incluye el IE de Redirección para Voz EPS Fallback   , el nodo NG-RAN deberá (si es compatible) almacenar este IE y usarlo en decisiones posteriores de EPS fallback de voz como se especifica en TS 23.502.

En 5G, una solicitud de ruta es un mensaje de señalización enviado por la estación base de destino a la red central durante la transferencia para redirigir la ruta de la sesión del terminal (datos). TS 38.413 define lo siguiente:   I. Fallos en el establecimiento de la sesión PDU   Si falla el establecimiento de alguna sesión PDU, la lista de sesiones fallidas se incluirá dentro del “IE de transporte de fallo de establecimiento de solicitud de cambio de ruta” en el mensaje PATH SWITCH REQUEST. El AMF procesará esta información como se especifica en TS 23.502.   2. Información de seguridad del usuario y de la ruta   Para cada sesión PDU, si su "información de flujo de QoS DL redundante adicional IE para cada TNL" se incluye en el IE de transferencia PATH SWITCH REQUEST del mensaje Path Switch Request, entonces el SMF puede usar cada información de capa de transporte UP incluida como el punto de terminación de enlace descendente para los flujos de QoS asociados contenidos en esta sesión PDU, y estos flujos de QoS se dividen en diferentes túneles para la transmisión redundante. Para cada sesión PDU, si el IE de transferencia de Path Switch Request de su mensaje "Path Switch Request" contiene "IE de reutilización de información TNL NG-U DL redundante", entonces el SMF debe (si es compatible) tratar la dirección de la capa de transporte DL incluida como la dirección de la capa de transporte DL para la transferencia redundante. Como se describe en TS 23.501. Para cada sesión PDU, si el IE de transferencia de Path Switch Request de su mensaje "Path Switch Request" contiene el IE "ID de nodo RAN global del nodo NG-RAN auxiliar", el SMF debe (si es compatible) manejar esta información como se estipula en TS 23.501. Para cada sesión PDU contenida en el mensaje PATH SWITCH REQUEST, si el "IE de transmisión de solicitud de cambio de ruta" contiene el "IE de índice de conjunto de parámetros de QoS actual", el SMF debe tratarlo como el conjunto de parámetros de QoS actualmente implementado entre los parámetros de QoS alternativos del flujo de QoS involucrado. El nodo NG-RAN debe (si es compatible) informar el IE del indicador de procesamiento basado en el conjunto PDU en el "IE de transmisión PATH SWITCH REQUEST" en el mensaje Path Switch Request. Si el "IE de transferencia PATH SWITCH REQUEST" en el mensaje Path Switch Request contiene un IE de indicador de procesamiento basado en el conjunto PDU, el SMF debe (si es compatible) manejar esta información como se estipula en TS 23.501. Si el "IE de transporte PATH SWITCH REQUEST" en el mensaje Path Switch Request contiene el IE del indicador de soporte MBS, entonces el SMF debe (si es compatible) manejar esta información como se estipula en TS 23.247. Si es compatible, el nodo NG-RAN debe informar la transmisión PATH SWITCH REQUEST de la etiqueta ECN en IE o el IE de estado de informe de información de congestión en el mensaje Path Switch Request. Si la etiqueta ECN o el IE de estado de informe de información de congestión se incluye en el IE de transporte PATH SWITCH REQUEST del mensaje Path switch Request, el SMF debe (si es compatible) usarlo para inferir si la etiqueta ECN en NG-RAN, la etiqueta ECN en UPF o el informe de información de congestión está activo. Como se describe en TS 23.501.   3. Procesamiento de datos ascendentes   Si el IE de transferencia PATH SWITCH REQUEST ACKNOWLEDGE del mensaje Path Switch Request Acknowledge contiene el IE de información UL NG-U UP TNL, entonces el nodo NG-RAN debe almacenar esta información y usarla como el punto de terminación de enlace ascendente para los datos del plano de usuario de esta sesión PDU. Si el IE de transferencia PATH SWITCH REQUEST ACKNOWLEDGE del mensaje Path Switch Request Acknowledge contiene el IE de información adicional NG-U UP TNL, entonces el nodo NG-RAN debe almacenar esta información y usar el IE de información UL NG-U UP TNL contenido en ella como el punto de terminación de enlace ascendente para los datos del plano de usuario de esta sesión PDU (divididos en diferentes túneles). Si el IE de transmisión PATH SWITCH REQUEST ACKNOWLEDGE del mensaje de confirmación de solicitud de cambio de ruta contiene el IE de información TNL UP NG-U UL redundante, el nodo NG-RAN debe (si es compatible) almacenar esta información. Y usarla como el punto de terminación de enlace ascendente de los datos del plano de usuario para la transmisión redundante de esta sesión PDU, como se describe en TS 23.501. Si el IE de transmisión PATH SWITCH REQUEST ACKNOWLEDGE del mensaje de confirmación de solicitud de cambio de ruta contiene el IE de información TNL UP NG-U UL redundante adicional, el nodo NG-RAN debe (si es compatible) almacenar esta información. Y usar el IE de información UL NG-U UP TNL incluido como el punto de terminación de enlace ascendente para los datos del plano de usuario divididos en diferentes túneles de esta sesión PDU

Similar a los sistemas 4G (LTE) de la generación anterior,La petición de conmutación de ruta es un mensaje de señalización enviado por la estación base de destino a la red central durante la transferencia para redirigir la ruta de datos (de usuario) de la sesión (de datos de paquete) del terminal.. Este mensaje inicia un proceso en el que la unidad de gestión de sesión instruye al plano de usuario para cambiar el punto final de datos de enlace descendente del sitio antiguo (fuente) al nuevo sitio,garantizar el flujo ininterrumpido de datos a la nueva ubicación del usuario.   I. Solicitud de cambio de ruta En 5G, el proceso de solicitud de ruta establece una conexión de señalización relacionada con el terminal (UE) con el 5GC y, en su caso,solicitudes de cambio del punto terminal de enlace descendente del portador de transporte NG-U a un nuevo punto terminalEste proceso utiliza la señalización relacionada con la UE.   II. Proceso de solicitud de ruta Tal como se muestra en la figura 8.4.4.2-1 a continuación, la “PATH SWITCH REQUEST” es iniciada por el nodo NG-RAN de destino hacia la AMF. Su definición específica es la siguiente: El nodo NG-RAN inicia el proceso enviando un mensaje de solicitud de conmutación de ruta (PATH SWITCH REQUEST) a la AMF.la FMM transferirá de forma transparente el IE de transferencia de petición de interruptor de ruta al SMF asociado a cada sesión de PDU indicada en el IE de identificación de sesión de PDU..Al recibir el mensaje PATH SWITCH REQUEST, el FM deberá desactivar el procesamiento de comunicación MT activado, tal como se describe en el TS 23.502.   III. Procesamiento del mensaje de solicitud de ruta Si el mensaje PATH SWITCH REQUEST contiene un RRC Resume Cause IE,la FMM la utilizará (si se admite) de conformidad con las disposiciones de optimización CIoT 5GS del plano de usuario para los nodos NG-RAN que actúan como ng-eNB especificados en el TS 23..502. Si el mensaje PATH SWITCH REQUEST contiene un indicador RedCap IE o eRedCap IE, la FMM tratará (si se admite) la UE como una UE RedCap o eRedCap UE previamente servidas por una celda E-UTRA,En el caso de los vehículos de la categoría II, se utilizará el número de vehículos de la categoría III.501Después de que todas las actualizaciones necesarias (incluyendo el cambio de ruta de enlace ascendente) se completen con éxito en el 5GC,la FMM enviará al nodo NG-RAN un mensaje de confirmación de la solicitud de cambio de ruta para al menos un recurso de sesión de PDU incluido en la solicitud de cambio de ruta.El proceso termina entonces.   IV. Manejo de la sesión de la PDU Para un IAB-MT o un IAB-MT móvil en el que el ID de sesión de la PDU IE en el mensaje PATH SWITCH REQUEST indique un identificador de sesión de la PDU no asignado (según se define en el TS 24.007),la AMF considerará (si se admite) que el IAB-MT o el IAB-MT móvil carecen de sesión PDU y procederá según lo especificado en el TS 23.501. Posteriormente, el nodo NG-RAN deberá (si se admite) ignorar la lista de conmutación de recursos de sesión de PDU IE en el mensaje de reconocimiento de solicitud de conmutación de ruta.Para cada sesión de PDU en la que la petición de transferencia de IE del interruptor de ruta dentro del mensaje de petición de interruptor de ruta contenga un flujo adicional de DL QoS por IE de información TNL, La SMF puede utilizar cada información de capa de transporte de enlace ascendente incluida como punto de terminación de enlace descendente para los flujos QoS asociados divididos en diferentes túneles para esta sesión PDU.