5Gコアの心臓部を覗く：SMFが提供するNsmf_PDUSession APIの深淵
ネットワークエンジニアとして現場に立っていると、「5Gは速い」といった表面的な話よりも、「なぜこのセッションは確立されないのか？」「なぜ切断されるのか？」という泥臭いデバッグに直面することがほとんどです。
5Gシステム（5GS）のサービスベースアーキテクチャ（SBA）において、通信の「ライフライン」を管理しているのが、SMF（Session Management Function）です。今回は、そのSMFが提供するNsmf_PDUSessionサービスAPIに焦点を当て、実務レベルで知っておくべきセッションライフサイクルとパラメータ構造を紐解いていきましょう。
Nsmf_PDUSession APIが担う「責任」
SMFが提供するこのAPIは、UE（端末）の接続から切断まで、まさに「セッションの生涯」を管理するためのものです。HTTP/2を基盤としたRESTful APIとして定義されており、主に以下のライフサイクルを制御します。
1. Create (POST): 新規セッションの確立
2. Update (PATCH): セッションの変更（ハンドオーバーやQoSの変更など）
3. Release (POST): セッションの終了
これらを理解せずに「繋がらない」と嘆くのは、ブラックボックスの中身を見ずに配線を疑うようなもの。まずはAPIの構造を叩き込みましょう。
セッション作成のフローとパラメータの勘所
セッション作成時の POST /sessions は、最もドラマが起きやすいポイントです。ここでは PduSessionCreateData というオブジェクトをJSONで投げつけます。
現場でよく見るトラブルの多くは、この中の pduSessionId の不一致や、sNssai（ネットワークスライス情報）の不整合です。
{
"supi": "imsi-440101234567890", // 加入者識別子
"pduSessionId": 5, // セッションID
"sNssai": {
"sst": 1, // スライスタイプ
"sd": "000001" // スライス区分
},
"dnn": "internet", // データネットワーク名
"n1SmInfoFromUe": { // UEからのNASメッセージ（バイナリをBase64エンコード）
"contentId": "n1SmMsg"
}
}このリクエストを投げる際、必ず確認すべきは Content-Type を application/json ではなく multipart/related に設定することです。NASメッセージを含む場合、JSONとバイナリを分離して送る必要があるからです。ここを疎かにして「400 Bad Request」を連発するのは、新人が必ず通る道です。
実務で使う：Pythonによるセッション作成のテストコード
運用保守やラボでの検証において、curl だけでは限界があります。Pythonの requests ライブラリ（あるいは httpx）を用いて、モックサーバーや実機に対してセッション作成を試みるスクリプトの断片を載せておきます。
import requests
import json
# SMFのAPIエンドポイント
smf_url = "http://smf.5g-core.local/nsmf-pdusession/v1/pdu-sessions"
headers = {
"Content-Type": "application/json",
"Accept": "application/json"
}
payload = {
"supi": "imsi-440101234567890",
"pduSessionId": 5,
"dnn": "internet",
"sNssai": {"sst": 1, "sd": "000001"}
}
# 実際の実務ではここに認証用のBearerトークンを付与する
try:
response = requests.post(smf_url, json=payload, headers=headers)
response.raise_for_status()
print(f"セッション作成成功: {response.status_code}")
print(f"セッションコンテキスト: {response.json()}")
except requests.exceptions.HTTPError as err:
# 現場で最も重要なログ。ここを詳細に出力するように設計する
print(f"エラー発生: {err}")
print(f"詳細: {response.text}")セッション変更（PATCH）とトラブルシューティングの極意
ハンドオーバーやQoSの更新時には PATCH メソッドが使われます。ここで重要なのが n1SmInfoFromUe の変更です。
現場のデバッグで最も有効なのは、X-Correlation-ID や 3gpp-Sbi-Trace-Id を追うこと。SBA環境では、AMFからSMF、UPFへとリクエストが連鎖します。どこでパケットがドロップしているのか、Wireshark を開く前に、まずは各ノードのログでこれらのIDが引き継がれているかを確認してください。
最後に：シニアエンジニアからの助言
API仕様書（3GPP TS 29.502）は非常に分厚く、すべてを暗記するのは不可能です。しかし、以下の3点は心に留めておいてください。
1. エラーコードの「裏」を読め: 403 Forbidden が返ってきたとき、それは単なる権限不足ではなく、バックエンドのPCF（Policy Control Function）との連携エラー（ポリシーの不整合）であることが多い。
2. ステートマシンを信じるな: APIの戻り値と、実際のUPFの転送状態が乖離することがあります。GET /sessions/{pduSessionRef} を定期的に呼び出し、現在のリソース状態と同期が取れているかを確認する「ヘルスチェックルーチン」を自作することをお勧めします。
3. 泥臭いパケット解析: JSONのパースエラーを疑う前に、まずは tcpdump で該当インターフェースのHTTP/2ストリームを確認しましょう。ヘッダーの欠落は、コードのミスよりも環境側の設定ミス（プロキシやロードバランサ）であることが往々にしてあります。
ネットワークは生き物です。仕様書という「地図」を手に持ちつつも、現場で流れるパケットという「足跡」を信じて、日々検証を繰り返してください。それが、最強のエンジニアへの近道です。
コメント