5Gコアの「司令塔」を理解する：NRFにおけるサービス登録と発見の裏側
5Gコアネットワーク（5GC）の設計に携わっていると、しばしば「SBA（Service Based Architecture）」という言葉に突き当たります。従来の4G（EPC）が、特定の機能を持つノードが複雑な専用線で結ばれた「点と点の関係」だったのに対し、5GCはまるでマイクロサービスアーキテクチャそのもの。その中心で「誰がどこにいるのか」を管理する、いわばネットワーク版の「DNS兼サービスディスカバリ」が今回解説する NRF（Network Repository Function） です。
現場のエンジニアにとって、NRFは単なる仕様上の存在ではありません。NF（Network Function）同士が疎通できない際、パケットキャプチャを開いてNRFへの HTTP POST が201で返っているか、あるいは403で拒絶されているかを確認する瞬間、私たちはこの仕組みの重要性を痛感するのです。
—
1. NRFの役割：サービス登録と発見のメカニズム
SBAにおいて、AMFやSMFといった各NFは、起動時に自身のプロフィールをNRFに登録します。これを NF Registration と呼びます。そして、他のNFからサービスを呼び出す際（NF Discovery）、NRFに対して「このサービスを提供できる奴はどこだ？」と問い合わせを行います。
この通信は全て RESTful API、つまり HTTP/2 上の JSON で行われます。インフラエンジニアとしては、この HTTP リクエストのヘッダーやボディの構造を、TCPDump や Wireshark で瞬時に読み解けるようになっておくことが、トラブルシューティングの第一歩です。
—
2. 実践：NF登録（NF Profile Registration）のコード例
NFが起動し、NRFに自身の情報を登録する際のフローを考えてみましょう。ここでは、Pythonの requests ライブラリを用いたイメージで解説します。実際の実務では HTTP/2 対応のライブラリが必須ですが、ロジックは以下の通りです。
import requests
import json
# NRFのエンドポイント（実際はDiscoveryで取得したFQDNを使用）
nrf_url = "https://nrf.local.5gc/nnrf-nfm/v1/nf-instances/amf-01"
# 登録するNFプロファイルの構造体
nf_profile = {
"nfInstanceId": "amf-01-uuid-1234",
"nfType": "AMF",
"nfStatus": "REGISTERED",
"ipv4Addresses": ["192.168.1.10"],
"nfServices": [
{
"serviceInstanceId": "namf-comm",
"serviceName": "namf-comm",
"versions": [{"apiVersionInApiRoot": "v1"}],
"scheme": "https",
"apiPrefix": "https://amf.local.5gc:8080"
}
]
}
# NRFへPUTリクエストを送信して登録
# 冪等性を考慮し、初回登録にはPUTが使われることが多い
response = requests.put(nrf_url, json=nf_profile, headers={"Content-Type": "application/json"})
if response.status_code == 201:
print("登録成功：NRFがNFを認識しました")
else:
print(f"登録失敗：{response.status_code} - {response.text}")実務のTips
nfInstanceId: これは必ずUUIDで管理してください。インフラの自動スケーリングでNFが再起動するたびにIDが変わると、NRFのデータベースがゴミデータで溢れかえります。heartbeat: NRF登録後、NFは定期的にPATCHメソッドで自身の生存報告（Heartbeat）を送る必要があります。これを忘れると、NRF側でNFStatusがSUSPENDEDになり、通信が遮断されます。
—
3. NF発見（NF Discovery）のクエリ設計
次に、あるNFが他のサービスを呼び出す際の「検索」フェーズです。例えばSMFがPCFを探す際、以下のような curl コマンドに近いリクエストが飛び交います。
# NRFに対して、特定のサービスタイプを持つNFを検索する
curl -v -X GET \
"https://nrf.local.5gc/nnrf-disc/v1/nf-instances?target-nf-type=PCF&requester-nf-type=SMF" \
-H "Accept: application/json"この際、NRFは target-nf-type だけでなく、sNssai（ネットワークスライスのID）や dnn（データネットワーク名）などを条件に追加してフィルタリングを行います。
—
4. トラブルシューティングの勘所
現場でよく遭遇するのは、「NRFまでは到達しているのに、検索結果が空（200 OKだがリストが空）になる」というケースです。
1. スコープの不一致: 登録時の sNssai 情報と、検索時のクエリパラメーターが微妙に一致していないことがよくあります。大文字・小文字、あるいは sNssai 内の sst（Slice/Service Type）の値が正しいか、JSONの階層を疑ってください。
2. 証明書エラー: NRFとの通信は基本的に TLS 必須です。mTLS（相互認証）が求められる環境では、クライアント側の証明書の期限切れや、信頼されたCA証明書がインポートされていないことが原因の9割を占めます。
3. APIバージョンのミスマッチ: apiVersionInApiRoot で指定したバージョンと、リクエスト先のURIが合致しているか確認してください。
最後に
NRFは5GCという巨大なパズルを繋ぐ接着剤です。この動きを理解していれば、ベンダーのブラックボックス的な機器であっても、どこでパケットが迷子になっているのか、論理的に追い詰めることができます。
まずは、あなたの環境のNRFに対して GET リクエストを投げ、現在登録されている NF Profile を覗いてみることから始めてみてください。そこには、ネットワークの「現在」が全て書き込まれています。
コメント