El verdadero reto de un despliegue con varios PCF no es la mera existencia de múltiples instancias de PCF. El problema es que un mismo UE puede ser encaminado fácilmente a PCF distintos durante procedimientos de servicio diferentes. Durante el establecimiento de una sesión PDU, el SMF puede haber creado ya una asociación de políticas con un PCF. Más tarde, cuando se activa un servicio de voz IMS y el AF inicia una nueva solicitud de política, el balanceo de carga puede enviar esa solicitud a otro PCF. Cuando esto ocurre, se rompe el contexto de políticas entre ambas etapas, lo que puede provocar incoherencias en los flujos QoS de VoNR, las reglas PCC y las políticas de sesión.

BSF, o Binding Support Function, está diseñado específicamente para resolver este tipo de situación en la que las solicitudes del mismo usuario a través de interfaces distintas deben llegar al mismo PCF. No genera reglas PCC ni sustituye al PCF en la toma de decisiones de política. Su responsabilidad principal es mantener la relación de vinculación entre una sesión del UE y su PCF asociado, de modo que los consumidores de servicio puedan localizar el PCF que ya participó en el control de políticas de ese usuario cuando llegan solicitudes posteriores.

Por qué una red con varios PCF puede seleccionar el PCF equivocado

Para entender el valor del BSF conviene revisar un problema similar que ya existía en 4G. En la arquitectura EPC, el PGW se comunica con el PCRF mediante la interfaz Gx, mientras que el P-CSCF del dominio IMS envía solicitudes de autorización de políticas por la interfaz Rx. Cuando se despliegan varios PCRF, las rutas de señalización Gx y Rx deben terminar en el mismo PCRF. De lo contrario, las solicitudes posteriores del servicio IMS no pueden heredar el contexto de políticas creado previamente en la sesión.

En redes 4G, una solución habitual es utilizar un DRA para el encaminamiento Diameter y la vinculación de sesiones. Considérese un caso típico: cuando el PGW establece una conexión PDN para el APN de IMS, la solicitud Gx se encamina a través de DRA1 hacia PCRF1. DRA1 registra la relación entre el IMSI, la dirección IP del UE y PCRF1. Si un mensaje Rx posterior del P-CSCF se envía a DRA2 por efecto del balanceo de carga y DRA2 lo reenvía a PCRF2, PCRF2 no conoce el contexto de sesión establecido anteriormente en el lado del PGW.

El impacto es mucho más serio que seleccionar simplemente el servidor equivocado. PCRF2 no dispone del estado existente de las reglas PCC, por lo que las nuevas solicitudes de política de medios recibidas por Rx no pueden correlacionarse correctamente con las políticas establecidas previamente por Gx. En despliegues 4G, este problema puede resolverse sincronizando en tiempo real la información de vinculación entre varios DRA, pero estas implementaciones suelen ser específicas de cada fabricante, lo que complica considerablemente los despliegues multivendor y la operación a largo plazo.

En 5GC, la necesidad de coherencia de políticas sigue siendo la misma, aunque hayan cambiado las funciones de red y las interfaces. El SMF se comunica con el PCF por N7, mientras que el AF solicita autorización de políticas por N5. En un flujo completo de políticas VoNR, el AF proporciona primero los requisitos del flujo de aplicación y de QoS, el PCF genera las reglas PCC correspondientes y después el SMF y el UPF aplican esas reglas. Si solicitudes diferentes del mismo UE llegan a PCF distintos, la continuidad de las políticas puede volver a romperse.

El BSF estandariza en la práctica una capacidad de vinculación que antes dependía de mecanismos de sincronización propietarios. Mantiene la relación entre la sesión actual del UE y el PCF responsable, ayudando a garantizar que las solicitudes de política posteriores vuelvan a dirigirse a la instancia de PCF que ya participó en la sesión.

¿Qué información vincula el BSF?

Desde el punto de vista de implementación, el BSF puede verse como una tabla dinámica que relaciona el UE con la instancia propietaria de su política. Cuando un PCF participa en el control de políticas de una sesión PDU del UE, registra en el BSF la información de vinculación necesaria. Posteriormente, otras funciones de red pueden consultar el BSF mediante identificadores del UE y características de la sesión para recuperar la información de direccionamiento del PCF correspondiente.

Un registro de vinculación típico puede incluir la dirección IP del UE, SUPI, DNN, S-NSSAI y la dirección del PCF asociado. En despliegues que necesiten interoperar con interfaces Diameter tradicionales, el registro también puede incluir el nombre de host Diameter o el FQDN del PCF.

Estos campos no se recopilan simplemente para completar información. Cada uno cumple una función concreta para filtrar e identificar la vinculación correcta:

• UE IP: Permite localizar directamente la vinculación a partir de la dirección actual del plano de usuario y es uno de los parámetros de consulta más habituales.

• SUPI: Identifica al abonado a nivel de identidad de usuario y ayuda a garantizar que la vinculación corresponda al UE correcto.

• DNN: Distingue las distintas redes de datos utilizadas por un mismo UE, como IMS y los servicios normales de Internet.

• S-NSSAI: Identifica con mayor precisión el segmento de red asociado a la sesión en un despliegue 5G con slicing.

• Dirección del PCF: Proporciona la información de direccionamiento real que necesita un consumidor de servicio para llegar al PCF seleccionado.

• Nombre de host Diameter/FQDN: Proporciona una referencia de mapeo para el encaminamiento Diameter tradicional en despliegues donde coexisten SBI y Diameter.

Por este motivo, la vinculación del BSF no debe reducirse a un simple mapeo uno a uno entre una dirección UE y una dirección PCF. Un mismo UE puede tener varias sesiones PDU y acceder a diferentes DNN o segmentos de red. Si los criterios de consulta son demasiado amplios, el PCF devuelto puede no corresponder al contexto de servicio actual.

En el despliegue, la granularidad de la vinculación debe coincidir con la granularidad del control de políticas. Esto es especialmente importante en los servicios IMS, donde la continuidad de políticas es crítica. Si el UE tiene varios segmentos o varios contextos de red de datos, DNN y S-NSSAI no deben omitirse de los criterios de vinculación.

¿Cómo debe utilizarse Nbsf_Management?

El BSF expone el servicio Nbsf_Management sobre SBI. El servicio no se basa en una gran colección de API sin relación entre sí. En cambio, proporciona cuatro operaciones principales que cubren todo el ciclo de vida de un registro de vinculación: registro, descubrimiento, actualización y baja. En despliegues reales, estas cuatro operaciones se corresponden directamente con la creación, el uso, el mantenimiento y la eliminación de una vinculación de PCF.

Registro: crear primero la vinculación

Una vez seleccionado un PCF y cuando comienza a participar en el control de políticas del UE, debe registrar la vinculación en el BSF. Una solicitud típica es:

POST .../pcfBindings

El cuerpo de la solicitud puede incluir campos clave como la dirección IP del UE, SUPI, DNN, S-NSSAI, la dirección del PCF y el FQDN correspondiente. Cuando el BSF crea correctamente el registro de vinculación, devuelve:

201 Created

El momento de registro es uno de los errores de implementación más habituales en esta fase. La vinculación debe registrarse antes de que se inicie cualquier consulta posterior desde el lado del servicio. De lo contrario, cuando llegue a la red una solicitud del AF o una solicitud compatible con Diameter, el BSF puede no disponer todavía de la vinculación PCF correspondiente y la búsqueda puede fallar.

Descubrimiento: recuperar el PCF existente a partir del contexto de sesión

La operación Discovery es donde se aprecia con mayor claridad el valor práctico del BSF. Un consumidor de servicio envía una consulta utilizando la información del UE disponible en ese momento:

GET .../pcfBindings?query_parameters

Los parámetros de consulta pueden incluir la dirección IP del UE, SUPI o GPSI, DNN, S-NSSAI y otros identificadores relevantes. Si se encuentra una vinculación coincidente, el BSF devuelve:

200 OK

La respuesta incluye la dirección del PCF correspondiente y, cuando sea necesario, el nombre de host Diameter o el FQDN. En la arquitectura estandarizada, los consumidores de servicio pueden incluir funciones como NEF, AF y NWDAF. En despliegues que todavía deban admitir encaminamiento Rx tradicional, la información de vinculación devuelta también puede utilizarse para seleccionar el PCF correcto para la señalización posterior.

Actualizar y dar de baja: mantener el ciclo de vida de la vinculación

Si cambia la información de vinculación, un registro existente puede actualizarse mediante PATCH:

PATCH .../pcfBindings/{bindingId}

Una actualización correcta devuelve 200 OK. Cuando se libera la sesión, el PCF deja de atender al UE o la vinculación deja de ser válida, el registro debe eliminarse mediante:

DELETE .../pcfBindings/{bindingId}

Una eliminación correcta devuelve normalmente 204 No Content. En despliegues reales no debe ignorarse la baja. Si los registros de vinculación obsoletos permanecen demasiado tiempo en el BSF, el mismo abonado puede establecer más adelante una nueva sesión y coincidir por error con un PCF antiguo. Este tipo de problema suele ser más difícil de diagnosticar que una vinculación simplemente inexistente.

Cómo diagnosticar la vinculación N7 y Rx

A lo largo de toda la ruta de señalización, el flujo del BSF puede dividirse en tres etapas: primero registrar la vinculación, después consultarla y, por último, encaminar la señalización de política posterior de vuelta al PCF original. Una vez clara esta secuencia, diagnosticar problemas de política VoNR resulta mucho más eficiente que capturar grandes cantidades de señalización sin una dirección concreta.

Etapa uno: establecer la sesión PDU y registrar el PCF

Después de que una instancia BSF se ponga en servicio, registra primero sus capacidades y su información de direccionamiento en el NRF. A continuación, el UE establece una sesión PDU para el DNN de IMS y el SMF solicita control de políticas a un PCF. Una vez seleccionado el PCF, este invoca Nbsf_Management_Register para almacenar en el BSF la vinculación entre el UE y el PCF.

En ese momento, el BSF puede contener registros de vinculación similares a:

UE IP1 + DNN1 + S-NSSAI1 + SUPIxx → PCF1
UE IP2 + DNN2 + S-NSSAI2 + SUPIyy → PCF2

Etapa dos: una llamada VoNR activa una consulta de políticas

Cuando el UE inicia una llamada VoNR, el dominio IMS activa una nueva solicitud de autorización de políticas. En la arquitectura 5GC estandarizada, el AF y el PCF intercambian información de políticas por la interfaz N5. En algunos despliegues que siguen utilizando señalización Diameter tradicional de IMS, el P-CSCF puede continuar utilizando el procedimiento Rx/AAR.

La pregunta clave en esta fase es sencilla: ¿qué PCF debe recibir la solicitud de política?

El solicitante no debe limitarse a seleccionar otro PCF según la lógica normal de balanceo de carga. Primero consulta el BSF utilizando datos como la dirección del UE, DNN y S-NSSAI. El BSF hace coincidir el registro de vinculación existente y devuelve la instancia de PCF que ya es responsable de la sesión del UE.

Etapa tres: encaminar la señalización posterior de vuelta al PCF original

Una vez identificado el PCF correcto, las solicitudes de política posteriores se dirigen a ese mismo PCF. Así, el contexto de políticas creado durante el establecimiento de la sesión PDU y las nuevas solicitudes de política generadas durante la fase de medios VoNR permanecen en la misma instancia de control de políticas. El PCF puede entonces generar y mantener reglas PCC usando el contexto completo de la sesión.

Si puede iniciarse una llamada VoNR pero el comportamiento de la política QoS es anómalo, las reglas de medios IMS son incoherentes o solo algunos abonados sufren fallos intermitentes, conviene revisar la ruta de vinculación del BSF antes de atribuir inmediatamente el problema a la red de acceso radio.

Una secuencia práctica de diagnóstico puede dividirse en cuatro pasos. Primero, confirme que la operación BSF Register se ejecutó realmente después del establecimiento de la sesión PDU. Segundo, verifique que la dirección IP del UE, SUPI, DNN y S-NSSAI almacenados en el BSF sean correctos. Tercero, compruebe que las condiciones de consulta utilizadas en la solicitud Discovery posterior puedan identificar de forma única la vinculación original. Cuarto, verifique que la dirección PCF o el identificador Diameter devuelto coincidan exactamente con el PCF que participó inicialmente en el control de políticas N7.

También debe tenerse en cuenta la arquitectura de despliegue. En algunas redes, el BSF puede estar co-ubicado con el SMF. En ese caso, los puntos de captura de paquetes y los flujos de llamadas internos pueden diferir de los de un despliegue BSF independiente. Sin embargo, el principio fundamental no cambia: la red debe mantener una vinculación estable entre la sesión del UE y el PCF responsable.

Preguntas frecuentes

¿Realizan tanto el BSF como el NRF selección de funciones de red?

No. Sus funciones son diferentes. El NRF ayuda a las funciones de red a descubrir instancias NF disponibles y sus capacidades, por lo que actúa más como un registro de servicios. El BSF almacena una vinculación ya establecida entre una sesión UE concreta y un PCF. En términos sencillos, el NRF responde «¿Qué PCF están disponibles?», mientras que el BSF responde «¿Qué PCF ya es responsable de esta sesión UE?»

¿Puede un UE tener una sola vinculación PCF?

No necesariamente. Una vinculación no se define únicamente por la identidad del UE. También puede depender del DNN, S-NSSAI y del contexto concreto de la sesión PDU. Si el mismo UE accede a diferentes redes de datos o segmentos de red, puede ser necesario mantener las vinculaciones correspondientes por separado.

¿Pueden el BSF y el SMF desplegarse en la misma instancia de función de red?

Sí. Es posible un despliegue co-ubicado. En ese caso, la secuencia de señalización visible externamente puede diferir de la de un BSF independiente, pero la vinculación UE-PCF sigue teniendo que almacenarse y utilizarse. Por ello, durante el diagnóstico debe confirmarse primero la arquitectura real del fabricante.

¿Qué debe comprobarse primero cuando falla una consulta al BSF?

Empiece por tres puntos: si el registro de vinculación se creó correctamente, si los parámetros de consulta coinciden con los valores utilizados durante el registro y si la vinculación ha caducado o se eliminó prematuramente. Si el BSF devuelve un registro, compruebe también que la dirección PCF, el FQDN o el identificador Diameter devueltos apunten a la instancia PCF esperada.