Главная сложность развертывания с несколькими PCF заключается не в самом наличии нескольких экземпляров PCF. Проблема в том, что один и тот же UE в разных сервисных процедурах легко может быть направлен к разным PCF. При установлении PDU-сессии SMF уже может создать ассоциацию политик с одним PCF. Позже, когда запускается голосовая услуга IMS и AF инициирует новый запрос политики, балансировка нагрузки может отправить этот запрос другому PCF. В результате контекст политик между двумя этапами разрывается, что может привести к несогласованности потоков QoS VoNR, правил PCC и политик сессии.

BSF, или Binding Support Function, специально предназначена для решения ситуаций, в которых запросы одного пользователя через разные интерфейсы должны попадать к одному и тому же PCF. BSF не формирует правила PCC и не заменяет PCF при принятии решений по политике. Ее основная задача — поддерживать привязку между сессией UE и связанным с ней PCF, чтобы при поступлении последующих запросов потребители сервиса могли найти PCF, который уже участвовал в управлении политиками этого пользователя.

Почему сеть с несколькими PCF может выбрать неправильный PCF

Чтобы понять ценность BSF, полезно вспомнить похожую проблему, существовавшую уже в 4G. В архитектуре EPC PGW взаимодействует с PCRF по интерфейсу Gx, а P-CSCF в домене IMS отправляет запросы авторизации политики по интерфейсу Rx. При развертывании нескольких PCRF сигнальные пути Gx и Rx в конечном итоге должны приходить к одному и тому же PCRF. Иначе последующие IMS-запросы не смогут использовать контекст политики, созданный ранее в рамках сессии.

В сетях 4G распространенным решением является DRA для маршрутизации Diameter и привязки сессий. Рассмотрим типичный пример: при установлении PGW PDN-соединения для IMS APN запрос Gx через DRA1 направляется к PCRF1. DRA1 сохраняет связь между IMSI, IP-адресом UE и PCRF1. Если последующее сообщение Rx от P-CSCF из-за балансировки нагрузки попадет в DRA2, а DRA2 пересылает запрос в PCRF2, то PCRF2 не знает контекст сессии, ранее созданный на стороне PGW.

Последствия гораздо серьезнее, чем просто выбор не того сервера. PCRF2 не располагает текущим состоянием правил PCC, поэтому новые запросы медиаполитики, поступившие по Rx, нельзя корректно связать с политиками, ранее сформированными по Gx. В 4G эту проблему можно решать синхронизацией информации о привязках в реальном времени между несколькими DRA, однако такие реализации часто зависят от конкретного производителя, что заметно усложняет мультивендорное развертывание и долгосрочную эксплуатацию.

В 5GC требование согласованности политик сохраняется, хотя сетевые функции и интерфейсы изменились. SMF взаимодействует с PCF по N7, а AF запрашивает авторизацию политики по N5. В полном процессе политики VoNR AF сначала передает требования к потоку приложения и QoS, PCF формирует соответствующие правила PCC, после чего SMF и UPF применяют эти правила. Если разные запросы одного UE попадают к разным PCF, непрерывность политики снова может быть нарушена.

BSF фактически стандартизирует механизм привязки, который раньше зависел от проприетарной синхронизации. Она хранит связь между текущей сессией UE и ответственным PCF и помогает гарантировать, что последующие запросы политики будут направлены обратно к экземпляру PCF, уже участвовавшему в этой сессии.

Какие данные связывает BSF?

С точки зрения реализации BSF можно рассматривать как динамически поддерживаемую таблицу соответствия между UE и владельцем его политики. Когда PCF начинает участвовать в управлении политикой PDU-сессии UE, он регистрирует в BSF необходимые данные привязки. Позже другие сетевые функции могут запросить BSF по идентификаторам UE и характеристикам сессии и получить адресную информацию соответствующего PCF.

Типичная запись привязки может содержать IP-адрес UE, SUPI, DNN, S-NSSAI и адрес связанного PCF. В развертываниях, где требуется взаимодействие с традиционными интерфейсами Diameter, запись также может содержать Diameter-имя хоста PCF или FQDN.

Эти поля собираются не просто для полноты. Каждое из них выполняет определенную роль при фильтрации и поиске правильной привязки:

• UE IP: Позволяет напрямую найти привязку по текущему адресу пользовательской плоскости и является одним из наиболее распространенных параметров запроса.

• SUPI: Идентифицирует абонента на уровне пользовательской идентичности и помогает убедиться, что привязка относится к правильному UE.

• DNN: Различает разные сети передачи данных, используемые одним UE, например IMS и обычный доступ в Интернет.

• S-NSSAI: Дополнительно определяет сетевой слайс, связанный с сессией, в развертывании 5G с сетевым слайсингом.

• Адрес PCF: Содержит фактическую адресную информацию, необходимую потребителю сервиса для доступа к выбранному PCF.

• Diameter Host Name/FQDN: Служит эталоном сопоставления для традиционной маршрутизации Diameter в развертываниях, где одновременно используются SBI и Diameter.

Поэтому привязку BSF нельзя сводить к простой схеме «один адрес UE — один адрес PCF». Один UE может иметь несколько PDU-сессий и использовать разные DNN или сетевые слайсы. Если условия поиска слишком широкие, возвращенный PCF может не соответствовать текущему сервисному контексту.

В развертывании детализация привязки должна соответствовать детализации управления политикой. Это особенно важно для IMS-сервисов, где критична непрерывность политики. Если у UE несколько слайсов или несколько контекстов сети передачи данных, DNN и S-NSSAI нельзя исключать из критериев привязки.

Как использовать Nbsf_Management?

BSF предоставляет сервис Nbsf_Management через SBI. Этот сервис не представляет собой большую коллекцию несвязанных API. Вместо этого он предлагает четыре основные операции, охватывающие весь жизненный цикл записи привязки: регистрацию, обнаружение, обновление и дерегистрацию. В реальном развертывании эти операции напрямую соответствуют созданию, использованию, обслуживанию и удалению привязки PCF.

Register: сначала создать привязку

После выбора PCF и начала его участия в управлении политикой UE он должен зарегистрировать привязку в BSF. Типичный запрос выглядит так:

POST .../pcfBindings

Тело запроса может содержать такие ключевые поля, как IP-адрес UE, SUPI, DNN, S-NSSAI, адрес PCF и соответствующий FQDN. После успешного создания записи привязки BSF возвращает:

201 Created

Временная последовательность — одна из наиболее частых ошибок реализации на этом этапе. Привязку необходимо зарегистрировать до того, как будет выполнен любой последующий запрос со стороны сервиса. Иначе к моменту поступления запроса со стороны AF или Diameter-совместимого запроса BSF может еще не содержать соответствующую привязку PCF, и поиск завершится неудачей.

Discovery: получить существующий PCF из контекста сессии

Практическая ценность BSF особенно хорошо проявляется в операции Discovery. Потребитель сервиса отправляет запрос, используя доступную на данный момент информацию об UE:

GET .../pcfBindings?query_parameters

Параметры запроса могут включать IP-адрес UE, SUPI или GPSI, DNN, S-NSSAI и другие релевантные идентификаторы. Если найдено совпадение, BSF возвращает:

200 OK

Ответ содержит адрес соответствующего PCF и, при необходимости, Diameter-имя хоста или FQDN. В стандартизованной архитектуре потребителями сервиса могут быть, например, NEF, AF и NWDAF. В развертываниях, где по-прежнему требуется поддержка традиционной маршрутизации Rx, возвращенная информация о привязке также может использоваться для выбора правильного PCF для последующей сигнализации.

Update и Deregister: поддерживать жизненный цикл привязки

Если информация о привязке изменилась, существующую запись можно обновить с помощью PATCH:

PATCH .../pcfBindings/{bindingId}

Успешное обновление возвращает 200 OK. Когда сессия освобождается, PCF перестает обслуживать UE или привязка становится недействительной, запись следует удалить с помощью:

DELETE .../pcfBindings/{bindingId}

Успешное удаление обычно возвращает 204 No Content. В реальных развертываниях дерегистрацию нельзя игнорировать. Если устаревшие записи привязки слишком долго остаются в BSF, тот же абонент при установлении новой сессии может ошибочно совпасть со старым PCF. Такие проблемы зачастую сложнее диагностировать, чем простое отсутствие привязки.

Как диагностировать привязку N7 и Rx

Если рассматривать весь сигнальный путь, процесс BSF можно разделить на три этапа: сначала зарегистрировать привязку, затем выполнить ее поиск и, наконец, направить последующую сигнализацию политик обратно к исходному PCF. Когда эта последовательность понятна, диагностика проблем политики VoNR становится намного эффективнее, чем бессистемный сбор больших объемов сигнализации.

Этап 1: установить PDU-сессию и зарегистрировать PCF

После запуска экземпляр BSF сначала регистрирует в NRF свои возможности и адресную информацию. Затем UE устанавливает PDU-сессию для IMS DNN, а SMF запрашивает управление политикой у PCF. После выбора PCF он вызывает Nbsf_Management_Register, чтобы сохранить в BSF привязку UE к PCF.

В этот момент BSF может содержать записи привязки следующего вида:

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

Этап 2: вызов VoNR запускает поиск привязанного PCF для политики

Когда UE инициирует вызов VoNR, домен IMS запускает новый запрос авторизации политики. В стандартизованной архитектуре 5GC AF и PCF обмениваются информацией о политике по интерфейсу N5. В некоторых развертываниях, где сохраняется традиционная IMS-сигнализация Diameter, P-CSCF по-прежнему может использовать процедуру Rx/AAR.

Ключевой вопрос на этом этапе прост: какой PCF должен получить запрос политики?

Запрашивающая сторона не должна просто выбирать другой PCF по обычной логике балансировки нагрузки. Сначала она обращается к BSF, используя, например, адрес UE, DNN и S-NSSAI. BSF сопоставляет существующую запись привязки и возвращает экземпляр PCF, который уже отвечает за эту UE-сессию.

Этап 3: направить последующую сигнализацию обратно к исходному PCF

После определения правильного PCF последующие запросы политики направляются к этому же PCF. Благодаря этому контекст политики, созданный при установлении PDU-сессии, и новые запросы политики, возникающие на медиастадии VoNR, остаются на одном и том же экземпляре управления политикой. PCF может формировать и поддерживать правила PCC с учетом полного контекста сессии.

Если вызов VoNR инициируется, но поведение QoS-политики аномально, правила IMS-медиа несогласованы или только у части абонентов возникают периодические сбои, перед тем как сразу связывать проблему с радиосетью, следует проверить путь привязки BSF.

Практическую диагностику можно разделить на четыре шага. Во-первых, убедиться, что после установления PDU-сессии действительно была выполнена операция BSF Register. Во-вторых, проверить корректность IP-адреса UE, SUPI, DNN и S-NSSAI, сохраненных в BSF. В-третьих, проверить, позволяют ли условия последующего запроса Discovery однозначно найти исходную привязку. В-четвертых, убедиться, что возвращенный адрес PCF или идентификатор Diameter точно совпадает с PCF, который изначально участвовал в управлении политикой по N7.

Необходимо учитывать и архитектуру развертывания. В некоторых сетях BSF может быть совмещена с SMF. В этом случае точки захвата пакетов и внутренние вызовы могут отличаться от автономного развертывания BSF. Однако основной принцип не меняется: сеть должна поддерживать стабильную привязку между UE-сессией и ответственным PCF.

Часто задаваемые вопросы

Выполняют ли BSF и NRF выбор сетевых функций?

Нет. Их роли различаются. NRF помогает сетевым функциям обнаруживать доступные экземпляры NF и их возможности и по сути выполняет роль реестра сервисов. BSF хранит уже установленную привязку между конкретной UE-сессией и PCF. Проще говоря, NRF отвечает на вопрос «Какие PCF доступны?», а BSF — «Какой PCF уже отвечает за эту UE-сессию?»

Может ли у UE быть только одна привязка PCF?

Не обязательно. Привязка определяется не только идентичностью UE. Она также может зависеть от DNN, S-NSSAI и конкретного контекста PDU-сессии. Если один и тот же UE использует разные сети передачи данных или сетевые слайсы, соответствующие привязки может потребоваться поддерживать отдельно.

Можно ли развернуть BSF и SMF в одном экземпляре сетевой функции?

Да. Совмещенное развертывание возможно. В этом случае видимая извне сигнальная последовательность может отличаться от автономного BSF, но привязку UE к PCF все равно необходимо хранить и использовать. Поэтому при диагностике следует сначала уточнить фактическую архитектуру конкретного производителя.

Что проверять в первую очередь, если запрос BSF завершается неудачей?

Начните с трех пунктов: была ли запись привязки успешно создана, совпадают ли параметры запроса со значениями, использованными при регистрации, и не истекла ли привязка или не была ли она преждевременно удалена. Если BSF возвращает запись, дополнительно убедитесь, что возвращенные адрес PCF, FQDN или идентификатор Diameter указывают на ожидаемый экземпляр PCF.