【実務・中級編】 5G 5GCにおけるHTTP/2ベースのService Based Interfaces(SBI)とREST API – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5Gコアネットワークの「背骨」を理解する：HTTP/2ベースSBIとREST APIの実践的アプローチ

こんにちは。現場で叩き上げのネットワークエンジニアをしていると、かつての通信業界がいかに「閉鎖的で特殊なプロトコル」に依存していたかを痛感します。昔はSCTPやDiameterといった難解なプロトコルをパケットキャプチャで必死に追っていましたが、今の5Gコア（5GC）は様相が違います。

5GCを支えるのは、Webエンジニアにはおなじみの HTTP/2 と JSON です。Service Based Architecture（SBA）という設計思想は、まさに「ネットワークを巨大なWeb APIの集合体」として再定義しました。今回は、現場で5GCのトラブルシューティングやAPI設計に関わる皆さんに向け、SBI（Service Based Interface）のリアルな挙動を解説します。

—

1. なぜ「Webの技術」が5Gコアに持ち込まれたのか？

これまでのモバイルネットワークは、ベンダ固有の作り込みが激しく、拡張性や柔軟性に欠けていました。しかし、5Gではネットワーク機能を「サービス」として切り出し、REST API経由で相互接続するアーキテクチャが採用されました。

ここで重要なのが、NF（Network Function）間の通信を規定する SBI（Service Based Interface） です。

AMF (Access and Mobility Management Function): 端末の接続と位置管理
SMF (Session Management Function): セッション制御

これらが互いに「相手が何を提供できるか」をAPIを通して知る。まるでマイクロサービスアーキテクチャそのものですよね。

—

2. HTTP/2が前提である理由と通信のリアル

なぜHTTP/1.1ではなくHTTP/2なのか。答えはシンプルで「多重化」と「ヘッダー圧縮」です。5GCのトラフィックは極めて高密度です。HTTP/2の Stream を使えば、1つのTCPコネクションで複数のNF間通信をパラレルに流せます。

実務でパケットを追う際は、Wiresharkで http2 フィルターをかけるのが基本ですが、SETTINGS フレームや WINDOW_UPDATE フレームで接続が詰まっていないかを確認するのがデバッグの第一歩です。

サービス要求のフロー例

AMFからSMFへセッション作成（Nsmf_PDUSession）を要求する場合、以下のようなJSONペイロードがHTTP POSTで飛び交います。

{
  "supi": "imsi-123456789012345",
  "pduSessionId": 5,
  "dnn": "internet",
  "sNssai": {
    "sst": 1,
    "sd": "000001"
  }
}

—

3. 実践：PythonでNnrf_NFDiscoveryをシミュレートする

NFが別のNFを見つけるための「NF Discovery」を、Pythonの requests ライブラリ（HTTP/2対応の httpx がより実用的です）で擬似的に表現してみましょう。

import httpx

# NRF（Network Repository Function）のURL
nrf_url = "https://nrf.local:8080/nnrf-disc/v1/nf-instances"

# 検索パラメータ：SMFを探す場合
params = {
    "target-nf-type": "SMF",
    "requester-nf-type": "AMF"
}

# 認証トークン（OAuth2.0）をヘッダーに含めるのが5GCのお作法
headers = {
    "Authorization": "Bearer <access_token>",
    "Accept": "application/json"
}

# HTTP/2でリクエストを投げる
with httpx.Client(http2=True) as client:
    response = client.get(nrf_url, params=params, headers=headers)
    
    if response.status_code == 200:
        print("NF発見成功:", response.json())
    else:
        print(f"エラー発生: {response.status_code}")

—

4. 現場で役立つデバッグTips

実務で最もハマるのが 「負荷分散とロードバランサー（LB）」 です。5GCでは、NFの前にL7ロードバランサー（Service Communication Proxy: SCP）を置くことが一般的です。

3GPP TS 29.500 を座右の銘にする:

APIのレスポンスコード（404 Not Found や 503 Service Unavailable）の定義がすべてここにあります。

HTTPヘッダーを確認:

3gpp-Sbi-Target-Nf-Id や 3gpp-Sbi-Routing-Binding といった独自ヘッダーが、パケットのルーティングを制御しています。ここが不整合だと、パケットは正しく目的のNFに届きません。

curlで疎通確認:

現場での切り分けには curl --http2 を使います。

# 証明書検証をスキップしつつ、HTTP/2で特定のNFへリクエストを投げる
curl -v --http2 -k \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <TOKEN>" \
  -X POST https://smf.local/nsmf-pdusession/v1/pdu-sessions \
  -d @payload.json

—

最後に：ネットワークエンジニアの武器

かつてのネットワークエンジニアは「パケットが流れているか」だけを見ていれば良かったかもしれません。しかし、現在の5GCを運用するということは、「分散システムを運用する」 ことと同義です。

APIの設計思想を理解し、JSONのスキーマを読み解き、HTTP/2のストリームを追う。これらWeb技術の基礎があるだけで、ネットワークトラブルの解決速度は劇的に向上します。

もし現場で「通信が繋がらない！」と叫んでいるエンジニアがいたら、まずは tcpdump だけで終わらせず、その先にあるAPIのレスポンスコードを一緒に眺めてみてください。そこには、ネットワークの「意志」がJSONの形式で記されているはずですから。