この記事では、2022年9月に行われた3GPP Plenaryのサマリ及び筆者の気になった寄書を紹介していきます。
3GPPとは何ぞやとか、寄書の眺め方については、過去の下記記事を参照下さい。
# ちなみに、今回の記事の内容もRANが多めです
Workplan/TImeline
[RP-221900 / CP-222012 / SP-220972]
Plenaryでは毎回Releaseのスケジュールも議論の項目になります。
2022/09時点では、下記のようです。
- Rel-17:仕様凍結は済んでいるものの、まだCorrection（修正）が必要な項目も多い
- Rel-18:2023/12の仕様凍結を目指して進行中。RANでは、3ヶ月後の2022/12 Plenaryで改めてRel-18のTimelineについては議論される予定
- Rel-19:SA1で検討開始。まだ大枠のTimelineは未定
ちなみに、Rel-18からは、5G-Advancedとしてロゴも少し変わっています。
LTEではLTE→LTE-Advanced→LTE-Advanced Pro と少しずつパワーアップしていきましたが、5Gの場合は次は6G的な新たな世代になるのでしょうか。この辺りもRel-20あたりから議論が始まるかもしれません。
その他、本格的なRel19以降の検討に向けたPlanningの寄書も何件かありました。
新たなReleaseの検討を開始するにあたっての順序としては、おおよそ3クォーターかけて下記のように決めていくようです。
- Workshopで各社の展望を語りつつ、テーマを絞り込む
- Releaseのテーマを決定する
- テーマをWI/SIに落とし込んで決定する
New WorkItem/StudyItem
今回の会合で承認されたWorkItem/StudyItemの中で、個人的に気になったものを
紹介していきます。
#Enhancement～や、～Phase2 等は基本的に過去の検討の続き感が強いので、ここでは#あまり取り上げていません
NR Network-controlled Repeaters (RAN Rel-18)
[RP-222673]
TR 38.867 Study on NR network-controlled repeatersでの検討をもとにしたWorkItemで、従来から検討されているカバレッジ拡張方式のひとつ、RFリピータをさらに拡張し、Network-controlled repeaterとして定義し、その方式を検討しています。
似たようなカバレッジ拡張技術としてIAB(Integrated Access and Backhaul)も議論されていますが、RFリピータは簡単に言うと、電波を増幅して中継するアンプであるのに対し、IABは基地局-基地局間を基地局-UEと同じように結び、その回線をバックホール回線として用いる規格です。
Network-controlled repeater のコンセプト図を下記に示します。
Control link (C-link)は、NR-Uu上で伝送され、NCR-MTによってNCRを制御します。
NCR-FwdはBackhaul linkとAccess linkを介して、RFの増幅アンプとして機能します。
NCRは、例えばC-linkを介して電源ON/OFFや送信電力制御を行うことで、状況に応じた
SINRの改善（干渉影響の軽減）やカバレッジ拡張を柔軟に行えようになる、としています。
※特に、FR2のミリ波のような基地局に対して有効な気がします
High power for FR1 for FDD single band(s) with power class 2 (RAN Rel-18)
[RP-222083]
現状のUEの最大送信電力はグローバルで見ても、23dBmが標準となっていますが、
過去、アップリンクのカバレッジ向上を目的に、LTE-TDD B41(2.5GHz)での高出力UE(HPUE)等が検討されてきました。
https://www.kiai.gr.jp/jigyou/h30/PDF/0606p1.pdf
TR 38.861 Study on high power UE (power class 2) for one NR FDD bandでは、低い周波数の NR FDDバンドn1,n3へのHPUE適用に向けた検討を行ってきましが、このWorkItemではさらにn8,n28等のNR FDDバンドへのPower class 2 (26dBm)適用に向けた下記のような検討も行っていきます。
- 帯域固有のRF要件
- UE最大出力電力とTx電力許容値
- A-MPR（AdditionalMaximumPowerReduction）要件
- Power class 2の感度劣化要件
※HPUEは、UE~衛星までの距離が課題であるNTNへの適用も十分あり得そう
5G System with Satellite Backhaul (SA Rel-18)
[SP-220808]
TR23.700-27 Study on 5G System with Satellite BackhaulをもとにしたWorkItemです。
NTNと少し違った観点で、gNBのバックホール回線として衛星が用いられる場合の様々な検討が行われています。例えば、複数の衛星をバックホール回線として用いる場合のPCC/QoSに基づく経路選択や、UPFが衛星に搭載された場合のEdgeComputing、UE間の折り返し通信の実現に向けた方式検討が行われています。
※NTNの方でもUPF搭載シナリオを検討しても良い気がしますね
Timing Resiliency and URLLC enhancements (SA Rel-18)
[SP-220814]
TR 23.700-25 Study on timing resiliency and TSC and URLLC enhancements をもとにした
WorkItemです。こちらは、以前にも少し触れたIIoT(Indsutrial IoT)関連の検討となります。
この分野ではRel-15の頃から、産業用イーサネットやOTと呼ばれるネットワークと、5Gシステム統合を目指しています。具体的には、TSN (Time-Sensitive Networking)と5Gシステムとの統合に向けた検討を以前から実施していて、Rel-17の頃からは関連の深いURLLCも含めた検討となっています。
Rel-18の今回では、主に下記の議論が中心となるようです。
- GNSS障害時に5Gシステムが自走し、5Gシステムがバックアップとして機能し、他のアプリケーション向けに無線および屋内対応の時間同期サービスを提供するための要件を規定する
- 低遅延と低ジッターをサポートするために、TSNトランスポートネットワークと相互運用するための拡張
- アプリケーションからのバースト送信を調整するための フィードバック対応（例：RANでのバッファリングを避けるためにアプリケーションがDLパケット送信タイムスロットを検討するなど）
- 5GSが低遅延（例：2ms）要件を満たすために、アプリケーションがダウンストリームスケジューリングを適応させるメカニズムをサポートする
※5G-TSN統合はRel16で基本的な機能が標準化されましたが、まだまだ本格的な実装・運用に向けては検討課題が多そうな印象です
今回取り扱われなかったWI提案(RAN Slicing)
[RP-222444][RP-222355]
further enhancement of RAN Slicing for NR
個人的に追いかけているRAN slicingの項目です。RANにおけるSlicing検討は
Rel-17にてStudyItemが検討され、TR38.832にてまとめられています。
#こちらは別途解説記事を執筆予定です。
Rel-17において、上記はWIとしても検討され、
- スライスベースのセル再選択
- スライス毎のRACH優先付け
がサポートされます。ただし、サービス継続性（ハンドオーバなど）の実現ついては、UEとコアの両方にも影響があり、さらなる調査・検討が必要とされました。
そこで、Rel-18ではさらなる拡張として下記を検討すべきとしています。
- 端末トリガーによるスライス認識セル再選択をサポートするためのメカニズムおよびシグナリングを規定する
- サービングセルがサポートしないスライスについて、DCまたはCAを設定することにより、UEが意図するスライスにアクセスすることをサポートするメカニズムを規定する
- 基地局間移動シナリオの場合、ターゲット 基地局がサポートしないスライスについて、TR 38.832 のセクション 6.2.1 に記載されているように、ターゲット基地局側で再マッピングするため方式検討
と言った具合に、いわゆるE2Eスライシングを実現するために必要と思われる、
基地局間を移動した場合でもRAN含めたスライスベースの制御を実施する、という部分の検討がRel-17では未検討であるため、Rel-18でも継続議論が必要、という主張のようです。
※ZTE,CMCCといった中国勢しか熱心では無いようで、今回も取り扱われず承認には至りませんでしたが... その他ベンダは、E2Eスライシング実現でロックインするため、実装マターにしておきたいのかも？
Status Report
絶賛議論中の項目の各WGにおける検討状況をサマった寄書たちです。
Status report for SI: Study on enhancement for resiliency of gNB-CU-CP
[RP-222250][RP-222271]
こちらは、丁度RAN3での検討が完了し、TRのドラフトも寄書・承認されていましたので、TRの内容を見ていきます。
TR38.879 Study on enhancement for Resiliency of gNB-CU-CP
一口にgNBといっても、5Gではfunction splitの観点から、gNB-CU/gNB-DUに分割されます。そして、gNB-CUはさらにC-plane担当のCUCPとU-plane担当のCUUPに分割されます（CUPSとも言われたりします）
標準上は、ひとつのgNB-CU-CPに対して複数のDUが接続されることも想定されており、下図のようにCU-CPは複数のDU、AMF、隣接するgNBのCU-CPと多数のノードと接続されることが想定され、かつ単一障害点にも見て取れます。
CU-CPに障害が発生すると、すべてのユーザ通信に影響が出る可能性があることから、
本項目ではCU-CPの障害シナリオを検討します（解決策は本項目では取り扱わない）
障害シナリオとしては、大きく下記を検討しています。
- Hardware failure
- Software failure
- Transport network failure
- Power failure
- RAN node breakdown, e.g., due to natural disaster
各シナリオについて、具体的な影響部分も含めたシナリオを議論しています。
例えば、Transport network failureによる、gNB-CU-CP～DU間のSCTP断（F1AP断）
などが挙げられています。
このStudyItemでは障害シナリオのみの検討でしたが、解決策についても今後議論される可能性が高いと思われます。
