Pruebas VoNR en campo 2026: cómo validar la calidad de voz en 5G Standalone

Un integrador RF baja por la Sheikh Zayed Road de Dubái en marzo de 2026. Acaba de validar el sitio en 5G SA, los contadores de gNB están limpios, el SIM está aprovisionado en el UDM. Hace una llamada de prueba VoNR. Funciona.

Mil metros más adelante, al cambiar de sector, la llamada cae a LTE. La siguiente, también. La siguiente, también.

Doce llamadas, doce fallback a EPS. Ningún drop de RF. Ningún reject visible en la pantalla del Android. Pero la red comercial de du, lanzada oficialmente en febrero de 2026 como primer despliegue VoNR comercial en EAU, no le mantiene la voz en NR. Algo, en algún lugar entre el AMF, el SMF y el IMS, está empujando esa llamada de vuelta al core 4G.

¿Cómo lo demuestras? ¿Con qué KPI lo cuantificas? ¿Y cómo lo aíslas con un terminal Android, sin un Keysight, sin un Anritsu, sin un core lab?

Esta guía responde eso. Es el protocolo de validación VoNR que un integrador puede ejecutar en campo en 2026.

VoNR ya no es un punto en la hoja de ruta: está en producción comercial en 2026

Durante cuatro años, VoNR fue una promesa que aparecía en cada roadmap de operador y desaparecía del deck del trimestre siguiente. En 2026 eso cambió.

Verizon y Ericsson anunciaron en el primer trimestre de 2026 el primer roaming VoNR a nivel nacional en Estados Unidos, con una arquitectura IMS interconectada que permite mantener la voz en NR cuando el abonado pasa de un visited network a otro sin caer al Circuit Switched Fallback ni al EPS Fallback. Es la primera vez que la industria valida la voz NR end-to-end fuera del operador home.

du, en Emiratos Árabes Unidos, lanzó en febrero de 2026 el primer servicio VoNR comercial del país, integrado con su núcleo 5G SA y disponible en terminales Android y iPhone compatibles. Bell Canada activó VoNR sobre iPhone en el área metropolitana de Toronto en agosto de 2025. T-Mobile US y Vodafone Alemania ya operan VoNR comercial en sus redes 5G SA.

Esto no es ya pilotaje en interiores. Es servicio facturable, en zonas urbanas densas, con tráfico real.

Y sin embargo, según el State of Play 5G SA de Opensignal de febrero de 2026, la disponibilidad SA global a finales de 2025 era de aproximadamente 17,6%. La GSA reporta 89 redes SA lanzadas comercialmente y 181 operadores invirtiendo en 73 países. La arquitectura está desplegada; la monetización de la voz va por detrás. Esa brecha es el espacio donde un integrador de campo aporta valor en 2026.

Si vas a validar voz en SA en 2026, no estás haciendo un POC. Estás auditando un servicio comercial que el cliente factura.

Qué cambia entre VoLTE y VoNR, y por qué tu método VoLTE ya no sirve

La trampa más común en 2026 es asumir que la voz NR es “VoLTE pero más rápida”. No lo es. La pila de transporte y la negociación de QoS cambian de raíz.

En VoLTE, el IMS viaja sobre una PDN connection LTE dedicada, transportada por un bearer dedicado QCI=1. La señalización SIP y el RTP atraviesan el SGW y el PGW. El códec por defecto, en la mayoría de las redes EU/MENA, es AMR-WB, con EVS opcional cuando el operador lo ha desplegado.

En VoNR, el IMS viaja sobre una sesión PDU 5GC, marcada con 5QI=1 y un QFI dedicado dentro del NSSAI elegido (típicamente la slice eMBB, aunque algunos operadores como du y Verizon ya están probando slices dedicadas para voz). La señalización SIP y el RTP atraviesan el UPF sobre las interfaces N3 (gNB→UPF) y N6 (UPF→IMS). El códec preferido es EVS Super-Wideband (EVS-SWB), con AMR-WB como fallback aceptable. La capa NAS deja de ser EMM/ESM y pasa a 5GMM/5GSM según TS 24.501.

Esto tiene una consecuencia operativa enorme: EPS Fallback (EPS-FB) y Full VoNR son dos servicios diferentes desde la perspectiva del KPI. Si tu red anuncia VoNR pero, en el momento de establecer la llamada, el AMF dispara un handover a EPS antes de que el IMS responda con un 200 OK, lo que estás midiendo no es VoNR: es VoLTE con un setup más lento. Mucho operador anuncia “VoNR” cuando tiene EPS-FB con SA idle camping.

La traza completa de una llamada VoNR pura cruza siete capas: RRC NR (establecimiento del signalling radio bearer) + NAS 5GMM (autenticación, contexto de movilidad) + NAS 5GSM (modificación de la sesión PDU para añadir el flujo 5QI=1) + SIP INVITE sobre el QFI de voz + RTP sobre N3→UPF→N6 + P-CSCF / I-CSCF / S-CSCF en el IMS + MGW si hay terminación a PSTN. Tu método de validación VoLTE solo cubría las cuatro primeras adaptadas a EPS. En NR tienes que reconstruir el pipeline desde cero.

Los 6 KPIs de campo que demuestran que una llamada VoNR funciona (o no)

3GPP TS 26.114 define el marco de telefonía multimedia IMS y los códecs (incluyendo EVS), y TS 23.501 especifica la tabla 5QI y la arquitectura del 5GC. Sobre esa base, en campo en 2026 trabajamos con seis KPIs. No son negociables.

KPI 1. Tiempo de establecimiento de llamada VoNR. Medido desde el SIP INVITE saliente hasta el 200 OK + ACK + primer paquete RTP. Objetivo: < 4 segundos. En VoLTE maduro estamos en torno a 2 segundos; el delta NR viene del establecimiento adicional de la sesión PDU si el UE no la tiene ya activa al momento del INVITE.

KPI 2. MOS POLQA según ITU-T P.863.2. En llamadas con códec EVS-SWB, el objetivo es MOS ≥ 4,0. En llamadas que negocian AMR-WB (porque el otro extremo no soporta EVS o el IMS hizo transcoding), el objetivo cae a MOS ≥ 3,5. Si tu MOS-POLQA es < 3,5 en EVS-SWB, tienes un problema de jitter, de pérdida de paquetes en el plano de usuario, o de clock drift en el UPF.

KPI 3. Latencia one-way del flujo 5QI=1. Desde que el RTP sale del UE hasta que llega al gateway IMS del lado terminado. Objetivo: < 100 ms. Si pasa de 150 ms en una red SA con UPF distribuido, sospecha backhaul mal dimensionado o un UPF centralizado en una región remota.

KPI 4. Tasa de EPS Fallback no intencional. En una zona SA madura con cobertura NR continua, el EPS-FB debería ser < 5% del total de intentos VoNR. Si tu cliente lanza VoNR comercial y mide 35% de fallback, no tiene VoNR: tiene VoLTE con un signalling tax extra.

KPI 5. Tasa de rechazo de Service Request. El UE pide reanudar la sesión PDU para enviar el SIP INVITE; el AMF responde con un Service Reject si el contexto está corrupto. Objetivo: < 1%. Por encima de 3% suele indicar mala sincronización entre AMF y UDM, o políticas SMF mal configuradas para la slice de voz.

KPI 6. Codec negociado. EVS-SWB o EVS-FB en el SDP de respuesta. Si ves AMR-WB sistemáticamente en una red que anuncia EVS, el IMS está haciendo transcoding o el P-CSCF está degradando deliberadamente la oferta. Eso es una fuga de calidad de voz que el operador no ve en sus contadores de core.

Con esos seis KPIs en una hoja, ya tienes el cuadro de mando que distingue VoNR comercial sano de VoNR cosmético. Si esto te recuerda al trabajo que ya hicimos para medición de calidad de voz en VoLTE, es porque la lógica QoE es la misma, pero la captura cambia.

Diagnosticar una llamada VoNR que falla: 4 causas raíz y cómo identificarlas en Android

Un Android rooteado con chipset Qualcomm (Snapdragon 8 Gen 2 o superior, con DIAG accesible) te permite capturar el log L3 en formato QMDL y decodificar las cuatro causas más frecuentes de una llamada VoNR rota. La señal que buscas es siempre NAS 5GMM/5GSM + SIP. La capa RRC NR ya te dice si hubo reconfiguration, pero la decisión de fallback o reject la toma el AMF o el IMS, no la radio.

A. EPS Fallback no intencional. En la traza ves un Registration Accept con la 5GS update result indicando “SMS only” o un Service Reject con la causa 5GS_services_not_allowed. Más sutil: el AMF acepta la sesión PDU pero, al recibir el SIP INVITE, dispara inmediatamente un handover command a E-UTRAN. El UE cae a LTE antes de cursar el primer paquete RTP NR. Si el operador anuncia VoNR pero esto pasa en > 30% de las llamadas, lo que tienes desplegado es EPS Fallback con SA camping, no VoNR completo.

B. SIP 488 Not Acceptable Here. Causa raíz: desajuste de códec entre UE e IMS-AS. El UE ofrece EVS-SWB en el SDP, el P-CSCF lo reenvía al IMS, y el IMS-AS responde 488 porque su perfil de servicio no contempla EVS-SWB para esta clase de abonado. Diagnóstico: capturar el SIP INVITE saliente y comparar el m=audio line del SDP con el m=audio del 488. Si el solapamiento de payload types es vacío, tienes una mala configuración del codec policy en IMS.

C. PDU session establishment reject (SMF). El UE pide una sesión PDU para el DNN “ims” o equivalente; el SMF rechaza con causa NAS 5GSM #26 (“Insufficient resources for specific slice”) o #67 (“Insufficient resources for specific slice and DNN”). Causa probable: el DNN ruteado al UPF correcto no tiene asignado el 5QI=1, o la slice de voz no está provisionada en el UDM para ese SUPI. Esto es la versión 5G del problema clásico que ya cubrimos en APN 4G a DNN 5G: qué cambia realmente, pero ahora con el SST/SD del NSSAI añadido como dimensión extra.

D. Beam mismatch en handover. En zonas mmWave o sub-6 con haces estrechos, la llamada VoNR cae al hacer Xn handover cuando el SS-RSRP del gNB destino es < −110 dBm. El UE tiene cobertura SS-SINR aceptable pero el haz de servicio del target no está bien orientado y el RTP empieza a perder paquetes durante la transición. La traza muestra RRC reconfiguration exitoso pero el RTCP reporta fraction lost > 5% durante 200-400 ms post-handover.

Si la causa que encuentras se parece a un Registration Reject en lugar de a un fallo de voz puro, vale la pena cruzarlo con el caso documentado en diagnóstico de Registration Reject 5G SA y códigos GMM cause, porque a veces el problema “VoNR” es en realidad un problema de attach mal aprovisionado.

Un protocolo VoNR de campo práctico (solo Android, sin equipo de laboratorio)

Lo que sigue es ejecutable en una jornada de campo de un solo ingeniero, con un Android rooteado y un SIM aprovisionado. Sin Keysight. Sin Anritsu. Sin core lab.

Setup. Smartphone Qualcomm rooteado, Snapdragon 8 Gen 2 como mínimo, con acceso DIAG habilitado. Forzar modo 5G SA desde el menú de ingeniería del fabricante o vía AT command. Verificar que el IMS está registrado (un PRACK limpio en la traza tras el SIP REGISTER). SIM aprovisionado con la slice de voz en el UDM y abonado activo en el HSS/UDM combo del operador.

Método. Cincuenta llamadas A→B en zona SA validada (cobertura NR continua, sin carrier aggregation anómalo) y cincuenta más en borde de cobertura (SS-RSRP entre −105 y −115 dBm, donde el riesgo de beam mismatch es alto). Para cada llamada, registrar simultáneamente el QMDL completo y el audio de referencia para análisis POLQA local con un sample de 8 segundos en cada extremo.

Medición. POLQA local sobre el audio capturado, con la referencia ITU-T P.863.2 para SWB. Decodificación L3 sobre el QMDL para extraer los timestamps del INVITE, 200 OK, primer RTP NR, y eventos de handover o fallback. La latencia 5QI=1 se calcula con marcas RTP RTCP-XR si el operador habilita los extension reports; si no, se aproxima por el RTT del propio RTCP.

Reporte. Una tabla por sitio. La fila mínima:

call_id	setup_time	MOS POLQA	fallback	causa raíz
SZR-001	3,2 s	4,1 (EVS-SWB)	N	OK
SZR-002	4,8 s	3,2 (AMR-WB)	Y	EPS-FB tras INVITE
SZR-003	3,5 s	4,0 (EVS-SWB)	N	OK
SZR-004	n/a	n/a	Y	SMF reject #67 (slice DNN)
SZR-005	3,9 s	3,7 (EVS-SWB)	N	RTCP loss 6% post-HO

Con cien filas como esas, el integrador entrega un informe que el ingeniero de core del operador puede accionar inmediatamente: cada causa raíz mapeada a un componente (AMF, SMF, P-CSCF, gNB), con KPI medido contra el objetivo de la sección 3.

Si quieres montar este flujo sobre nuestro toolchain, el VoLTE Checker ya soporta captura L3 sobre Android Qualcomm; el modo VoNR-aware está en roadmap para cubrir nativamente la decodificación 5GMM/5GSM y el SDP del IMS. Mientras tanto, puedes apoyarte en QoS y QoE en redes móviles y en la referencia de KPI drive test 5G 2026 para encajar VoNR en tu metodología existente.

En resumen

VoNR pasó de promesa a servicio comercial en 2026. Las redes que lo anuncian no son uniformes: muchas operan en realidad EPS Fallback con SA idle camping y lo facturan como VoNR. La diferencia se ve en seis KPIs medibles desde un Android rooteado, y se aísla con cuatro causas raíz que cualquier integrador puede identificar en una jornada de campo: fallback no intencional, codec mismatch, SMF reject por slice/DNN, y beam mismatch en handover.

El método VoLTE ya no sirve. La sesión PDU, el 5QI, el QFI y el NSSAI cambian la captura desde la primera trama RRC. Quien siga validando voz en SA con la checklist de 2022 va a firmar informes que no aguantan una segunda revisión.

¿Cuál es tu tasa de fallback VoNR actual en sitios comerciales? ¿Y cuántas de tus llamadas “VoNR” son en realidad VoLTE con un handover automático tras el INVITE?