3 mensajes NAS bastan para obtener el retrato completo de una red 5G SA

Son las 10:06 de la manana. Estas en un sitio 5G SA recien desplegado en zona urbana densa. El terminal muestra “5G”. Las barras de senal estan al maximo. Pero, ha asignado realmente la red un slice eMBB? La voz pasara por VoNR o caera a VoLTE?

Nadie en el equipo puede responder a estas preguntas sin acceder a la senalizacion NAS.

Y eso es exactamente lo que revelan 3 mensajes NAS capturados en tiempo real.

Lo que el terminal no te dice

Cuando un UE se conecta a una red 5G Standalone, una serie de mensajes NAS (Non-Access Stratum) se intercambian entre el terminal y el nucleo de red a traves de la interfaz N1. Estos mensajes estan definidos en la especificacion 3GPP TS 24.501 y contienen informacion critica que la interfaz de usuario del telefono nunca muestra.

Un ingeniero de campo que se fia unicamente del icono “5G” y las barras de senal trabaja a ciegas. La capa NAS es el unico lugar donde se puede confirmar lo que la red ha decidido realmente para ese terminal.

Registration Accept: el veredicto de la red

El Registration Accept (tipo de mensaje 66, definido en 3GPP TS 24.501 seccion 8.2.7) es la respuesta de la red a la solicitud de registro del terminal. Es el mensaje con mas informacion sobre la relacion red-terminal.

Esto es lo que revela una captura en vivo:

Allowed NSSAI: el campo lista los slices que la red autoriza para este terminal. En nuestra captura, sst: 1 confirma la asignacion de un slice eMBB (enhanced Mobile Broadband), el perfil estandar definido en 3GPP TS 23.501 seccion 5.15.2.

imsVoPS3gpp: cuando este flag vale 1, la red indica que soporta servicios de voz IMS en este PLMN via acceso 3GPP. Esto significa que la voz puede ir por VoNR (Voice over New Radio) nativo, sin necesidad de caer a EPS Fallback hacia 4G.

TAC (Tracking Area Code): confirma la zona de seguimiento en la que el terminal esta registrado.

Sesiones activas: la lista de sesiones PDU ya establecidas (aqui sesiones 1 y 2).

Por que es critico: sin este mensaje, es imposible saber si la red realmente asigno el slice solicitado o si sustituyo uno por defecto. En un sitio multi-slice (eMBB + URLLC), esta verificacion es indispensable.

PDU Session Establishment Accept: la conexion de datos confirmada

El PDU Session Establishment Accept (tipo de mensaje 194, 3GPP TS 24.501 seccion 8.3.2) confirma los parametros de la sesion de datos entre terminal y red.

Campos clave capturados:

PDU Type = 2 (IPv6): la red asigno una direccion IPv6 para esta sesion. En 5G SA, IPv6 es el tipo por defecto recomendado por el 3GPP, a diferencia del dual-stack frecuente en 4G.

SSC Mode = 1: el modo de continuidad de sesion y servicio 1 (definido en 3GPP TS 23.501 seccion 5.6.9) garantiza que el ancla UPF permanezca igual durante toda la vida de la sesion. Es el modo mas comun, ofreciendo continuidad de direccion IP durante la movilidad.

QoS Rules: se crea automaticamente una regla QoS con ruleOpCode: 1 (Create new QoS rule) y un filtro de paquetes bidireccional (dir: 3). El flag dqr: yes confirma que es la Default QoS Rule, aplicada a todo el trafico que no corresponde a ningun filtro especifico.

DL NAS Transport: la segunda sesion revelada

El DL NAS Transport (tipo de mensaje 104, 3GPP TS 24.501 seccion 8.2.11) es un mensaje contenedor utilizado por el AMF para transportar mensajes SM (Session Management) hacia el terminal a traves de la capa MM (Mobility Management).

En nuestra captura, este mensaje encapsula un segundo PDU Session Establishment Accept (pduSessionId: 2, pti: 5, msgType: 194), revelando que una segunda sesion de datos se establece simultaneamente.

El campo ctnType: 1 indica que el contenido transportado es de tipo N1 SM information, es decir, un mensaje de gestion de sesion destinado al UE. Esta segunda sesion tambien es IPv6 con PDU type 2.

Por que 2 sesiones? En 5G SA, un terminal puede mantener multiples sesiones PDU simultaneas hacia diferentes DNN o el mismo DNN con parametros QoS distintos. Este es un cambio fundamental respecto al 4G donde los bearers estaban vinculados a un unico APN.

Lo que el analisis automatico revela

Al cruzar estos 3 mensajes, emerge una imagen coherente del contexto de red:

Este nivel de visibilidad estaba historicamente reservado a sondas de nucleo de red posicionadas en la interfaz N11 (entre AMF y SMF) o N4 (entre SMF y UPF). Poder leer esta misma informacion desde el terminal, en tiempo real, via la interfaz DIAG del chipset Qualcomm, es un cambio de paradigma para el diagnostico de campo.

Implicaciones para el drive test 5G SA

El acceso a la senalizacion NAS desde el terminal abre posibilidades concretas para los equipos de campo:

Verificacion de slice: confirmar que el slice solicitado (eMBB, URLLC, MIoT) es el realmente asignado por la red, y no un fallback a un slice por defecto.

Diagnostico VoNR: identificar si las llamadas de voz usan VoNR nativo o caen a EPS Fallback antes incluso de realizar la primera llamada.

Auditoria de sesiones: ver cuantas sesiones PDU estan activas simultaneamente, sus tipos IP y sus parametros QoS respectivos.

Validacion SSC: verificar que el modo de continuidad de sesion corresponde a la arquitectura desplegada (SSC 1 para movilidad clasica, SSC 2/3 para edge computing).

Todo esto sin desplegar una sonda, sin acceder al nucleo de red, y sin licencia de operador. Un unico terminal Android con acceso DIAG es suficiente.

Lo que esto cambia para los ingenieros de campo

La senalizacion NAS 5G ya no es un dominio reservado a los equipos de nucleo de red. Con las herramientas adecuadas de lectura DIAG, cada ingeniero de campo puede acceder al mismo nivel de informacion que una sonda de red, directamente desde el terminal que ya usa para sus mediciones.

La pregunta ya no es “muestra el sitio 5G?” sino “ha configurado realmente la red este sitio como estaba previsto?”

3 mensajes NAS bastan para responder.

Referencias: 3GPP TS 24.501 (protocolo NAS para 5GS), 3GPP TS 23.501 (arquitectura del sistema 5GS), 3GPP TS 23.502 (procedimientos 5GS)