この記事は 3GPP TS38.300(V17.6.0)を読んでいく Advent Calendar 2023
の1日目の記事として執筆したものです。
その他の記事はQiitaのアドベントカレンダーページからどうぞ！
3GPP TS38.300(V17.6.0)を読んでいくのカレンダー | Advent Calendar 2023 - Qiita
はじめに
一日目ということで本カレンダーの趣旨を簡単に紹介します。
5Gに関する仕様は3GPPで標準化され、公開されています。
中でも、下記の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を読んでいきます。
RedCapってなんなの一問一答
Q.RedCap（ReducedCapbility）って何？
A.通常のUE（非RedCapUE）と比較して、対応機能を削ぎ落したUEのことです。Rel-17で仕様化されました。2024年から本格的に商用製品が世の中に登場する見込みです。
（ちなみに、RedCapという名称以前はNR-Lightという呼ばれ方もしていました）
ファーウェイが5GのRedCapを大規模商用化へ、23年末までに50超の製品発売 | 日経クロステック（xTECH）
軽量版5G「RedCap」は2024年後半に商用化へ、MediaTekがチップセット発表｜BUSINESS NETWORK
Q.何故機能を削ぎ落すの？ せっかく5Gで進化してるのに！
A.機能盛りだくさんだと、構造が複雑化してしまう（アンテナをいっぱい搭載するとか、CPUが熱々になるので冷却必須とか）のでコストも高くなりますが、全てのUEが機能盛りだくさんを必要としてはいない（特にIoTデバイスなど）ので、最低限の機能だけを実装して安く仕上げてバッテリーも長持ちさせようぜ！がコンセプトです。
Q.具体的にどんな機能が削がれちゃったの？
A.CA、MR-DC、DAPSハンドオーバーなどの機能が非対応です。
また、サポートする最大帯域幅やMIMO数については、下記の通りとなっており、スループット的にはあまり大きくありません（DL 150Mbps,UL 50Mbps程度想定）
- FR1:20MHz
- FR2:100MHz
- MIMO: DL 2Layer , UL 1Layer
- 半二重FDDもサポート
Q.IoTデバイスって具体的に何？
現状、WiFiやBlutoothしか搭載されていないことが多い、ウェアラブル機器やセンサ類がeSIM+RedCap対応でセルラー対応していく、といったイメージでしょうか。
その他、LPWA、NB-IoT、LTE Cat.1などのセルラーIoT規格の次世代規格としても期待されています。
2026年以降は、民生用途では、健康モニタリングなどができる5G接続のウェアラブル機器、産業用途では、産業データ収集や資産追跡用の低コストの無線センサー、スマートシティーやスマート工場向けの監視デバイスの使用が増えるとみられていることから、商用RedCapデバイスが急成長する見込みです。
5G時代の新たなセルラーIoT技術「RedCap」とは何か：2026年以降に市場が成長する見込み（3/3 ページ） - EE Times Japan
Q.どのくらいコスト削減になるの？
A.TR38.875 Study on support of reduced capability NR devices内で下記のように試算されています。例えば、最大帯域幅100MHzを代わりに20MHzとすれば、31.9%の削減につながるとしています。
以上がRedCapのサマリとなります。
毎度おなじみドコモテクニカルジャーナルでも触れられています。
以下ではさらに詳しく見ていきます。
RedCapUEをどう識別・制御するのか？
RedCap対応UEを用いて、RedCap対応のネットワークに接続したいとなったとき、
どのような手順でつながるのか見ていきます。いくつか手順（RACH手順の中で識別、UECapabilityから識別）が考えられていますが、RACH手順内における2つのパターンについて見ていきます（下図参照）
①RACH Msg1 based identification
前回解説したSIB1の中身の中に、いろんなIEが含まれていたと思いますが、
中でもinitialUplinkBWPについて、RedCap向けのものがRel-17で新たに定義されています。
SIB1の中身を見てみた（5GSA） - omusubi techblog
RedCapUEは、SIB1に上記が含まれている場合、このBWPを用いてRACH手順を実施することで、gNB側も識別することができます。
②RACH Msg3 (LCID) based identification
もう一つの方法は、Msg3（PUSCH）において、MACサブヘッダー内のLCIDで識別します。
LCIDの値一覧は下記表です。ここで、通常のUEであれば"52"、RedCap対応UEであれば"35"を選択します。これにより、gNBはRedCapUEであることを識別することができます。
その他SIB1拡張
SIB1に関してもRedCap向けのIEが増えています。
halfDuplexRedcapAllowedは該当セルの半二重FDDのサポート有無を表しています。
そのほか、1RX、2RX対応UEごとのアクセス規制が可能にするという使いどころが謎のIEも規定されています。
まとめ
次期IoT向け規格のメインストリームになるかもしれない？RedCapの仕様を見ていきました。単に機能を削いだUEというわけではなく、gNB側でRedCap対応UEであることを識別したうえで、半二重FDD適用や細かなアクセス規制などのRedCap対応UE向けの制御が行えるようになっていることが見て取れます。
