【実務・中級編】 5G SA(Standalone)アーキテクチャ(5GC)の完全仮想化とサービスベースアーキテクチャ – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5G SAの真髄:サービスベースアーキテクチャ(SBA)をエンジニアの視点で解剖する

「5Gになったのに、なぜか速度が出ない」「結局、4G(NSA)と何が違うんだ?」――そんな疑問を抱えているエンジニア諸君、ようこそ。

多くの人が「5G」と聞いて連想するのは、せいぜい「ミリ波による爆速通信」くらいだろう。だが、モバイル通信の現場で飯を食っている我々にとって、5Gの真の革命は無線区間ではなく、コアネットワークにある。それが5G SA(Standalone)であり、それを支える5GC(5G Core)の「サービスベースアーキテクチャ(SBA)」だ。

今日は、ベンダーのカタログスペックを眺めるだけでは決して見えてこない、SBAの泥臭い実態と、それを制御するWeb APIの世界を深掘りしていこう。

—

1. EPCとの決別:SBAがもたらす「クラウドネイティブ」な世界

これまでのLTE(EPC)は、ハードウェアに近い物理的なノード(MME, S-GW, P-GW)が、専用のプロトコル(GTP, Diameter)で「点と点」を繋ぐ閉鎖的な世界だった。

しかし、5GCではすべてがNF(Network Function)という仮想化されたソフトウェアとして定義され、これらがSBI(Service Based Interface)というHTTP/2ベースのRESTful APIで相互に通信を行う。

つまり、5G Coreは巨大な「Webアプリケーション」に変貌したのだ。これが何を意味するか? ネットワークエンジニアとWebアプリケーションエンジニアの境界線が、ついに消滅したということだ。

—

2. SBIの正体:なぜHTTP/2とJSONなのか

SBAにおける各NF(AMF, SMF, UPFなど)のやり取りは、標準化団体3GPPによって 3GPP TS 29.500 シリーズで定義されている。

面白いのは、これらが完全にWebの作法に従っている点だ。

  • トランスポート層: HTTP/2 over TLS
  • データ形式: JSON
  • API設計: RESTful API

例えば、端末がネットワークに接続する際、アクセス管理を行うAMFが、セッション管理を行うSMFに対してコンテキストを要求するフローは、まさにマイクロサービスのAPIコールそのものだ。

認証・認可フローの概念(curlによるシミュレーション)

現場でトラブルシューティングをする際、Wiresharkでパケットを追うのも良いが、まずはAPIの挙動を理解しておく必要がある。以下は、あるNFが別のNFのサービスを叩く際のイメージだ。

# AMFからSMFに対してセッション作成を要求するREST APIコールのイメージ
curl -X POST "https://smf.5gc.local/nsmf-pdusession/v1/pdu-sessions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <JWT_TOKEN>" \
  -d '{
    "supi": "imsi-123456789012345",
    "pduSessionId": 5,
    "dnn": "internet",
    "requestType": "INITIAL_REQUEST"
  }'
# 成功すれば 201 Created が返り、セッションIDを含むJSONが戻ってくる

実務では、この際に 3gpp-Sbi-Target-Nf-Id といったカスタムヘッダーが付与される。これらを追うのが、現代のモバイルエンジニアの「パケットキャプチャ」だ。

—

3. 実践:PythonでNFの状態を監視する

インフラ運用において、特定のNFが健全かどうかを判断するために、監視システムから各NFの NFDiscovery を叩くことは日常茶飯事だ。NRF(Network Repository Function) という「NF専用の電話帳(DNSのようなもの)」から情報を引くコード例を示そう。

import requests

# NRFのサービスエンドポイント
nrf_url = "https://nrf.core.5g.local/nnrf-disc/v1/nf-instances"

def get_available_smf():
    # SMF(セッション管理機能)を探すためのクエリ
    params = {
        "target-nf-type": "SMF",
        "service-names": "nnsmf-pdusession"
    }
    
    try:
        response = requests.get(nrf_url, params=params, timeout=5)
        response.raise_for_status()
        
        # 応答には利用可能なSMFのURIリストが含まれる
        nf_instances = response.json().get('nfInstances', [])
        return [nf['nfInstanceId'] for nf in nf_instances]
    
    except requests.exceptions.RequestException as e:
        print(f"NRFへの問い合わせでエラー発生: {e}")
        return []

# 実行例
print(f"稼働中のSMF一覧: {get_available_smf()}")

—

4. 現場で直面する「泥臭い」トラブルシューティング

最後に、シニアエンジニアとして一つだけ釘を刺しておきたい。
「APIベースになったからWebと同じ」と油断していると、必ず痛い目を見る。

1. MTUサイズの問題: HTTP/2のヘッダーが巨大化し、パケットがフラグメント化されて、古いルーターでドロップされる現象は頻発する。tcpdump を取る際は、必ず snaplen をゼロにして全パケットを取得せよ。
2. TLSのオーバーヘッド: 全ての通信がHTTPS/2(TLS 1.3)で暗号化されるため、CPU負荷が高い。NFのスケールアウト設定を怠ると、トラフィック急増時にAPIのレスポンスがタイムアウトし、ネットワーク全体が「デッドロック」に陥る。
3. ステートの不整合: NFはステートレスを目指しているが、実際の実装では UDM(Unified Data Management) との同期ズレが起きることがある。APIの 404 Not Found が返ってきたら、ログの correlation-id を追って、どのNFがステートを保持しているのかを突き止めるのが定石だ。

まとめ:ネットワークは「コード」で動く時代へ

5G SAの導入は、単なる通信速度の向上ではない。それは、ネットワーク運用という職能を、ソフトウェアエンジニアリングの領域へと完全にアップデートするイベントだ。

プロトコルスタックを教科書的に暗記する時代は終わった。これからは「どうAPIを叩き、どう非同期なイベントを捌き、どうサービスを疎結合に保つか」を議論できる者が、真のネットワークエンジニアとして生き残る。

もし君が今、curl コマンドを叩いて 200 OK が返ってきた瞬間にニヤリとできるなら、君はもう立派な5Gエンジニアの入り口に立っている。さあ、次はどのAPIを叩こうか?

コメント

タイトルとURLをコピーしました