- はじめに（サマリ）
- 背景：ローカル5Gは5GSAが主流（人柱？）
- 1.プロシージャ（シグナリング）長い・種類多い・関連ノード多い・オプション多いのがツラい
- 2.プロシージャで躓いたとき（リンク断・ノード故障含む）の対処が超ツラい
- 3.端末によって言うことを聞いたり聞かなかったりするのツラい
- まとめ
はじめに（サマリ）
この記事は、筆者が以前5G SAシステムの検証（≒という名のひたすらバグ出し）を行った際に思ったことを書き綴ったものです。
SoftBankさんの下記記事や、昨今のZeroOutageというキーワードに触発されて備忘録的にまとめておこうと思いました。
障害に強いモバイル通信を目指して | ソフトバンク先端技術研究所 | 企業・IR | ソフトバンク
来週のSA1の寄書にの日本の4社連名のがあった
— omusubi (@omusubi5g) 2024年5月22日
Challenge for zero outage network
S1-241092 pic.twitter.com/tRxgAQCUKF
[サマリ]
1.プロシージャ（シグナリング）長い・種類多い・関連ノード多い・オプション多いのがツラい
2.プロシージャで躓いたとき（リンク断・ノード故障含む）の対処が超ツラい
3.端末によって言うことを聞いたり聞かなかったりするのツラい
背景：ローカル5Gは5GSAが主流（人柱？）
日本のMNOはまだ5GSAを全国的に広く提供していませんが、ローカル5G市場ではほぼ5GSAが主流となっています。2024年6月時点では、いわゆる世界のMNOに採用されているグローバルベンダだけではなく、様々な新興ベンダも5GSAシステムを提供しています（個人的には、ローカル5G市場がMNOに先行して5GSAの人柱になっている感があります）
単なるPoCではなく、実際に業務に組み込んで使うには、やはり安定性や品質面が気になります。そこで、様々なベンダのローカル5Gシステムについて、いわゆる準正常系・異常系テストをひたすら実施しました。その中で感じたことを綴っていきます。
1.プロシージャ（シグナリング）長い・種類多い・関連ノード多い・オプション多いのがツラい
まず、端末からインターネットにつなぐためには、大きく下記の3Stepがあります。
- 端末と基地局の間で無線通信路（RRCコネクション）を確立する
- 端末とコアの間で加入者認証・位置登録を実施する
- 端末とコアの間でデータの通信路（PDUセッション）を確立する
これらが3GPP仕様上で規定されたものは、下記になります。
inside TS 23.502: 5GS Registration procedures
一方で下記のように他の仕様をもとにより詳細化したり、対象ノードを絞って簡略化した記載もよく見られます。
5G Standalone Access Registration Signaling Messages
5G SA Registration | 5G Call Flow - Techplayon
これらを見てまず感じたのが、下記です。
- シンプルに長すぎる
（TCPの3ウェイハンドシェイクや、ARP解決ぐらいにスッキリにできんのか） - 基本パターンだけでもググって色んなシーケンスが出てきてどれが正しいのかわからない（3GPP仕様のTS23.502記載の手順で動いてるはずだよね…？）
- さらにローミングの場合とか、通信再開(Service Request)のパターンとかでちょいちょい中身変えて定義してくる
- 登場人物多すぎ 必須の人物はだれやねん
（実際のシステムで頻繁には見ない/逆に居るのに記載されてない人物がいる
e.g. old AMF/NSSF/NRF）
そして、これらの懸念がつぎの課題につながっていきます。
2.プロシージャで躓いたとき（リンク断・ノード故障含む）の対処が超ツラい
よくみる5Gアーキテクチャ図
これは、gNB~AMF間のN2、gNB~UPF間のN3、SMF～UPF間のN4、UPF~DN間のN6といった各ノード間のリンクや装置が故障した際の挙動、及び復旧したときの挙動を確認したときに感じたことです。
- それぞれのリンクの死活監視プロトコル、タイマやリトライ数もちろん違う
（N2はSCTP、N3はGTP、N4はPFCPとそれぞれ異なりますし、相互で監視するか、片方だけか、断検知・復旧検知の挙動もそれぞれインプリ次第だったり。
最適解はなんやねん） - 躓いたタイミング次第で適切にコンテキスト開放などしないと超絶ハマる
（いったん切れてやり直そうとしても、各ノードにゴミが残っていて、それが原因でそこから進まなくなること多数。何十もあるメッセージの1メッセージ毎・状態(既存呼や新規呼の場合等)毎に検証しないといけないのか？） - AMFが他ノードのエラーまで世話をして、RAN側に伝えないといけない
（例えば、PDUセッション周りのプロシージャはSMFが主担当であるが、そこで起きたエラーもAMF経由でRANや他ノードにお知らせしないといけない。AMFは大変><） - あるノード故障中に、他ノードは何してるのが正解？
（gNB~AMF間が切れてるけど、gNB～UPF間は生きてる、みたいなとき既存U-plane通信は継続、C-planeはひたすら上がってくるRegistration/ServiceRequestをRejectすべきなのか、いっそのこと停波するのか、それとも報知情報だけ止めるのか？ 運用でカバーなのか)
壊れたノード次第では、他も雪崩式に壊れていく、といった危険性も想定すると、ノードの最小化や、このノードが壊れたらこうする！みたいなベストプラクティスが望まれます。
3.端末によって言うことを聞いたり聞かなかったりするのツラい
基本的には、5G以前から沢山の可変タイマやエラー時のCauseが準備されており、
- 端末側からの接続試行リトライ数・リトライ間隔
- なんなら機内モードON/OFFや再起動しないと試行しない
といった端末の挙動はある程度制御できるように、”なっているはずです”。
しかし、実際にはすべての端末が仕様通りの動作をすることはなく、
といったことが多く、行儀の悪い端末は延々と無視してリトライしてくることも想定されます。かといって、IoT端末等は手動で再起動が容易にできないような環境にあることも多く想定され、延々とリトライを試みる機構を一方的に責めるのも…とも思います（せめてリトライ間隔ぐらいはちゃんと言うことを聞いてくれ…という気もしますが）
まとめ
以上が、5Gシステムの準正常・異常系試験を実施したときに感じたツラいポイントです。その他にも、アーキテクチャや機能面、RANの仮想化やコンテナ化って必須？みたいなツラいポイントもいずれまとめてみたいと思います。
