Network Slicing 5G y NIS2: asegurar las franjas de infraestructura crítica

Un hospital del norte de Europa despliega una franja 5G URLLC para cirugía asistida remotamente. La franja está configurada para latencia inferior a 10 ms con fiabilidad del 99,999 %. En el mismo gNB, una franja eMBB de consumo gestiona streaming de vídeo para miles de suscriptores. Un viernes por la noche, un concierto en el estadio adyacente satura la franja eMBB. La latencia en la franja quirúrgica sube a 200 ms. El cirujano reporta retardo. El paciente está estable, pero la confianza en el aislamiento de la franja se desmorona.

Nadie detectó la interferencia entre franjas hasta que un humano la percibió. Ninguna alarma se disparó. Ningún umbral KPI se superó en el OSS. El aislamiento existía en la configuración. No existía en el espectro radio.

Este es el problema exacto donde el network slicing 5G y NIS2 colisionan: ¿cómo demostrar que una red virtual dedicada a infraestructura crítica está realmente aislada en condiciones reales?

Qué es realmente el network slicing 5G

El network slicing está definido en la especificación 3GPP TS 23.501 (Arquitectura del Sistema 5G). Permite que una infraestructura física 5G SA (Standalone) única albergue múltiples redes virtuales lógicamente aisladas de extremo a extremo, cada una adaptada a una categoría de servicio específica.

Cada franja se identifica mediante un S-NSSAI (Single Network Slice Selection Assistance Information), compuesto por dos campos:

• SST (Slice/Service Type): un valor de 8 bits que identifica la categoría de servicio. Los valores estandarizados incluyen SST=1 (eMBB), SST=2 (URLLC), SST=3 (mMTC). Los valores definidos por el operador van de 128 a 255.
• SD (Slice Differentiator): un valor opcional de 24 bits que distingue franjas que comparten el mismo SST. Por ejemplo, dos franjas URLLC para clientes empresariales diferentes comparten SST=2 pero tienen valores SD distintos.

El proceso de selección de slice involucra al AMF (Access and Mobility Management Function), que recibe el S-NSSAI solicitado por el terminal durante el registro y lo dirige a la instancia de franja apropiada. El NSSF (Network Slice Selection Function) asiste al AMF cuando el AMF de servicio no puede proporcionar los S-NSSAI solicitados.

A nivel de red troncal, cada franja puede disponer de sus propias instancias SMF (Session Management Function), UPF (User Plane Function) y reglas de política vía PCF (Policy Control Function). A nivel RAN, el slicing depende del scheduler del gNB para asignar recursos radio por franja según los parámetros SLA configurados. Aquí es donde teoría y práctica divergen.

NIS2 y las obligaciones de infraestructura crítica

La Directiva NIS2 (Directiva 2022/2555 del Parlamento Europeo y del Consejo, adoptada en diciembre de 2022) reemplazó la Directiva NIS original y amplió significativamente el alcance y rigor de las obligaciones de ciberseguridad en la UE.

Los operadores de telecomunicaciones están clasificados como entidades esenciales bajo NIS2. Esta clasificación activa obligaciones vinculantes según el Artículo 21:

• Medidas de seguridad basadas en riesgos que cubren cadena de suministro, gestión de incidentes, continuidad de negocio y seguridad de red
• Notificación de incidentes en 24 horas (alerta temprana), 72 horas (notificación completa) y un mes (informe final) al CSIRT designado
• Seguridad de la cadena de suministro, incluyendo validación de componentes y servicios de terceros
• Responsabilidad del órgano de dirección: el consejo de administración de las entidades esenciales asume responsabilidad directa sobre la gestión de riesgos ciber

Para los operadores que despliegan network slicing 5G para sectores críticos (salud, energía, transporte, seguridad pública), NIS2 significa que el aislamiento de slice no es una funcionalidad de rendimiento. Es una obligación de seguridad. Si la franja URLLC de un hospital puede degradarse por tráfico de consumo, el operador ha incumplido las medidas de gestión de riesgos adecuadas según el Artículo 21.

La intersección con el network slicing es directa: si un operador promete una franja URLLC aislada a un cliente de infraestructura crítica, NIS2 exige que el aislamiento sea demostrable, no asumido. Un archivo de configuración mostrando la asignación S-NSSAI es necesario. La evidencia de que el aislamiento se mantiene bajo congestión, movilidad e interferencia es lo que buscarán los auditores NIS2.

Dónde falla el aislamiento de slice en la práctica

La arquitectura 3GPP para network slicing está bien definida a nivel de red troncal. Instancias dedicadas de SMF y UPF por franja proporcionan separación real del tráfico por encima de la interfaz N3. El problema está a nivel RAN, donde los recursos radio físicos son compartidos.

Compartición de recursos radio

Un gNB sirve múltiples franjas sobre el mismo espectro. El scheduler MAC es responsable de asignar PRBs (Physical Resource Blocks) a los terminales según el SLA de su franja. Pero la capacidad radio total es finita. Cuando la franja eMBB consume el 90 % de los PRBs disponibles durante un pico de tráfico, la franja URLLC puede no recibir el mínimo garantizado, dependiendo de la implementación del scheduler y la configuración RRM (Radio Resource Management) del operador.

La especificación 3GPP TS 28.541 define el modelo de gestión de subredes de slices. Los parámetros maxNumberOfUEs y resourceAllocationStrategy son configurables por franja. Pero la aplicación depende de la implementación del scheduler del fabricante, y no existe una metodología de prueba estandarizada para verificar el cumplimiento bajo carga.

Fallos en la aplicación de QoS

Cada sesión PDU dentro de una franja está asociada a flujos QoS, identificados por QFI (QoS Flow Identifier). El 5QI (5G QoS Identifier) corresponde a características estandarizadas: presupuesto de retardo de paquete, tasa de error de paquete y prioridad de planificación. El tráfico URLLC típicamente usa 5QI=82 (GBR crítico en retardo, presupuesto de 10 ms) o 5QI=83 (10 ms, mayor fiabilidad).

En la práctica, la cadena de aplicación de QoS tiene múltiples puntos de fallo: el UPF puede marcar correctamente los paquetes, pero el scheduler del gNB puede no respetar la prioridad bajo congestión. El RAN puede respetar la prioridad para el flujo GBR pero permitir que flujos no-GBR de la misma franja compitan con flujos GBR de otra franja.

Fuga de señalización entre franjas

Los mensajes RRC y NAS no son intrínsecamente conscientes de las franjas en su transporte. Un terminal registrado en múltiples franjas recibe mensajes RRC Reconfiguration que pueden referenciar recursos de distintas franjas. Si el gNB no segrega correctamente los reportes de medición y los parámetros de reselección de celda por franja, un terminal en una franja URLLC puede ser dirigido a mediciones optimizadas para una franja eMBB, degradando la latencia.

Requisitos por tipo de franja: lo que exigen los números

Cada tipo de franja tiene objetivos de rendimiento cuantificados que definen si la franja funciona según especificaciones. Estos objetivos provienen de 3GPP TS 22.261 (Requisitos de servicio para el sistema 5G) e ITU-R M.2410.

La diferencia entre el objetivo URLLC de 1 ms / 99,999 % y el objetivo eMBB de 4 ms / 99,9 % no es marginal. Son dos órdenes de magnitud de diferencia en fiabilidad. Demostrar que una franja URLLC cumple su objetivo coexistiendo con tráfico eMBB en el mismo gNB requiere mediciones bajo congestión, no solo en condiciones de reposo.

Metodología de validación en campo

Verificar el aislamiento de slice en campo requiere capturar y analizar la señalización Layer 3 a nivel del terminal. La siguiente metodología proporciona las evidencias que el cumplimiento de NIS2 exige.

Paso 1: Análisis del PDU Session Establishment

Cuando un terminal establece una sesión PDU, el mensaje NAS (PDU Session Establishment Accept, definido en 3GPP TS 24.501) contiene el S-NSSAI asignado por la red. Este puede diferir del S-NSSAI solicitado por el terminal si el NSSF de la red anula la selección.

Capture el mensaje Registration Accept y verifique que el Allowed NSSAI coincide con la configuración de slice esperada. Luego capture el PDU Session Establishment Accept y verifique el S-NSSAI asignado y las reglas QoS (incluyendo 5QI, ARP y valores GBR/MBR).

Paso 2: Verificación de flujos QoS bajo carga

Con una sesión PDU activa en la franja objetivo, genere tráfico que sature la franja eMBB en la misma celda. Monitorice la franja URLLC para detectar degradación de latencia, incremento de jitter y pérdida de paquetes. La señalización L3 revelará si el gNB envía mensajes RRC Reconfiguration que modifican los parámetros de scheduling del terminal URLLC en respuesta a la congestión eMBB.

Paso 3: Movilidad con continuidad de slice

Realice handovers (intra-frecuencia e inter-frecuencia) mientras el terminal está activo en una franja específica. Verifique que la celda destino mantiene la misma asignación S-NSSAI después del handover. El mensaje RRC Reconfiguration durante el handover debe portar la información de slice, y la modificación de sesión PDU subsiguiente (si la hay) debe preservar los parámetros QoS.

Paso 4: Detección de interferencia entre franjas

Utilice una configuración dual-SIM o multi-terminal para medir simultáneamente el rendimiento en dos franjas diferentes servidas por la misma celda. Correlacione los picos de latencia en la franja URLLC con las ráfagas de throughput en la franja eMBB. Las capturas L3 alineadas temporalmente de ambos terminales proporcionan la evidencia de si el aislamiento se mantiene o no.

La herramienta crítica para este flujo es un decodificador de protocolo L3 capaz de parsear mensajes NAS y RRC en tiempo real, directamente desde el chipset del terminal vía protocolo DIAG de Qualcomm. Esto proporciona visibilidad sobre la señalización realmente intercambiada entre el terminal y la red, no la vista abstracta presentada por los sistemas OSS de los fabricantes.

Para pruebas de red 5G a escala, las herramientas telecom basadas en smartphone capturan simultáneamente señalización L3 y KPIs RF (RSRP, RSRQ, SS-SINR por haz) durante drive tests, permitiendo la validación de slices en grandes áreas de cobertura sin hardware de scanner dedicado.

Conclusión

El network slicing 5G transforma una infraestructura física compartida en redes virtuales dedicadas a sectores críticos. La arquitectura es sólida. Las especificaciones son completas. Pero la configuración no es aislamiento, y la validación en laboratorio no es prueba de campo.

NIS2 ha cambiado el panorama del cumplimiento. Los operadores que sirven a entidades esenciales con redes 5G segmentadas deben ahora demostrar que el aislamiento de slice se mantiene en condiciones reales: congestión, movilidad, interferencia e integración multi-fabricante. Las obligaciones de gestión de riesgos del Artículo 21 se aplican directamente a los mecanismos de gestión de recursos radio y aplicación de QoS que determinan si una franja URLLC realmente entrega 1 ms de latencia y 99,999 % de fiabilidad cuando importa.

La evidencia proviene del campo. Los mensajes PDU Session Establishment, el análisis RRC Reconfiguration y la correlación de rendimiento entre franjas proporcionan los datos verificables que los auditores NIS2 requieren.

A medida que los despliegues 5G SA se multiplican y la infraestructura crítica depende cada vez más de la conectividad segmentada, una pregunta define la postura de cumplimiento del operador: ¿puede demostrar que sus slices están aisladas, o simplemente lo asume?