5Gコアは、もはや人と人との通信だけを対象に設計されているわけではありません。コネクテッドカー、スマートファクトリー、スマートキャンパス、遠隔医療、ドローンなど多くの業界アプリケーションでは、サービス状況に応じてネットワークリソースへ動的に働きかけたり、通信事業者から許可されたネットワーク状態情報を取得したりする必要が高まっています。新しい要件が出るたびにAMF、SMF、PCF、UDMなどの設定を事業者が手作業で変更しなければならないのであれば、5Gを垂直産業へ大規模に展開することは非常に困難です。

そこで登場するのがNEF（Network Exposure Function）です。NEFは5GCとAF（Application Function）の間に位置し、コアネットワーク内部の能力を外部アプリケーションが利用できる標準化インターフェースへ変換します。同時に、セキュリティ制御、情報変換、パラメータ伝達も担当します。第三者アプリケーションにとってNEFは単なるAPIゲートウェイではなく、通信事業者の5Gコア能力体系へアクセスするための制御された窓口です。

5GCにNEFが必要な理由

4Gのビジネスモデルは主にB2C型で、ネットワークが接続性を提供し、加入者がモバイルインターネットを通じて各種アプリケーションへアクセスしていました。5GではB2B2Xへと拡大し、個人ユーザーだけでなく、製造、交通、キャンパス、医療などの業界プラットフォームとのより深く自動化された連携が求められます。

ここで重要になるのが、業界アプリケーションが通信事業者のネットワーク能力を安全かつ標準化された方法でどのように利用するか、という問題です。

例えば、工場内の特定エリアにある生産端末へより予測可能なQoSを与えたい、あるいはアプリケーショントラフィックを工場に近いローカルデータネットワークへ誘導したい場合を考えます。共通の能力公開機構がなければ、アプリケーション基盤は複数のコアネットワーク機能へ直接接続し、ベンダーごとに異なる設定を実装する必要が生じます。これでは統合が複雑になり、内部インターフェースもより多く露出します。

NEFは業界アプリケーションと5GCの間に共通の境界を作ります。外部AFはAMF、SMF、PCF、UDM、UPFの細部をすべて理解する必要はなく、NEFを通じて標準準拠のサービス要求を送るだけです。その後NEFが適切な5GCネットワーク機能と連携し、結果をアプリケーション側へ返します。

この方式により、本来は手作業の調整や静的設定に依存していた一部の要件を標準化されたサービス呼び出しへ置き換え、通信事業者はより自動化された形でパートナーへネットワーク能力を公開できます。

5GCにおけるNEFの配置

NEFは5GCのネットワーク機能とAFの間に配置されます。AFは業務ロジックを担うアプリケーション層の機能エンティティで、通信事業者が所有・管理する信頼済みアプリケーションの場合もあれば、事業者の信頼ドメイン外にある第三者アプリケーション基盤の場合もあります。第三者アプリケーションへ内部コア機能の無制限な利用を許可することはできないため、制御された連携はNEFを経由します。

インターフェースの観点では、NEFは2つの異なる環境をつなぎます。北向きでは動画プラットフォーム、コネクテッドカープラットフォーム、産業制御システムなどのAFを扱い、南向きでは5GC内部機能へ接続し、要求されるサービスに応じてSMF、PCF、UDMなどと通信します。

NEFは4Gで使われたSCEFを発展させたものですが、対象範囲は大幅に広がっています。SCEFは主に特定のIoTユースケースに関連していましたが、5GCのNEFは人中心・機械中心の幅広いアプリケーションを支え、サービスベースの能力公開フレームワークの重要な要素になっています。

NEFは単にメッセージを転送するだけではありません。主な役割には、ネットワーク能力やイベントの公開、外部アプリケーションから3GPPネットワークへの安全な情報提供、外部形式と内部形式の情報変換、さらに必要に応じて他のネットワーク機能からデータを受け取り保存または再公開することが含まれます。

NEFが受信した一部の情報はUDRへ保存できるため、単一のNEFインスタンスに固定される必要はありません。またNEFはPFD機能も支援でき、より正確なアプリケーション検出とポリシー処理の基盤になります。

5つの主要能力はどのように公開されるか

NEFの価値は最終的に、どのサービスを公開できるかで決まります。実際の5GCでは、主な能力をQoS公開、ネットワークイベント購読、トラフィック誘導、パラメータプロビジョニング、PFD管理の5分野にまとめられます。これらは業界アプリケーションと通信事業者ネットワークの間でよく発生する代表的な連携要件です。

QoS能力の公開

QoS能力公開により、パートナーアプリケーションは特定のサービスフローに対するサービス品質を要求できます。例えば、既存のPDUセッション上で動画アプリが動作しているとき、ユーザーが高品質動画を選択すると、AFはNEFを介してそのトラフィックフローのQoS強化を要求できます。

NEFは要求を受け取るとPCFなどのコアネットワーク機能と連携します。PCFはポリシーロジックを適用し、SMFや他のネットワークリソースと協調して、そのサービスフローに適したQoS処理を設定します。

重要なのは単純に端末へ帯域を追加することではありません。アプリケーションが標準化インターフェースを通じてサービス要件を表現できる一方で、ポリシー判断とネットワークリソースの適用は5GCの管理下に置かれることです。

モビリティとネットワークイベント購読

第三者AFはNEFを利用して、UEの接続断、再到達可能化、現在または最後に把握された位置、ローミング状態、通信失敗理由、下りデータ配信状態など、UE関連のネットワークイベントを購読できます。

これらのイベントは異なるコアネットワーク機能で検出されます。AMFはUE到達性、接続断、特定の通信障害を検出でき、UDMはローミング状態や一部のID関連付け変更を提供できます。SMFは下りデータ配信に関する状態を報告できます。

AFがすべてのネットワーク機能へ直接接続する必要はありません。AFはNEFを通じてイベント購読を作成し、NEFが対象のネットワーク機能に必要な内部購読を設定します。対象イベントが発生すると、コアネットワークがNEFへ通知し、NEFが購読内容に従って外部AFへイベント通知を転送します。

この仕組みは、端末状態に応じて自動化された業務ロジックを起動する必要がある業界アプリケーションに特に有効です。外部プラットフォームがUE状態を継続的にポーリングする代わりに、実際にイベントが発生した時点で通知を受け取れます。

トラフィック誘導

NEFはAFからTraffic Influence要求を受け取り、特定UEまたはサービスのトラフィックをLocal DN（Local Data Network）へ誘導することもできます。Local DNはDNAIで識別され、一般にエッジコンピューティングや地域配置されたサービスと関連します。

例えば自動化工場では、産業制御サーバーを生産現場に近いローカルネットワークへ配置できます。アプリケーション基盤はNEFを通じて5GCへユーザープレーン経路の調整を要求し、対象端末のトラフィックを適切なLocal DNへルーティングできます。

NEFがUPFを直接制御するわけではありません。要求をポリシー制御プロセスへ渡し、PCFとSMFがポリシーとユーザープレーン設定を処理します。状況に応じてSMFはUPFを再選択したり、既存経路上のUPFを追加・置換・削除したりしてトラフィック誘導を実現します。

セキュアなパラメータプロビジョニング

外部AFはNEFを介して、特定のユーザー関連パラメータを5GCへ提供することもできます。ただし、アプリケーションがコアネットワークのパラメータを自由に変更できるという意味ではなく、提供可能な情報範囲は厳格に制御されます。

代表例にはExpected UE Behaviourと一部のNetwork Configuration Parametersがあります。Expected UE Behaviourは端末の予想される移動特性を示し、ネットワーク設定パラメータには最大応答時間、許容可能な下りデータ伝送遅延、UE到達不能時にバッファする推奨下りパケット数などが含まれる場合があります。

NEFは認可されたパラメータ要求をUDMへ転送し、UDMはUDRと連携して関連データを読み書きします。これらのデータ変更を購読しているAMFや他のネットワーク機能は、更新パラメータを受け取り、後続のネットワーク処理に利用できます。

PFD管理

PFD（Packet Flow Description）は、アプリケーション検出に用いるルールの集合と考えられます。第三者AFはNEFを通じてアプリケーション識別情報を作成できます。生成されたルールはUDRに保存され、SMFがNEFを介して取得し、アプリケーション検出のためUPFへ配信できます。

基本的なポート番号やアドレスだけでトラフィックを識別する方法に比べ、PFDはより具体的なアプリケーション特性を記述できます。例えば動画サービスを特定のURLパターンやその他のトラフィック特性で識別し、該当トラフィックを適切なポリシー処理ルールへより正確に対応付けられます。

NEFの本当の技術的価値

アーキテクチャの観点でNEFの最重要な役割は、新しい転送ノードを追加することではなく、管理可能な能力公開レイヤーを構築することです。外部AFからはサービス指向インターフェースが見えますが、5GC内部の実処理は引き続きPCFのポリシー制御、SMFのセッション管理、UDMのデータ管理、UPFのユーザープレーン処理などが担います。

そのためNEFを一般的なAPIゲートウェイとして捉えるべきではありません。外部の業務要求と3GPPコアネットワーク能力の関係を理解し、両者の間でセキュリティ制御、情報変換、処理フローの調整を行う必要があります。

NEFは他のネットワーク機能を置き換えるものでもありません。QoSの適用はポリシー制御とセッションリソース設定に依存し、ネットワークイベントは該当NFが検出します。ユーザープレーン経路はSMFなどが調整し、ユーザー関連データはUDMとUDRが維持します。NEFの役割は、これらの内部能力を制御された標準化方式で公開することです。

この能力は5G B2B2Xサービスで特に重要です。業界アプリケーションは5GC内部トポロジー全体を理解したり、各ネットワーク機能向けに独自インターフェースを構築したりする必要はありません。標準化された公開機構を通じてネットワーク要件を提出できます。同時に、通信事業者はコアネットワーク境界の制御を維持しつつ、選択したネットワーク能力を信頼できるパートナー向けサービスへ変換できます。

実運用上、NEFは5Gコアを主に接続性を提供するネットワークから、業界アプリケーションへネットワーク能力を直接公開できるプラットフォームへ進化させる役割を果たします。

よくある質問

すべてのAFは通信事業者ネットワークの外部に配置する必要がありますか？

いいえ。AFは通信事業者が所有または管理する信頼済みアプリケーションの場合もあれば、事業者の信頼ドメイン外にある第三者アプリケーションの場合もあります。AFの種類によってアクセス方式やセキュリティ処理は異なります。

業務データは常にNEF内にローカル保存されますか？

いいえ。NEFが受信した一部の情報はUDRへ保存でき、その後ほかのネットワーク機能や後続手順で利用できます。そのため、データ保存を単一NEFインスタンスに固定する必要はありません。

Local DNとUPFは同じものですか？

いいえ。Local DNは特定のアプリケーションやデータサービスを提供するローカルデータネットワークであり、UPFは5GCのユーザープレーンネットワーク機能です。トラフィックは適切なUPF経路を通じて指定Local DNへ到達できますが、両者の役割は異なります。

UPFが自らPFDルールを作成しますか？

いいえ。PFDルールはAFから提供され、NEFを通じて管理できます。SMFが関連ルールを取得し、ユーザープレーンでより正確なアプリケーション検出を行うためUPFへ配信します。