【実務・中級編】 5G無線アクセスネットワーク（NG-RAN）におけるCU-DU分離アーキテクチャ（F1インターフェース） – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5Gの「頭脳」を解き放つ：CU-DU分離とF1インターフェースがインフラエンジニアにもたらす変革

やあ、ネットワークエンジニアの皆さん。現場のトラブルシューティングでパケットキャプチャの山に埋もれる日々、お疲れ様です。

今日は、少しマニアックだが、今のモバイル通信インフラの「心臓部」に深く切り込む話をしよう。5Gの無線アクセスネットワーク（NG-RAN）における、CU-DU分離（Disaggregation）についてだ。

「基地局なんてアンテナが立っていればいい」なんて言っていた時代は終わった。5Gの世界では、基地局の機能が「中央集中」と「分散」に分断され、それらが F1インターフェース という絆で結ばれている。この構造を理解することは、WebサービスのバックエンドAPI設計や低遅延インフラを考える上で、驚くほど示唆に富んでいるんだ。

—

なぜCUとDUに分ける必要があるのか？

従来の4G LTEまでの基地局（eNB）は、ひとつの箱の中に「頭脳」から「手足」まで全てが詰まっていた。しかし5G、特にミリ波や高密度なエリア展開を考えると、この「全部入り」モデルは柔軟性を欠く。

そこで登場したのが、gNB（5G基地局）の機能分離アーキテクチャだ。

CU (Centralized Unit – 集中ユニット): 無線リソース制御（RRC）やパケットデータ収束プロトコル（PDCP）など、高度な処理を担当する。「司令塔」だ。
DU (Distributed Unit – 分散ユニット): 無線リンク制御（RLC）やメディアアクセス制御（MAC）、物理層（PHY）のリアルタイム処理を担う。「現場の実行部隊」だ。

これらを繋ぐのが F1インターフェース だ。ここでの通信は、F1-C（制御面）と F1-U（ユーザーデータ面）に分かれる。

F1インターフェースの解剖学

F1-C (Control Plane): SCTP 上で動作する F1AP (F1 Application Protocol) が走り、制御シグナリングを運ぶ。
F1-U (User Plane): GTP-U (GPRS Tunneling Protocol) を使用し、実際のユーザーデータをカプセル化して転送する。

—

現場で役立つF1インターフェースのデバッグ視点

Web APIエンジニアがなぜこれを知るべきか？それは、「モバイルネットワークの遅延は、アプリケーション層の努力だけでは解決できない」からだ。

もし君たちが設計するアプリケーションがリアルタイム性を要求するなら、この「CUとDUの間のジッター」が、TCPの往復時間（RTT）やQUICのハンドシェイクにどう影響するかを想像してほしい。

1. F1APのステータス確認（概念的CLI）

現場では、CUとDUのコネクションが確立されているか、F1AP のセットアップ要求が通っているかが全ての起点になる。

# 現場でよく使う擬似的なgNB管理CLI例
# CU側からDUとの接続状態を確認する
gnb-admin show f1-interface status --du-id DU-001

# 出力イメージ:
# F1-C State: ESTABLISHED (SCTP Association OK)
# F1-U State: ACTIVE (GTP-U Tunnel UP)
# Latency: 1.2ms (CU-DU RTT)
# 設定のヒント: SCTPのMulti-homing設定が冗長化の肝だ

2. PythonによるGTP-Uパケットの簡易解析（ロジックの理解）

F1-U で流れる GTP-U パケットを解析するスクリプトを書く際、エンジニアは TEID (Tunnel Endpoint Identifier) の重要性に気づくはずだ。

# F1-UパケットのGTPヘッダーを読み解くイメージ（Scapy等を使用）
from scapy.all import *
from scapy.contrib.gtp import GTPHeader

def analyze_f1_u_packet(packet):
    # GTP-Uパケットをフィルタリング
    if packet.haslayer(GTPHeader):
        gtp = packet[GTPHeader]
        print(f"TEID: {gtp.teid}")  # どのDUからどのセッションのデータかを示すID
        print(f"Payload Length: {len(packet.payload)}")
        # このTEIDが一致しないと、CUはパケットを捨ててしまう
        # Web APIでいうところのセッションIDの不整合に近い挙動だ

# パケットキャプチャを開始
sniff(filter="udp port 2152", prn=analyze_f1_u_packet)

—

遅延削減の真実：CU-DU分離の「ご利益」

CUとDUを分離することで、DUをアンテナの近く（エッジ）に配置し、CUをデータセンターに集約できる。これにより、「低遅延が必要な無線処理は現場で即断即決し、重い制御処理はクラウドでまとめて行う」というハイブリッドな運用が可能になる。

これは、Webサービスにおける「マイクロサービス」の考え方に非常に近い。

DUの負荷分散: 特定のDUが混雑しても、CUがトラフィックを適切にハンドリングする。
API設計への示唆: モバイル通信の遅延を考慮するなら、APIレスポンスのサイズは可能な限り小さくし、TCP Slow Start の回数を減らす工夫が必要だ。特に F1-U でトンネリングされる際、オーバーヘッドが微増することを忘れてはならない。

—

最後に：ネットワークは「生き物」である

CU-DU分離は、単なるアーキテクチャの変更ではない。無線アクセスネットワークが「専用ハードウェアの塊」から「汎用サーバーとソフトウェアの集まり」へと進化する過程そのものだ。

現場でトラブルに直面したとき、パケットがどこで滞留しているのか。CUのCPU負荷なのか、F1-Uのトンネル帯域なのか、それともDUの無線リソース（PRB）枯渇なのか。この視点を持つだけで、君たちのトラブルシューティングの精度は劇的に上がるはずだ。

ネットワークの世界に「魔法」はない。あるのは、丁寧な設計と、正確なパケットの挙動に対する洞察だけだ。また次回、泥臭い現場の深淵で会おう。