この記事は、5GのNetworkFunction (NF)を解説していく Advent Calendar 2024
の1日目の記事として執筆したものです。
その他の記事はQiitaのアドベントカレンダーページからどうぞ！
5GのNetworkFunction (NF)を解説していく - Qiita Advent Calendar 2024 - Qiita
はじめに
一日目ということで本カレンダーの趣旨を簡単に紹介します。
モバイルシステムに関する仕様は3GPPで標準化され、公開されています。中でも、5Gに関して言うと、下記の3つが概要を記載していることから、よく言及されます。
TS23.501 System architecture for the 5G System (5GS) →5Gのアーキテクチャ
TS23.502 Procedures for the 5G System (5GS) →5Gにおける各種動作プロシージャ
TS38.300 NR and NG-RAN Overall Description →基地局・無線関連の概要
いずれも500ページを超えるような大長編かつ、概ね3ヶ月毎に改版されているため、これらを解説するような記事は、ほとんどありません。
今回は一昨年の、「5Gアーキテクチャの仕様であるTS23.501最新版を皆で読んでいく」、昨年の、「基地局・無線関連の全体概要を記したTS38.300を読んでいく」に引き続き3年目となりました。
今年のテーマを設定した理由の一つに、業界の動向として6Gについての議論が少しずつ始まっていることが挙げられます。
New 6G logo approved
WG SA1 6G Use Case Workshop
その議論の中で、6Gでは5Gの反省を活かしてNF (NetworkFunction)を減らしたり、よりシンプルな構成にすべきといった意見もしばしばみられます。
6G foundry: Rethinking the control plane | Qualcomm
ということで！そもそも5GのNFは今どれだけあるんや？本当にこれって必要なのか？を改めて認識するために、
今年は5GのNF一覧を眺めながら、各NFの役割を調べてみようと思います。
本記事のサマリ
- リリースを経るごとに増大するUE Radio Capability情報（UEが対応する周波数や機能一覧みたいなもの）のやりとりを削減するためにRACSとUCMFが新たに規定された
- RACS：新たに導入されたUE Radio Capability IDとそれを用いた手順のこと
- UCMF：UE Radio Capability IDと紐づくUE Radio Capabilityを保存・管理するネットワークファンクションのこと
- 中身全部を都度送るんじゃなくて、最初に端末ごとにID割り振ってやりとりはそれでやろうや！必要な時には、UCMFに保存されてるIDと中身の紐づけを照会する感じで！
UCMF一問一答
UCMFって何?
Rel-16で新たに追加されたNFです。UE radio Capability Management Function という名称にもあるように、RadioCapability (=端末のもつ能力。対応する周波数やMIMO数など)情報をやりとりする際のシグナリングを管理・最適化するために導入されました。
なんでそのシグナリングを最適化する必要があるの？
例えばですが、UE Radio Capabilityに含む情報は下記のように多岐にわたります。
- 対応周波数帯（Band）
- 変調方式（Modulation）
- 送信電力クラス
- MIMO対応レベル（アンテナ数）
- 帯域幅（Bandwidth）サポート
- 暗号化アルゴリズムサポート
- 完全性保護（Integrity protection）サポート
これをRegistrationの都度、UE→gNB→AMFに送信し、AMFで保存しています。
実際の信号は下記のAmarisoft製シミュレータのデモでも見ることができます。
Amarisoft Web Interface 2024-11-27
また、具体的にどのような情報が仕様として定義されているのかは、
TS38.306 User Equipment (UE) radio access capabilities
にて確認することができます。
確かに、実際の信号をみても、仕様を見ても、かなりの情報量があり、今後も増えていくと想定され、これをRegistrationの都度に送信するのはなかなかのリソース食いに見えます。
Sharetechnote先生の記事によると、下記のようにリリースが変わるごとに、リリース内でも版をかさねるごとに増えているのが見て取れます。
RACS (Radio Capability Signalling Optimisation)ってのもあったような？
はい、UCMFと密接に関わる機能としてRACSも同じくRel-16から導入されました。
The 3G4G Blog: UE Radio Capability Signaling Optimization (RACS) in Rel. 16
これは、UE Radio Capabilityの情報量が大きくなってきたことに対して、UE Radio Capability IDを導入し、UE Radio Capabilityの中身を都度やりとりするのではなく、情報量の少なくてすむ、IDをベースにしたやりとりに置き換えるという手段全体を指します。
したがって、UCMFは、RACSにおけるUE Radio Capability IDを管理するためのNFという理解でよいと思います。
具体的にUCMFの有無でどう手順が変わる？
UCMFの有無によるプロシージャの違いを簡単に下記に示します。
UCMF · Issue #2 · omusubi5g/mobile · GitHub
初回こそ変化はありませんが、以降のregistarationにおいては、UE~gNB~AMF間でUE Radio Capability の中身そのものが送信されることはありません。
これらは、registration以外にもハンドオーバー等でUE情報を転送する際にも有効であると考えられます。
UE Radio Capability IDが含まれる具体的なメッセージは？
新たなメッセージは無く、Registration RequestのIEとして含まれます。
これに対して、通常はPDUセッションの確立手前に、UE radio capabilty情報がやり取りされます。
どんな使い道が考えられる？
ひとつ思いつくのは、イベント会場等を含む混雑エリアに対する適用が考えられます。
混雑エリアでは頻繁に何らかの理由で（いわゆるRadioLinkFailureやタイムアウトなど）再接続が多く発生することが想定されますが、その際に各端末が都度UE Radio Capability を全部やりとりしてしまうのは、かなり無駄な無線リソース消費と考えられます。
1UEで見れば少ないかもしれませんが、100~1,000UEのオーダーで合算してみればかなりの量に、しかも制御信号なので、基本的にはユーザデータよりも優先されることが考えられます。
したがって、UCMFの処理能力や規模にもよりますが、局所的かつ一時的な適用に効果があるのでは、と考えます。
まとめ
今回は、今までほとんど内容を調べたことのなかったUCMFについて調査してみました。
シグナリング削減を目的としており、今までには無い斬新な手法、というわけでは全くないのですが、過去の世代から踏襲してきた部分の多いモバイルにおいては、過去からの積み重ねでパラメータや要素がどんどん増大しており、今までの方法をそのまま適用するのでは無駄が多い点がほかにもあるのでは？という気づきにもなりました。
最終日には、NEFの解説も予定しています。こちらは、APIを開放して、モバイルシステムをもっと他業界にも使い倒してもらおう！的な思想のNFというイメージですが、昨今の状況について調査してみたいと思います。ほかの方々のアドベントカレンダーも含め、ぜひご覧ください。
