複数PCF構成における本当の課題は、PCFインスタンスが複数存在すること自体ではありません。問題は、同じUEが異なるサービス手順の中で別々のPCFへ容易に振り分けられてしまうことです。PDUセッション確立時には、SMFがすでにあるPCFとポリシーアソシエーションを確立している場合があります。その後、IMS音声サービスが起動し、AFが新たなポリシー要求を送信すると、ロードバランシングによってその要求が別のPCFに送られることがあります。そうなると、2つの処理段階の間でポリシーコンテキストが分断され、VoNRのQoSフロー、PCCルール、セッションポリシーに不整合が生じる可能性があります。

BSF（Binding Support Function）は、同一ユーザーに関する異なるインターフェース経由の要求を同じPCFへ到達させる必要がある、この種の問題を解決するために設計されています。BSF自身はPCCルールを生成せず、ポリシー判断においてPCFの役割を代替することもありません。主な役割は、UEセッションとそのセッションを担当するPCFとのバインディング関係を維持し、後続要求が到着した際に、サービスコンシューマーがすでにそのユーザーのポリシー制御へ関与したPCFを特定できるようにすることです。

複数PCFネットワークで誤ったPCFが選択される理由

BSFの価値を理解するには、4Gですでに存在していた類似問題を振り返ると分かりやすくなります。EPCアーキテクチャでは、PGWはGxインターフェースを介してPCRFと通信し、IMSドメインのP-CSCFはRxインターフェースを介してポリシー認可要求を送信します。複数のPCRFが配備されている場合、GxとRxのシグナリングパスは最終的に同じPCRFへ到達する必要があります。そうでなければ、後続のIMSサービス要求は、セッションの前段で作成されたポリシーコンテキストを引き継ぐことができません。

4Gネットワークでは、DiameterルーティングとセッションバインディングにDRAを用いる方法が一般的です。典型例として、PGWがIMS APN向けのPDN接続を確立すると、Gx要求はDRA1を経由してPCRF1へルーティングされます。DRA1はIMSI、UE IPアドレス、PCRF1の関係を記録します。その後、P-CSCFからのRxメッセージがロードバランシングによってDRA2へ送られ、DRA2がその要求をPCRF2へ転送すると、PCRF2はPGW側で以前に確立されたセッションコンテキストを把握していません。

影響は、単に「誤ったサーバーを選択した」というだけでは済みません。PCRF2には既存のPCCルール状態がないため、Rxで受信した新しいメディアポリシー要求を、Gxで以前に確立されたポリシーと正しく関連付けることができません。4Gでは、複数DRA間でバインディング情報をリアルタイム同期することで対処できますが、この種の実装はベンダー独自であることが多く、マルチベンダー環境の導入や長期運用を大幅に複雑化します。

5GCでも、ネットワーク機能やインターフェースが変わっても、ポリシー整合性に対する要求は変わりません。SMFはN7でPCFと通信し、AFはN5でポリシー認可を要求します。完全なVoNRポリシーフローでは、AFがまずアプリケーションフローとQoS要件を提示し、PCFが対応するPCCルールを生成し、その後SMFとUPFがそれらのルールを適用します。同一UEの異なる要求が別々のPCFへ到達すると、ポリシーの継続性は依然として失われる可能性があります。

BSFは、以前は独自同期メカニズムに依存していたバインディング機能を実質的に標準化します。現在のUEセッションとその担当PCFとの関係を維持し、後続のポリシー要求が、そのセッションにすでに関与しているPCFインスタンスへ戻されるようにします。

BSFはどの情報をバインドするのか

実装の観点では、BSFはUEとポリシー担当先との対応を動的に維持するテーブルとして捉えることができます。PCFがUEのPDUセッションに対するポリシー制御へ関与すると、必要なバインディング情報をBSFへ登録します。その後、他のネットワーク機能はUE識別子やセッション特性を使ってBSFを照会し、対応するPCFのアドレス情報を取得できます。

代表的なバインディングレコードには、UE IPアドレス、SUPI、DNN、S-NSSAI、および関連PCFのアドレスを含めることができます。従来のDiameterインターフェースとの相互接続が必要な構成では、PCFのDiameterホスト名またはFQDNを含む場合もあります。

これらのフィールドは、単に情報を揃えるために集めるものではありません。それぞれに、正しいバインディングを絞り込み、識別するための役割があります。

• UE IP: 現在のユーザープレーンアドレスを基にバインディングを直接特定でき、最も一般的な照会パラメータの1つです。

• SUPI: ユーザー識別レベルで加入者を特定し、バインディングが正しいUEに紐付いていることを確認するのに役立ちます。

• DNN: 同じUEが使用する異なるデータネットワークを区別します。たとえばIMSと通常のインターネットサービスです。

• S-NSSAI: ネットワークスライシングを用いる5G構成で、そのセッションに関連するネットワークスライスをさらに特定します。

• PCFアドレス: サービスコンシューマーが選択されたPCFへ到達するために必要な実際のアドレス情報を提供します。

• Diameterホスト名/FQDN: SBIとDiameterが共存する構成で、従来のDiameterルーティングに必要なマッピング参照情報を提供します。

このため、BSFのバインディングを、UEアドレスとPCFアドレスの単純な1対1対応として扱うべきではありません。1台のUEが複数のPDUセッションを持ち、異なるDNNやネットワークスライスへアクセスする場合があります。照会条件が広すぎると、返されたPCFが現在のサービスコンテキストと一致しない可能性があります。

実際の配備では、バインディングの粒度をポリシー制御の粒度に合わせる必要があります。これは、ポリシー継続性が重要なIMSサービスで特に重要です。UEが複数のスライスや複数のデータネットワークコンテキストを持つ場合、DNNとS-NSSAIをバインディング条件から省略すべきではありません。

Nbsf_Managementはどのように使用するべきか

BSFはSBI上でNbsf_Managementサービスを公開します。このサービスは、互いに無関係な多数のAPIで構成されているわけではありません。バインディングレコードのライフサイクル全体をカバーする4つの中核操作、つまり登録、Discovery、更新、Deregisterを提供します。実運用では、これら4つの操作がPCFバインディングの作成、利用、保守、削除に直接対応します。

Register：まずバインディングを作成する

PCFが選択され、UEのポリシー制御へ関与し始めたら、そのバインディングをBSFへ登録する必要があります。代表的な要求は次のとおりです。

POST .../pcfBindings

要求ボディには、UE IPアドレス、SUPI、DNN、S-NSSAI、PCFアドレス、対応するFQDNなどの主要フィールドを含めることができます。BSFがバインディングレコードの作成に成功すると、次を返します。

201 Created

この段階で最も起こりやすい実装上の落とし穴の1つがタイミングです。後続のサービス側照会が開始される前に、バインディング登録を完了しておく必要があります。そうでないと、AF側要求やDiameter互換要求がネットワークへ到達した時点で、BSFに対応するPCFバインディングがまだ存在せず、検索が失敗する可能性があります。

Discovery：セッションコンテキストから既存PCFを取得する

BSFの実用価値が最も分かりやすく現れるのがDiscovery操作です。サービスコンシューマーは、その時点で利用可能なUE情報を使って照会を送信します。

GET .../pcfBindings?query_parameters

照会パラメータには、UE IPアドレス、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が返されます。実運用ではDeregisterを軽視してはいけません。古いバインディングレコードがBSFに長く残ると、同じ加入者が後から新しいセッションを確立した際に、古いPCFへ誤って一致する可能性があります。この種の問題は、単にバインディングが存在しない場合よりも調査が難しくなることがあります。

N7とRxのバインディングをトラブルシュートする方法

シグナリングパス全体で見ると、BSFの処理は3段階に分けられます。まずバインディングを登録し、次にバインディングを照会し、最後に後続のポリシーシグナリングを元のPCFへ戻します。この順序を明確に理解すれば、方向性なく大量のシグナリングを収集するより、VoNRポリシー問題の切り分けをはるかに効率的に行えます。

第1段階：PDUセッションを確立しPCFを登録する

BSFインスタンスが起動すると、まず自身の能力とアドレス情報をNRFへ登録します。続いてUEがIMS DNN向けのPDUセッションを確立し、SMFがPCFへポリシー制御を要求します。PCFが選択されると、そのPCFはNbsf_Management_Registerを呼び出し、UEとPCFのバインディングをBSFへ保存します。

この時点で、BSFには次のようなバインディングレコードが含まれる場合があります。

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

第2段階：VoNR通話がポリシー照会を発生させる

UEがVoNR通話を開始すると、IMSドメインは新しいポリシー認可要求を生成します。標準化された5GCアーキテクチャでは、AFとPCFがN5インターフェース経由でポリシー情報を交換します。一部の構成では従来のIMS Diameterシグナリングを継続しており、P-CSCFがRx/AAR手順を使用する場合もあります。

この段階の重要な問いは単純です。どのPCFがポリシー要求を受け取るべきでしょうか。

要求側は、通常のロードバランシングロジックだけで別のPCFを選択すべきではありません。まずUEアドレス、DNN、S-NSSAIなどの情報を使ってBSFを照会します。BSFは既存のバインディングレコードを照合し、そのUEセッションをすでに担当しているPCFインスタンスを返します。

第3段階：後続シグナリングを元のPCFへ戻す

正しいPCFが特定されたら、後続のポリシー要求は同じPCFへ送られます。これにより、PDUセッション確立時に作成されたポリシーコンテキストと、VoNRメディア段階で生成される新たなポリシー要求が、同一のポリシー制御インスタンス上に維持されます。PCFは完全なセッションコンテキストに基づいてPCCルールを生成・維持できます。

VoNR通話は開始できるもののQoSポリシー動作が異常である、IMSメディアルールに不整合がある、または一部加入者だけで断続的な障害が起きる場合、問題をすぐ無線ネットワークへ帰属させる前にBSFバインディング経路を確認するべきです。

実践的なトラブルシュートは4段階に分けられます。第1に、PDUセッション確立後にBSF Register操作が実際に行われたか確認します。第2に、BSFへ保存されたUE IPアドレス、SUPI、DNN、S-NSSAIが正しいか確認します。第3に、後続Discovery要求で使用する照会条件が元のバインディングを一意に特定できるか確認します。第4に、返されたPCFアドレスまたはDiameter識別子が、最初にN7ポリシー制御へ参加したPCFと完全に同一であることを確認します。

配備アーキテクチャも考慮する必要があります。一部のネットワークでは、BSFがSMFと同一ノードに配置されることがあります。この場合、パケットキャプチャ位置や内部呼び出しフローは、独立したBSF構成とは異なる場合があります。ただし基本原則は変わりません。ネットワークはUEセッションと担当PCFの間に安定したバインディングを維持する必要があります。

よくある質問

BSFとNRFはどちらもネットワーク機能選択を行うのか

いいえ。両者の役割は異なります。NRFはネットワーク機能が利用可能なNFインスタンスとその能力を発見するのを支援し、サービスレジストリに近い役割を持ちます。一方BSFは、特定のUEセッションとPCFの間ですでに確立されたバインディングを保存します。簡単に言えば、NRFは「どのPCFが利用可能か」に答え、BSFは「このUEセッションをすでにどのPCFが担当しているか」に答えます。

UEはPCFバインディングを1つしか持てないのか

必ずしもそうではありません。バインディングはUE識別情報だけで決まるものではなく、DNN、S-NSSAI、具体的なPDUセッションコンテキストにも依存します。同じUEが異なるデータネットワークやネットワークスライスへアクセスする場合、対応するバインディングを別々に維持する必要があります。

BSFとSMFを同じネットワーク機能インスタンスに配置できるのか

はい。コロケーション構成は可能です。その場合、外部から見えるシグナリング順序は独立BSF構成と異なることがありますが、UEとPCFのバインディングは引き続き保存・利用する必要があります。トラブルシュート時には、まず実際のベンダー構成を確認するべきです。

BSF照会に失敗したとき最初に何を確認すべきか

まず3点を確認します。バインディングレコードが正常に作成されたか、照会パラメータが登録時に使用した値と一致しているか、そしてバインディングが期限切れになっていないか、または早期に削除されていないかです。BSFがレコードを返す場合は、返されたPCFアドレス、FQDN、Diameter識別子が想定するPCFインスタンスを指していることも確認してください。