5Gコアの「心臓部」を解剖する：SMFが担うPDUセッションとIP割当のリアル
こんにちは。ネットワークの現場でパケットの迷子に泣き、夜中にコアネットワークのログを追いかけてきた諸君。
今日は、5Gコア（5GC）の影の支配者、SMF（Session Management Function）について深掘りしよう。教科書には「PDUセッションを管理する機能」なんて一行で書かれているが、実際の現場でエンジニアが直面するのは、疎通不能な端末からの「なぜ繋がらない？」という悲痛な叫びだ。
なぜIPアドレスが降ってこないのか、なぜルーティングが切れるのか。その答えの多くはSMFの制御フローにある。今回は、インフラ運用やWeb API開発に携わるエンジニア諸君のために、現場の知見を交えてSMFの役割を紐解いていく。
—
1. SMFは何をしているのか？ ―「接続」の指揮官
SMFは、いわば5Gの「セッション制御の総司令官」だ。端末（UE）がネットワークに「データ通信したい」と手を挙げた瞬間から、その通信が終了するまでを管理している。
主なミッションは以下の3つだ。
- PDUセッションの確立・修正・解放: どのネットワーク（DN）に、どんなポリシーで繋ぐか。
- ユーザープレーン（UPF）の選定と制御: 通信の「通り道」をどこにするか。
- IPアドレスの割当と管理: 端末にどのIPを配るか。
特にWeb API開発者にとって重要なのは、SMFが「IPアドレスの管理」という、DHCPやRADIUS的な役割をコアネットワーク内で完結させている点だ。
—
2. PDUセッション確立の裏側（シーケンス）
端末が通信を開始する際、NAS（Non-Access Stratum）レベルで「PDU Session Establishment Request」が送られる。これをトリガーに、SMFは以下のような複雑なダンスを踊る。
1. 認証と認可: AMF経由でUDM（Unified Data Management）に問い合わせ、このユーザーがその通信をしていいか確認する。
2. ポリシー取得: PCF（Policy Control Function）から通信のルール（帯域制限や優先度）を取得する。
3. UPF選定: 負荷状況や地理的条件から、最適なUPFを選び、N4インターフェースを介してトンネルを構築する。
4. IP割当: SMF内のIPプールからアドレスを払い出し、端末へ通知する。
—
3. 実務で役立つ：IP割当の制御とデバッグ
現場で「IPが割り当たらない」というトラブルに遭遇した際、我々が見るのはN4インターフェースのログや、SBI（Service Based Architecture）経由のAPIリクエストだ。
PythonによるSMF API（擬似コード）の叩き方
最近の5Gコアは、RESTベースのHTTP/2でやり取りされている。PCFからポリシーを取得する際のイメージを持っておこう。
import requests
# SMFからPCFへポリシーを問い合わせる際の構造（概念）
def get_policy_from_pcf(ue_id, dnn):
url = "https://pcf.local.5gc:8080/npcf-policyauthorization/v1/app-sessions"
headers = {
"Content-Type": "application/json",
"Authorization": "Bearer <TOKEN>"
}
payload = {
"ipv4Addr": None, # ここでIP割当を要求・確認
"dnn": dnn,
"subscriptionId": ue_id
}
# 実際にはここでJSONレスポンスを解析し、UPFへN4指示を出す
response = requests.post(url, json=payload, headers=headers)
return response.json()
# 現場のログ追跡では、このpayloadに含まれるIP情報の有無が命綱になる現場Tips：IPアドレス管理の罠
SMF運用で最も泥臭いトラブルは「IPアドレスプールの枯渇」だ。
特にIoTデバイスが数千台単位で同時接続し、即座に切断を繰り返すような環境では、Release処理が追いつかずIPがロックされ続けることがある。
curlでUPFの状況を叩く際も、単に疎通を確認するだけでなく、現在のセッション数を必ずモニタリング対象に入れておくべきだ。
# UPF上のセッション統計を確認するコマンド例（ベンダー依存のCLI）
# 実際の運用では、このようなコマンドを定期実行し、異常があればアラートを飛ばす
$ show-upf-session-stats --dnn internet.access
# 戻り値の「Active_Sessions」がプール上限に達していないか確認する—
4. なぜ「Sub6」や「ミリ波」に関係があるのか？
読者の中には「なぜ物理層の話とSMFが関係あるのか？」と思う方もいるだろう。実は、5Gの周波数帯によってSMFが選択するUPFの場所（エッジか、中央か）が変わる。
- ミリ波（高周波）: 超低遅延が求められるため、
SMFは端末に近いエッジUPFを選定し、IPルーティングを最小化する。 - Sub6/LTE: 広域カバレッジを重視するため、中央のデータセンター側にある
UPFへ繋ぎ、IPセッションを安定させる。
エンジニアとして意識すべきは、「物理層の特性に合わせて、SMFが論理的な通信経路（UPFの場所）を動的に変更している」という事実だ。Web APIのレイテンシ設計を行う際、バックエンドがどこのUPFと通信しているかを理解していないと、ミリ秒単位のチューニングは不可能になる。
—
結論：ネットワークを「プログラム」する視点を持て
現代のエンジニアにとって、ネットワークは「箱（物理機器）」ではなく、JSONやHTTPで制御される「コード」の延長線上にある。
SMFの挙動を理解することは、単にモバイル通信の仕組みを知ることではない。あなたの開発するアプリケーションが、どのようなネットワークコンテキスト（IPアドレス、帯域、遅延）の上で動いているかを理解することに他ならない。
次に「繋がらない」というログを見た時、まずはAMFとSMFの間で何が起きているのか、そのシーケンスを想像してみてほしい。パケットは、君のコードが投げたデータが、物理の世界を駆け巡るための設計図なんだから。
それでは、また現場で会おう。健闘を祈る。
コメント