Un smartphone puede mostrar ya el icono 5G y, aun así, las páginas web seguir sin cargarse. Cuando ocurre, la primera reacción suele ser revisar el procedimiento de registro: ¿se completó 5G-AKA?, ¿se recibió Registration Accept?, ¿expiró T3512? Después de comprobar todo ello, el procedimiento de Registration puede parecer totalmente normal mientras el servicio de datos continúa sin funcionar.
En muchos casos, el problema no está en Registration, sino en la PDU Session. Registration responde a la pregunta «¿puede el UE registrarse en el 5GS?». PDU Session Establishment responde a la siguiente: «¿puede el UE acceder realmente a una red de datos?». Este artículo recorre el procedimiento de establecimiento de sesión PDU de principio a fin: cómo solicita el UE una sesión, cómo selecciona el AMF un SMF, cómo obtiene el SMF la información de suscripción y de políticas, cómo se configura el UPF y cómo se completa finalmente el túnel N3.
Después de que el UE complete el 5GS Registration, el AMF ya dispone de la identidad del usuario, la movilidad, la seguridad y el contexto de suscripción relacionado. Sin embargo, que el registro termine correctamente no significa que ya exista una ruta de plano de usuario. El UE puede seguir sin tener una ruta activa hacia Internet o hacia una red de datos empresarial.
PDU Session Establishment es el proceso que lleva al UE del estado «registrado» al estado «capaz de transportar tráfico de aplicaciones». El UE solicita una sesión, la red selecciona el SMF y el UPF, recupera los datos de suscripción asociados al DNN y al S-NSSAI, obtiene la política de sesión, instala reglas PFCP en el UPF y se coordina con el gNB para establecer el túnel N3. Al final del procedimiento, el UE dispone de una dirección IP, reglas de QoS y una ruta de plano de usuario hacia la Data Network.
El procedimiento se entiende mejor si no se considera como un único mensaje NAS aislado. Se están produciendo simultáneamente tres cosas: gestión de sesión, control de políticas y configuración de recursos del plano de usuario. Finalmente convergen en una PDU Session utilizable.
Límite funcional entre la sesión PDU y el registro 5GS
En 5GC, la división entre Registration y PDU Session es clara: uno establece el registro en la red y la otra establece la conectividad de datos.
Registration determina si el UE puede entrar en el 5GS. El AMF verifica la identidad del UE, realiza la autenticación, establece la seguridad NAS, recupera datos de suscripción relacionados con la movilidad y crea el contexto necesario para RM (Registration Management) y CM (Connection Management). Una vez completados estos pasos, queda establecida la relación de gestión entre el UE y la red central.
Una PDU Session está asociada al servicio de datos real. Si el UE necesita acceso a Internet, conectividad IMS o una red privada empresarial, Registration por sí solo no es suficiente. La red todavía debe determinar qué DNN se utiliza, qué S-NSSAI corresponde, qué SMF controla la sesión, qué UPF transporta el plano de usuario y qué parámetros de QoS y ancho de banda están autorizados.
Compararlo con EPC facilita recordar la diferencia. LTE utiliza los conceptos de PDN Connection y EPS Bearer. En 5GC, este modelo se sustituye por PDU Session + QoS Flow. Una vez establecida una PDU Session, la red crea reglas de QoS y recursos de QoS Flow, en lugar de un Default EPS Bearer al estilo LTE.
Otro punto importante es que una PDU Session no tiene que establecerse necesariamente al mismo tiempo que el Registration inicial. Un UE puede completar Registration y permanecer sin una PDU Session hasta que una aplicación requiera realmente servicio de datos. Por ejemplo, el dispositivo puede registrarse al encenderse, pero la PDU Session quizá no se cree hasta que el usuario abra una aplicación de vídeo media hora después.
Esta distinción es útil al analizar trazas. Si Registration se ha completado correctamente pero PDU Session Establishment no, revisar una y otra vez 5G-AKA, Registration Accept o T3512 normalmente no resolverá el problema del servicio de datos, porque la investigación está centrada en el procedimiento equivocado.
DNN, S-NSSAI y tipo de solicitud en la solicitud de sesión PDU
PDU Session Establishment comienza con un mensaje NAS enviado por el UE. Un PDU Session Establishment Request hace mucho más que decir simplemente a la red central «necesito acceso a datos». Los elementos de información transportados en la solicitud influyen en la selección posterior de NF y en la configuración de la sesión.
Una solicitud inicial típica puede incluir PDU Session ID, Request Type, PDU Session Type, SSC Mode, DNN y S-NSSAI.
PDU Session ID distingue varias sesiones pertenecientes al mismo UE. Un UE puede mantener varias PDU Sessions al mismo tiempo; por ejemplo, una para acceso a Internet y otra para una red privada empresarial. SUPI identifica al abonado, pero por sí solo no identifica qué PDU Session individual se está procesando en ese momento.
DNN identifica la Data Network a la que el UE quiere acceder. El acceso a Internet del operador, IMS y las redes empresariales pueden utilizar DNN diferentes. El DNN también interviene posteriormente en la selección del SMF, la selección del UPF y las decisiones de política.
S-NSSAI asocia la sesión con un segmento de red (Network Slice) concreto. El AMF y el SMF deben determinar si el segmento solicitado es coherente con la suscripción del usuario, el DNN solicitado y las capacidades desplegadas en la red.
Request Type identifica el contexto de la solicitud. Además de una nueva PDU Session, el procedimiento también puede estar relacionado con una sesión existente, cambios de acceso o escenarios de servicio de emergencia. Durante el análisis de trazas, la presencia de un PDU Session Establishment Request no debe interpretarse automáticamente como el mismo escenario en todos los casos.
El caso más habitual es un Initial Request: el UE ya ha completado Registration y ahora crea una nueva PDU Session para un DNN específico. La selección del SMF, la recuperación de suscripción desde UDM, el control de políticas de PCF y el establecimiento de recursos en el UPF se realizan a partir de este contexto de sesión.
Selección del SMF y creación del SM Context por el AMF
El mensaje NAS de gestión de sesión del UE llega primero al gNB y después se reenvía al AMF mediante NGAP junto con información relacionada con el acceso, como NR-CGI y TAI. El gNB no toma decisiones de control de la PDU Session; transporta la información NAS hacia la red central.
Tras recibir la solicitud, el AMF necesita identificar un SMF capaz de atender el S-NSSAI y el DNN solicitados.
En una arquitectura 5GC basada en servicios, el AMF puede utilizar el NRF para el descubrimiento de NF. Los criterios de descubrimiento pueden incluir el tipo de NF de destino, el servicio Nsmf_PDUSession requerido, S-NSSAI, DNN y el PLMN de servicio. El NRF devuelve instancias SMF candidatas y, a continuación, el AMF selecciona el SMF que prestará realmente el servicio según la política de red.
Después, el AMF invoca el servicio PDU Session del SMF para crear un SM Context. Además de SUPI, PDU Session ID, DNN y S-NSSAI, la solicitud transporta el PDU Session Establishment Request original del UE como información N1 SM.
A partir de este punto, el centro del control de la sesión pasa del AMF al SMF. El AMF continúa gestionando el acceso y la movilidad y sigue reenviando señalización N1 SM entre el UE y el SMF, pero el SMF es responsable de decidir cómo se crea la PDU Session, qué UPF se selecciona, qué políticas se aplican y cómo se configuran las reglas del plano de usuario.
Durante la resolución de problemas conviene tener presente un aspecto práctico: el número de transacciones NRF observado en una red comercial puede no coincidir exactamente con un diagrama de señalización de referencia. Los resultados del descubrimiento de NF pueden almacenarse en caché, puede utilizarse configuración estática o un SCP puede proporcionar el enrutamiento de servicios. La cuestión más importante no es si aparece una consulta NRF concreta en la traza, sino si el SMF seleccionado admite realmente el DNN, S-NSSAI y las capacidades de servicio requeridas.
Datos de suscripción UDM y procesamiento de la política de sesión PCF
Una vez que el SMF entiende qué tipo de sesión solicita el UE, todavía no puede crear inmediatamente el plano de usuario. Primero debe determinar qué tipo de PDU Session está realmente autorizado a establecer el abonado.
En un procedimiento típico, el SMF localiza el UDM apropiado, se registra como el SMF que atiende al SUPI y a la PDU Session, y recupera los Session Management Subscription Data asociados al S-NSSAI y al DNN solicitados.
Los datos de suscripción pueden contener el PDU Session Type permitido, SSC Mode, Session-AMBR y ajustes predeterminados relacionados con QoS. Estos valores definen los límites de la sesión a nivel de abonado. Por ejemplo, si el UE solicita una PDU Session IPv4, el SMF todavía debe verificar que el DNN permite ese PDU Session Type y que el SSC Mode solicitado está autorizado.
El SMF también puede suscribirse a cambios en los datos de suscripción SM. Si posteriormente se modifica en el UDM la suscripción de gestión de sesión correspondiente, el UDM puede notificar al SMF que presta servicio mediante el Callback URI registrado.
Si el despliegue utiliza Dynamic SM Policy Control, el SMF selecciona un PCF y establece una SM Policy Association. El SMF proporciona contexto como SUPI, PDU Session ID, DNN, S-NSSAI, ubicación del UE y parámetros de QoS suscritos. El PCF devuelve entonces la política de sesión autorizada, que puede incluir Session-AMBR, QoS predeterminado y otras reglas de política aplicables.
Esta etapa puede entenderse como una convergencia de los parámetros de sesión:
Solicitud de servicio del UE → límites de suscripción UDM → autorización de política PCF → el SMF finaliza los parámetros de control de sesión
Las reglas de QoS y de reenvío instaladas posteriormente en el UPF se basan en estos resultados.
Establecimiento de sesión N4 e instalación de reglas del plano de usuario en el UPF
Una vez determinados los parámetros de sesión, el SMF selecciona un UPF capaz de atender el DNN, S-NSSAI y la ubicación del UE solicitados, y después establece una PFCP Session sobre la interfaz N4.
PFCP Session Establishment Request es uno de los puntos más importantes del procedimiento PDU Session Establishment. Hasta esta etapa, la red ha trabajado principalmente con requisitos de servicio abstractos. En N4, esos requisitos se convierten en reglas que el UPF puede ejecutar sobre paquetes de usuario reales.
El SMF puede instalar reglas PDR, FAR, QER y URR en el UPF:
PDR: indica al UPF cómo identificar paquetes pertenecientes a la PDU Session o a un flujo de tráfico concreto;
FAR: define qué debe ocurrir con los paquetes coincidentes, como reenviarlos, descartarlos, almacenarlos en búfer u otra acción aplicable;
QER: aplica en el UPF el control de QoS requerido;
URR: define los requisitos de medición e informes de uso del plano de usuario.
Estas reglas no deben tratarse como cuatro funciones independientes. En conjunto definen cómo procesa el UPF el tráfico. El PDR identifica el flujo de paquetes y referencia los FAR, QER y URR aplicables para que el UPF sepa adónde deben ir los paquetes, qué controles de QoS se aplican y si es necesario medir el uso.
Cuando el UPF acepta el PFCP Session Establishment, devuelve su F-SEID y los parámetros de plano de usuario que ha creado. Uno de los resultados más importantes es la dirección de plano de usuario del lado UPF y el TEID utilizados para N3.
En ese momento, sin embargo, la ruta descendente puede no estar todavía completa porque el gNB aún no ha terminado de asignar sus recursos N3. Por ello, PDU Session Establishment no termina con una única solicitud PFCP. El procedimiento necesita todavía que la RAN complete su parte de la configuración del plano de usuario.
La señalización N1/N2 completa el túnel N3 y la configuración de QoS Flow
Una vez preparados los recursos del lado UPF, el SMF debe devolver dos conjuntos diferentes de información a través del AMF.
El primero es N1 SM information, que se entrega finalmente al UE. Contiene el PDU Session Establishment Accept junto con los parámetros que necesita el UE una vez establecida la sesión, como PDU Session Type, SSC Mode, DNN, S-NSSAI, dirección IP del UE, Session-AMBR y la QoS Rule predeterminada.
El segundo es N2 SM information, destinado al gNB. Indica a la RAN qué PDU Session se está creando, qué QoS Flows intervienen y qué dirección IP del UPF y TEID deben utilizarse en N3.
El AMF envía un PDU Session Resource Setup Request al gNB mediante NGAP. El gNB asigna los recursos de radio y N3 necesarios y reenvía al UE el PDU Session Establishment Accept.
Después de configurar los recursos, el gNB devuelve un PDU Session Resource Setup Response que contiene su propia dirección de plano de usuario N3 y TEID, junto con información sobre los QoS Flows que se establecieron correctamente.
Aquí existe un detalle temporal importante. Cuando el SMF estableció inicialmente la PFCP Session, ya conocía la información N3 del lado UPF, pero quizá todavía no conocía la información final del túnel del lado gNB. Una vez que el gNB devuelve su dirección N3 y el TEID, el AMF reenvía esa información al SMF. A continuación, el SMF utiliza PFCP Session Modification para actualizar el FAR correspondiente en el UPF, de modo que los paquetes descendentes puedan encapsularse en el túnel GTP-U correcto hacia el gNB.
En este punto, las rutas ascendente y descendente del plano de usuario quedan completas:
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
Por esta razón, recibir un PDU Session Establishment Accept no demuestra por sí solo que todos los elementos del plano de usuario sean correctos. Los parámetros del túnel N3, PFCP Session Modification y las reglas finales del UPF deben verificarse también frente al reenvío real de paquetes.
Resolución de problemas de señalización durante el establecimiento de la sesión PDU
PDU Session Establishment implica numerosas funciones de red. Intentar resolver el procedimiento comparando todos los mensajes desde el primer paquete puede volverse rápidamente confuso. Un método más eficiente consiste en dividir el procedimiento en varios puntos de comprobación y reducir paso a paso el dominio de fallo.
Verificar que la solicitud de sesión llega correctamente al AMF
Primero, confirme que el UE ha completado el 5GS Registration necesario. Después, inspeccione el PDU Session Establishment Request y compruebe que PDU Session ID, Request Type, DNN, S-NSSAI, PDU Session Type y SSC Mode sean apropiados. Si la solicitud ya contiene un parámetro no válido en el punto de entrada, ni un SMF ni un UPF en buen estado podrán producir la sesión prevista.
Verificar que el SMF crea un SM Context válido
A continuación, compruebe que el AMF selecciona un SMF apropiado y que Create SM Context se completa correctamente. El objetivo no es simplemente encontrar un mensaje NRF en la traza, sino confirmar que el SMF seleccionado admite el DNN, S-NSSAI y las capacidades de servicio requeridas.
Verifique después que los datos de suscripción SM devueltos por el UDM permiten la PDU Session solicitada y que la política PCF es coherente con la configuración de QoS esperada.
Verificar que los recursos UPF y N3 están completos
Si el plano de control ya ha devuelto PDU Session Establishment Accept pero el UE todavía no puede transmitir datos, la investigación debe bajar a N4 y N3.
Compruebe lo siguiente en este orden:
Si PFCP Session Establishment se completa correctamente y el UPF crea la sesión correspondiente;
Si PDR, FAR, QER y otras reglas son coherentes con la dirección de tráfico prevista;
Si el gNB devuelve correctamente su dirección IP de plano de usuario N3 y el TEID;
Si el SMF actualiza el UPF con la información del túnel gNB mediante PFCP Session Modification;
Si aparecen realmente en N3 paquetes GTP-U que utilizan el TEID esperado;
Si el UPF puede enviar y recibir correctamente tráfico hacia la Data Network de destino a través de N6.
Seguir esta secuencia ayuda a acotar el problema a NAS, SBI, N4, N3 o al reenvío de paquetes en el UPF, en lugar de tratar todo el 5GC como un único dominio de fallo indiferenciado.
Preguntas frecuentes
¿Por qué un UE puede completar el registro 5G y aun así no acceder a Internet?
Registration establece el contexto de acceso, identidad, seguridad y movilidad entre el UE y el 5GC. No crea automáticamente una ruta de datos de usuario. Antes de que el UE pueda acceder a Internet o a otra Data Network, todavía necesita una PDU Session para que el SMF pueda configurar los parámetros de sesión, los recursos del UPF y el plano de usuario N3.
¿Se establece siempre una PDU Session cuando se enciende el UE?
No. Una PDU Session puede establecerse en torno al momento de Registration, pero también puede iniciarse más tarde cuando el UE necesite realmente un servicio de datos. El 5GS permite que un UE permanezca registrado sin una PDU Session activa, por lo que la finalización de Registration y PDU Session Establishment no deben considerarse el mismo evento.
¿El éxito de PDU Session Establishment garantiza que el UE pueda acceder a Internet?
No. Un PDU Session Establishment Accept a nivel NAS por sí solo no demuestra una conectividad de datos correcta. El tráfico real de usuario también depende del túnel N3 entre el gNB y el UPF, de las reglas PDR/FAR/QER en el UPF, de la conexión N6 y de la Data Network de destino. Un UE puede recibir una dirección IP mientras el reenvío del plano de usuario sigue siendo incorrecto.
¿Por qué se produce PFCP Session Modification después de PFCP Session Establishment?
Cuando se crea la PFCP Session inicial en el UPF, es posible que el gNB aún no haya completado la asignación de recursos N3, por lo que el SMF todavía puede desconocer la dirección IP de plano de usuario y el TEID finales del gNB. Después de que el gNB devuelva estos valores en el PDU Session Resource Setup Response, el SMF actualiza las reglas correspondientes del UPF mediante PFCP Session Modification para que el tráfico descendente pueda enviarse por el túnel N3 GTP-U correcto.
¿QFI en una PDU Session y QER en la interfaz N4 son el mismo concepto?
No. QFI identifica un QoS Flow en el 5GS, mientras que QER es una QoS Enforcement Rule configurada por el SMF en el UPF a través de N4. Una QER participa en la aplicación de QoS y puede asociarse con un QFI cuando corresponda, pero QFI no es en sí mismo una QER y ambos conceptos no deben tratarse como intercambiables.
