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

Debido a la compleja configuración de los sistemas tradicionalesCLIyMNNEn la actualidad, la mayoría de los países miembros de la Unión Europea han adoptado una política de- ¿ Qué pasa?El protocolo de gestión de red está habilitado en el sistema 5G, lo que permiteEl NMS(sistema de gestión de red) para emitir, modificar y eliminar la configuración de los dispositivos de red conectados a los enrutadores, eNodeB, gNodeB, DU, CU o RU.La estructura y la sesión de servicio son las siguientes:;   - ¿ Qué?Principio de trabajo El sistema NETCONF contiene al menos unaEl NMSLa arquitectura NETCONF contiene dos roles: cliente y servidor     II. Las condiciones de trabajoCaracterísticas de la estructura del sistemaNETCONF contiene al menos un NMS que gestiona todos los dispositivos de red, incluidos:   2.1El cliente.proporciona las siguientes funciones:   Utilice NETCONF para gestionar los dispositivos de red. Enviar solicitudes RPC al servidor NETCONF para consultar o modificar uno o más valores de parámetros. Según las alarmas y eventos enviados por el servidor NETCONF del dispositivo administrado, entender el estado del dispositivo administrado. 2.2 Cuando elel servidor Cuando un dispositivo administrado experimenta un fallo u otro tipo de evento,el servidor NETCONF informa de la alarma o el evento al cliente mediante un mecanismo de notificación, lo que permite al cliente comprender el estado del dispositivo administrado.   III. El Consejo EuropeoSesión NETCONF: Como se muestra en la figura siguiente, el cliente y el servidor se comunican utilizando el mecanismo RPC. La comunicación solo está permitida después de que se establezca una sesión segura orientada a la conexión entre ellos.El cliente envía una solicitud RPC al servidorEl cliente NETCONF y el servidor se comunican utilizando el mecanismo RPC.La comunicación sólo se permite después de establecer una sesión segura orientada a la conexión.El proceso de establecimiento y terminación de la sesión es el siguiente:       El cliente establece una conexión SSH con el servidor y, después de completar la autenticación y autorización, establece una sesión NETCONF con el servidor. El intercambio de cliente y servidor¿ Qué pasa?mensajes para negociar capacidades. El cliente envía una o más solicitudes RPC al servidor. Modificar y comprometer la configuración; Datos o estado de la configuración de la consulta; Realizar operaciones de mantenimiento del dispositivo; El cliente termina la sesión NETCONF; La conexión SSH termina.

  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 (routers, 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).     I. 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.   II. 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 configuración completas, 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 métodos tradicionales como CLI y SNM no pueden satisfacer este requisito. Tienen las siguientes limitaciones, que NETCONF aborda.   31. 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. Los cambios frecuentes en la estructura y sintaxis de CLI dificultan 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.

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.