5Gコアの心臓部を支える「SCTP」の正体：NGAPとマルチホームの泥臭い真実
モバイル通信の世界に足を踏み入れたエンジニアなら、一度は「5Gのコントロールプレーンはどうやって高信頼性を確保しているのか？」という疑問に突き当たるはずです。
Web APIの設計で馴染み深い TCP は「信頼性は高いが、ヘッド・オブ・ライン・ブロッキング（HoLB）が痛い」。かといって UDP は「速いけれど、順序制御や再送が面倒」。この二つのいいとこ取りを狙い、5Gコアネットワークの要である NGAP（Next Generation Application Protocol）のトランスポートとして採用されたのが SCTP（Stream Control Transmission Protocol）です。
今日は、教科書的な仕様の羅列ではなく、現場のトラブルシューティングで汗をかいてきたエンジニアの視点から、SCTP のポート番号 38412 に隠された「マルチホーム」の真価について深掘りしていきます。
—
なぜ5GはTCPではなくSCTPなのか？
NGAP が SCTP を選んだ最大の理由は、単なる信頼性だけではありません。複数のストリームを並列に処理する「マルチストリーミング」と、ネットワーク経路の冗長化を実現する「マルチホーム」機能にあります。
特にマルチホームは、サーバー側に複数のIPアドレスをバインドし、万が一メインの経路がブラックホール化しても、シームレスに別経路へ切り替える仕組みです。これこそが、キャリアグレードの「止まらない通信」の生命線なのです。
SCTPのマルチホームが動き出すとき
SCTP のセッション確立（4ウェイハンドシェイク）において、エンドポイントは自身の持つ複数のIPアドレスを INIT / INIT ACK チャンクで通知し合います。
[AMF (Active)] <--- INIT (IP-A, IP-B) ---> [gNB (Standby)]
[AMF (Active)] <--- INIT ACK (IP-X, IP-Y) ---> [gNB (Standby)]このやり取りにより、双方は「相手がどのIPを使えるか」を把握します。もしメイン経路（Primary Path）でパケットロスや再送タイムアウトが頻発すると、SCTP のスタックは自動的にサブ経路（Alternate Path）へとデータを流し替えます。アプリケーション層（NGAP）にパケットロスを意識させることなく、コネクションを維持し続ける。この泥臭い制御が、5Gの安定性に寄与しているのです。
—
実践：SCTPの状態確認とデバッグ
インフラ運用において、38412 ポートで待ち受ける AMF（Access and Mobility Management Function）との通信が上手くいかない場合、まず確認すべきは ss や netstat ではなく、sctp-utils を活用したパケットレベルの可視性です。
1. 通信経路の確認コマンド
Linux環境で SCTP のコネクション状態を確認するには、以下のコマンドが必須です。
# -S でSCTPソケットのみを表示
# -n で名前解決をせずIPを表示
ss -Sntpこのコマンドで ESTAB になっていることを確認するのは基本中の基本。もし COOKIE-WAIT や COOKIE-ECHOED で止まっているなら、それは経路上のファイアウォールが SCTP をパケットドロップしている可能性が高いです。
2. PythonでSCTPの挙動をシミュレートする
実務でモックサーバーを立てる際、Python の socket モジュールを使うと便利です。ただし、標準ライブラリでは SCTP を直感的に扱いにくいため、pysctp などのライブラリを併用するのが現場の定石です。
import socket
from sctp import sctpsocket_tcp
# SCTPソケットの作成
sk = sctpsocket_tcp(socket.AF_INET)
# マルチホームを実現するためのIPバインド（例: 2つのインターフェースをバインド）
# 実際にはサーバー側のNIC設定に依存します
sk.bindx(['192.168.1.10', '10.0.0.10'], port=38412)
# リッスン開始
sk.listen(5)
print("NGAP用ポート 38412 で待機中...")
while True:
conn, addr = sk.accept()
# 接続後のハンドリング処理を記述
print(f"Connected by {addr}")—
運用上の落とし穴：ファイアウォールとMTU
SCTP で最も多いトラブルが、「なぜかセッション確立後の最初の大きいデータが通らない」という事象です。
原因の多くは MTU（Maximum Transmission Unit）と Path MTU Discovery（PMTUD）の不整合です。SCTP はパケットサイズが大きくなりやすいため、中継するルーターやファイアウォールで ICMP Destination Unreachable がフィルタリングされていると、経路のMTUサイズを正しく判定できず、接続がハングアップします。
トラブルシューティングのTips
- tcpdumpの活用: フィルタで
sctpを指定し、INITチャンクが往復しているか確認する。 - sysctlの設定: カーネルの
net.sctp.path_max_retransパラメーターを調整し、切り替えの感度を調整する（デフォルト値が環境に合っていないことが多々あります）。
# 現在の再送回数設定を確認
sysctl net.sctp.path_max_retrans
# 障害検知を早めるために値を下げる（例: 5から3へ）
sysctl -w net.sctp.path_max_retrans=3—
最後に：ネットワークを「育てる」エンジニアへ
SCTP のマルチホームやストリーム制御は、単なるプロトコルの仕様ではありません。それは、通信の信頼性を「ソフトウェアのロジック」で解決しようという、先人たちの執念の結晶です。
API設計一つとっても、バックエンドのネットワークがどういう挙動をしているかを知っているだけで、設計の解像度は劇的に上がります。「繋がっているからOK」ではなく、「どういう経路で、なぜその経路が選ばれているのか」をパケットのレベルまで想像できるエンジニアこそが、次世代のネットワークを支える存在になれると信じています。
皆さんの現場でも、もし 38412 ポートで悩むことがあれば、まずは SCTP のマルチホームの挙動に立ち返ってみてください。泥臭いデバッグの先に、必ず答えはあります。
コメント