3GPP Release 19における産業創出・ソリューション協創向け高度化技術

01. まえがき

3GPP（3rd Generation Partnership Project）*1では，第5世代移動通信システム（5G）の技術検討がRelease 18（以下，Rel-18）まで進められてきた[1]．従来の移動通信サービスに加え，スマートファクトリー*2や各種IoT（Internet of Things），コネクテッドカー*3，新カバレッジの開拓など，さまざまな産業や社会を支えるユースケースの実現をめざした無線技術が仕様化されている．
Rel-19では，極めて低消費電力な端末特性を前提とした新たなIoT利用形態の実現，産業・サービス創出を支える屋内通信環境およびネットワーク構成の高度化，ならびに従来の通信カバレッジ外を含む多様な環境における通信性能の向上および通信領域の拡張を目的とした検討を通じ，より多様で実用的な産業連携ソリューションの実現をめざした仕様化が進められた．本稿では，これら産業連携ソリューションの実現を支える3GPP Rel-19の無線アクセス関連技術について解説する．

02. 産業連携ソリューションの検討背景

2.1 超低消費電力・電池レスデバイスを活用したIoTユースケースの拡大

3GPPにおける移動通信向けIoTは，用途ごとに求められる通信性能・端末コスト・消費電力の違いに対応する形で段階的に拡張されてきた．LTE Rel-13では，低速・小容量通信を対象にLTE eMTC（enhanced Machine Type Communication）*4およびNB-IoT（Narrow Band-IoT）*5が仕様化され，狭帯域化や繰返し送信などにより，広いカバレッジと10年以上の電池寿命を実現するローエンドIoT基盤が確立された．
5G導入後は，LTE eMTCと，モバイルブロードバンド高度化技術（eMBB：enhanced Mobile BroadBand）*6や低遅延通信技術（URLLC：Ultra-Reliable and Low Latency Communications）*7といった5G NR（New Radio）*8端末との間に位置する，中速・中コスト帯のIoT需要が顕在化した．これに対応するため，3GPP Rel-17において，送受信帯域幅やアンテナ数，MIMO（Multiple Input Multiple Output）*9機能などを削減したRedCap（Reduced Capability）*10端末が導入された[2]．RedCapは，eMTCより高いデータレートを必要とする産業センサやウェアラブル端末などを想定し，5G NRをベースにしつつ端末複雑性を抑える位置付けである．続いてRel-18では，RedCapに対してピークデータレートをさらに制限し，省電力性と低コスト性を一層重視したeRedCap（enhanced RedCap）*11が仕様化された[1]．eRedCapは，NB-IoTとRedCapの間に存在していた通信性能・端末コストのギャップを埋める役割を担う．
これらRedCap/eRedCap端末については，地上系ネットワークに加え，衛星などを用いた非地上ネットワーク（NTN：Non-Terrestrial Network）*12における利用も想定されており，Rel-19ではNTNにおいてRedCap/eRedCap端末をサポートするための仕様整備および必要な機能拡張が行われた．これにより，広域・遠隔地においても中速・低消費電力IoT端末を用いたサービス展開が可能となる．
さらに，電池レスまたは極小エネルギーのみを蓄え，環境中の電波・光・熱・振動などから得られる微小エネルギーを用いて動作する超低消費電力IoT端末をセルラシステムに統合することを目的とした新技術として，A-IoT（Ambient IoT）*13の検討がRel-18より開始された．Rel-18では，SA1（Service and System Aspects Working Group 1）およびRAN（Radio Access Network）*14において，A-IoTに関するユースケース，要求条件，トラフィック特性，設計目標などが整理され，これらに基づいてRel-19では，在庫管理や簡易制御を代表例とするユースケースを対象に，A-IoT向け無線アクセス技術の本格的な仕様化が進められた．Rel-19において仕様化されたA-IoTデバイスは，μW級のピーク電力で動作し，能動的な送信を行わず，外部から供給される搬送波を後方散乱方式*15により送信する点を特徴とする．これにより，NB-IoTやeMTCと比べて，消費電力・端末コスト・端末サイズを大幅に低減することが可能となり，既存のセルラIoTよりも大規模な端末展開が期待される．図1に示すとおり，A-IoTの位置付けは，既存のセルラIoTでは対応が困難な超ローエンドIoT領域をカバーすることである．

2.2 産業・サービス創出を支える屋内通信環境およびネットワーク構成の高度化要求

近年，デジタルトランスフォーメーション（DX：Digital Transformation）の進展に伴い，工場，オフィスビル，商業施設，医療機関，物流倉庫などの屋内環境において，高度な通信インフラへの需要が急速に高まっている．従来のマクロセル*16を中心としたモバイルネットワークでは，電波は建物による遮蔽や構造の影響を受けやすく，屋内において十分な通信品質を確保できないケースが多い．特にミリ波*17などの高周波数帯を利用する5Gでは，この課題がより顕著となる．このような背景から，小規模なネットワークエリアを形成するフェムトセルを活用した屋内ネットワークの高度化が注目されている．これらのニーズを踏まえ，3GPP Rel-19では5G Femto*18に関する検討および仕様化が進められた．

2.3 空・海・山間部を含む非地上・非固定環境における通信およびレジリエンス要求

3GPPにおける非地上・非固定環境向け通信技術は，従来の地上ネットワークでは通信インフラの整備や，十分な通信品質および可用性の確保が困難であった利用シーンを対象に，Rel-17以降，段階的に拡張されてきた[1][2]．このような環境において必要な通信手段を確保することは，産業活動の継続性や社会インフラの強靱化の観点から，ますます重要になってきている．
Rel-19では，広域を移動する端末を対象とした海上・空中での通信，山間部や離島など地上ネットワークのカバレッジ外における接続性の確保，ならびに災害時やインフラ障害発生時における代替通信手段としての利用を主な対象として，NTNおよびWAB（Wireless Access Backhaul）*19の検討が進められた．
Rel-19のNTNでは，多様な衛星システムや接続形態への対応，上りリンク（UL：UpLink）*20容量の拡大，マルチキャスト通信のサポート，前述したIoT端末への対応などを通じ，実利用を見据えたNTNの普及に向けた仕様化が行われた．一方，WABでは，地上ネットワークと連携しつつ，臨時設置や可搬型展開可能とする柔軟なネットワーク構成が仕様化され，非常時や一時的な需要の集中が生じる利用シーンにおいても，迅速に通信サービスを提供する役割を担うことが期待される．

03. 産業連携ソリューションを実現する要素技術

3.1 A-IoT向け無線アクセス技術

Rel-19では，A-IoTデバイスと，無線インタフェースを介してデバイスに接続する基地局（リーダ*21）との間の最大通信距離について15m程度をターゲットとし，運用シナリオを屋内環境に限定している．Rel-19で仕様化されたA-IoTデバイスは，送受信の増幅器*22をもたず，また自身で搬送波を生成せず，外部から与えられる搬送波を反射変調する後方散乱方式により送信することで，最大消費電力約1μW級の省電力化を図る．
リーダからA-IoTデバイスへのリンクをR2D（Reader-to-Device），A-IoTデバイスからリーダへのリンクをD2R（Device-to-Reader）と定義し（図2），R2D・D2Rそれぞれにおける物理レイヤ*23・MAC（Medium Access Control）*24レイヤの動作，RANアーキテクチャおよびRF（Radio Frequency）*25／無線リソース制御（RRM：Radio Resource Management）*26要件と試験規定が仕様化された．なお，A-IoTはFR1（Frequency Range 1）*27帯の周波数分割複信（FDD：Frequency Division Duplex*28）バンドにおける運用が想定され，R2DはFDDの下りリンク（DL：DownLink）*29バンド，D2RはFDDのULバンドで送信される．
(1)物理レイヤ仕様
①物理レイヤの基本設計
・R2D
基地局が送信するR2Dの送信波形としてはDFT-s-OFDM（Discrete Fourier Transform- spread-Orthogonal Frequency Division Multiplexing）*30が採用され，将来的な屋外運用への拡張を見据えて既存NRとの共存を意識する設計となっている．また，変調方式としてはRF包絡線*31検出といった簡易な受信機構成で検出可能なOOK（ON-OFF Keying）*32が採用された．
ここで，R2Dの物理レイヤ信号およびチャネルの構成を図3(a)に示す．R2D送信は，開始検出部（SIP：Start Indicator Part of R-TAS）*33とクロック取得部（CAP：Clock Acquisition Part of R-TAS）*34からなるタイミング取得信号（R-TAS：R2D Timing Acquisition Signal）*35，R2Dの物理チャネル*36として規定されたPRDCH（Physical Reader-to-Device CHannel）*37，終端信号（ポストアンブル）*38，およびパディング*39部から構成され，R-TASの開始点およびパディングの末尾はOFDMシンボル*40境界と揃えられることが規定されている．
PRDCHの生成手順については，まず，上位レイヤ*41のペイロード*42に対し，ペイロード長に応じた6ビットまたは16ビットのCRC（Cyclic Redundancy Check）*43を誤り検出のために付加する．これにビット0を「10」，ビット1を「01」に対応付けるマンチェスター符号*44を線形符号化として適用したものがPRDCHとなる．マンチェスター符号によってOOK波形における振幅の立上り・立下りを符号語*45中央に確保することで，A-IoTデバイスのクロック同期回復に資する設計となっている．
・D2R
A-IoTデバイスは，前述のとおり，外部から与えられる搬送波をOOKまたはBPSK（Binary Phase Shift Keying）*46により変調する後方散乱方式によってD2Rチャネルおよび信号を送信する．
ここで，D2Rの物理レイヤ信号およびチャネルの構成を図3(b)に示す．D2R送信は，D2Rの物理チャネルとして規定されたPDRCH（Physical Device-to-Reader CHannel）と，PDRCHの直前に送信されるD2R信号であるプリアンブル*47およびPDRCH中または末尾で送信される中間信号（ミッドアンブル）*48とから構成される．
PDRCHの生成手順については，まず，PRDCHと同様に上位レイヤのペイロードにCRCを付加する．続いて，上位レイヤにおいて指示に基づいて，CRCが付加されたトランスポートブロック*49単位での繰返し送信（繰返し係数最大2）と，誤り訂正符号（畳み込み符号*50）を選択的に適用する．PDRCHでは，リーダとA-IoTデバイスの送信電力差や後方散乱方式の反射損失によって，PRDCHと比較して通信品質が劣化するが，当該繰返し送信や誤り訂正符号によってこれを補償する．さらに，搬送波との干渉低減と周波数分割によるデバイス間多重を実現するため，搬送波中心周波数*51からの周波数シフト*52を適用する．周波数シフトは，OOKまたはBPSKにより変調されたシンボルを，時間領域*53において繰返し送信するといったベースバンド*54処理により実現される．
②タイミング同期と補正
A-IoTデバイスは低消費電力で動作可能なクロックを前提とするため，105ppmといった自走クロックの大きなサンプリングずれ（SFO：Sampling Frequency Offset*55）がある．そのため，A-IoTデバイスでは，一度同期した後の時間経過に伴う同期ずれが非常に大きく，既存NRのようなOFDMシンボル・スロット*56・フレーム*57といった同期の枠組みを前提とすることができない．そこで，前述のR2D/D2R信号を使用して，R2D/D2R送受信ごとにタイミング同期を確立する設計となっている．
R2D受信においては，A-IoTデバイスは前述のSIPの検出によりR2Dの送信開始点を特定し，CAPの受信によりSFO補正を行った後，続くPRDCHを復号する．さらに，A-IoTデバイスはポストアンブルを検出することで，R2D送信の終端を特定することができる．SIP，CAPおよびポストアンブルは，図3(a)に示される既知のOOK変調パターンとして仕様に規定されている．
また，D2R送信については，前述のプリアンブルとPDRCH送信に一定間隔で挿入されるミッドアンブルとを用いて，受信時のSFO推定や伝搬路推定をリーダ側で行う．プリアンブルは，リーダ側におけるD2Rの開始点の検出にも用いられる．プリアンブルおよびミッドアンブルには仕様に規定されるm系列*58が用いられる．系列長は31ビットと7ビットの2つが規定され，条件に応じて使い分けられるようリーダから指示可能となっている．
(2)上位レイヤの設計
A-IoTの無線上位レイヤにあたるA-IoT MAC*59レイヤはRel-19で新しく策定されたプロトコルである．徹底的な機能の簡略化がなされたため，NRの無線上位プロトコル（RRC（Radio Resource Control）*60,SDAP（Service Data Adaptation Protocol）*61,PDCP（Packet Data Convergence Protocol）*62,RLC（Radio Link Control）*63,MAC）との相違点は多い．例えばA-IoTにおいてA-IoT MACは無線上位レイヤを構成する唯一のプロトコルであり，他の無線上位レイヤであるPDCPやRLC，RRCなどといったプロトコルは存在しない．また，制御信号を伝送する場合とデータを伝送する場合とで同一のプロトコルスタック*64を用いる．NRのRRCレイヤのように端末の接続状況（state）を端末個別に管理することもせず，ハンドオーバ*65処理も存在しない．また，ユーザデータに対するセキュリティ保護も行っていない（ただし，無線レイヤ*66よりも上位のレイヤであるA-IoT NAS（Non-Access Stratum）*67ではセキュリティ保護を行っている）．
Rel-19におけるA-IoT MACレイヤがサポートする機能は①A-IoTページング*68，②A-IoTアクセス手順，③A-IoT上位レイヤデータ伝送，④失敗検知，の4つであり，これらはA-IoTサービスの制御およびA-IoT NASメッセージの伝送を行うために必要最低限の機能である．それぞれの機能の詳細を以下に述べる．
①A-IoTページング
Rel-19のA-IoTシステムは，DT（Device-Terminated）*69およびDO-DTT（Device-Originated Device-Terminated Triggered）*70のトラフィックタイプをターゲットとした．従って，A-IoT MACレイヤの動作手順は，常にリーダがA-IoTデバイスに対してR2Dメッセージ*71を送信することによって始まる．Rel-19では，このA-IoT MACレイヤの動作手順を開始するR2Dメッセージを，A-IoTページングメッセージとして定義している．
A-IoTページングメッセージを受け取ったA-IoTデバイスは，メッセージ内のページングIDを読むことで自身がA-IoTページングの対象になっているかどうかを判別する．また，A-IoTデバイスはA-IoTページングメッセージ内の無線リソース情報（スケジューリング情報およびアクセス機会の数）を基に，次のD2Rメッセージを送信する．
②A-IoTアクセス手順
Rel-19 A-IoTは，CBRA（Contention-Based Random Access）*72とCFA（Contention-Free Access）*73の2種類のアクセス手順をサポートしている．手順の選択権はリーダにあり，選択結果をA-IoTページングメッセージの中でデバイスに通知する．CBRAとCFAのA-IoTアクセス手順を図4に示す．
CBRAでは，まずデバイスがA-IoTページングメッセージの内容を基にD2R無線リソースを選択し，アクセスランダムIDメッセージを送信する．なおデバイスには十分に正確なクロックが内蔵されていないため，時間同期を行う代わりにリーダがアクセストリガメッセージを複数回送信し，デバイスは受信したアクセストリガメッセージの回数を基に送信タイミングを決定する．アクセスランダムIDメッセージは，16ビットの乱数で構成されている．アクセスランダムIDメッセージの受信に成功したリーダは，その中に含まれていた乱数をコピーし，D2Rスケジューリング情報とともにランダムIDレスポンスメッセージを送信する．その後，デバイスは，自身が送信した乱数を含むランダムIDレスポンスメッセージの受信を試みる．当該メッセージの受信に成功したとき，CBRA手順は成功したとみなされ，A-IoT上位レイヤのデータ伝送へ進む．
CFAでは，A-IoTページングメッセージを受信し，A-IoT上位レイヤデータ伝送へ進む．
③A-IoT上位レイヤデータ伝送
A-IoTアクセス手順後の最初のA-IoT上位レイヤのデータ伝送は，CBRAの場合にはランダムIDレスポンスメッセージにおいて，CFAの場合にはA-IoTページングメッセージにおいて，それぞれ通知されるスケジューリング情報に従って実行される．
A-IoT MACは，上位レイヤすなわちA-IoT NASレイヤのデータをD2RとR2Dとの双方向で伝送する機能をもつ．なおA-IoTは，NRと異なり，アプリケーション上で生成したユーザデータを，NASレイヤを介して送信する．従って，A-IoT MACはNASレイヤの制御信号だけでなく，ユーザデータも伝送する機能である．
R2D方向に送信する際，リーダは，R2D上位レイヤデータ送信メッセージを用いる．このメッセージには対象のデバイスを指定するためのAS（Access Stratum） ID*74が含まれるが，デバイスがアクセスランダムIDメッセージで送信した乱数，またはリーダが割り当てたIDが，AS IDとして使用される．
D2R方向に送信する際，A-IoTデバイスは，D2R上位レイヤデータ送信メッセージを用いる．A-IoTアクセス手順の直後の送信時を除いて，A-IoTデバイスは，直前のR2D上位レイヤデータ送信メッセージの中で通知されるスケジューリング情報に従って，D2R上位レイヤデータ送信メッセージを送信する．A-IoT MACは，D2R方向の場合に対してのみ，メッセージ分割機能をサポートしている．A-IoTデバイスは，上位レイヤメッセージのサイズが，割り当てられたD2R無線リソースで送信可能なサイズよりも大きい場合，上位レイヤメッセージを分割して送信することができる．
④失敗検知
A-IoT MACは，CBRAアクセス手順とD2R上位レイヤデータ伝送の失敗検知機能をサポートしている．A-IoTデバイスがCBRAアクセス手順を実行中に新しいA-IoTページングメッセージを受信したとき，A-IoTデバイスは実行中の手順が失敗したとみなす．また，A-IoTデバイスがD2R上位レイヤデータ送信メッセージの送信後にNACK（Negative ACKnowledgement）*75フィードバックメッセージを受信したとき，A-IoTデバイスは伝送が失敗したとみなす．
(3)RANアーキテクチャの設計
Rel-19のA-IoTでは，既存の5Gアーキテクチャに存在するgNB（gNodeB）*76がA-IoTのリーダとしての機能を提供する．一方で，5GC（5G Core-network）*77の中にAIOTF（A-IoT Function）*78と呼ばれる新規ノード*79が導入された．AIOTFはA-IoTデバイスとの間でNASメッセージのやり取りを行うノードであるが，そのNASメッセージの仲介を行うgNBとの間にNG-C（Next Generation-Control Plane）インタフェース*80を介することになっている．なお，gNBとAIOTFの間の接続については，直接接続およびAMF（Access and Mobility management Function）*81を介した間接接続が選択できる．
Rel-19 A-IoTに対応するgNBは，以下の機能をサポートする．
・インベントリ*82要求：AIOTFがgNBに対し，A-IoTデバイスに対するインベントリ実行を要求する．gNBは要求に基づき，適切なターゲットを設定して無線インタフェース上でA-IoTページングメッセージを送信する．
・インベントリ報告：gNBがAIOTFに対し，直前に要求されたインベントリの実行結果を報告する．
・コマンド*83要求：AIOTFがgNBに対し，コマンドをA-IoTデバイスに対して伝送するように要求する．gNBは要求に基づいて無線インタフェース上でR2D上位レイヤデータ送信メッセージを送信し，その後，A-IoTデバイスから受信したD2R上位レイヤデータ送信メッセージから抽出したNASメッセージを，AIOTFに転送する．
・A-IoTセッション*84解放：AIOTFがgNBに対し，実行中のセッションを終了し，A-IoTデバイスに関する情報を解放するように要求する．gNBはセッション解放が完了した後，AIOTFに対して完了報告メッセージを送信する．なお，gNBからAIOTFに対してセッションの解放を要求することもできる．
(4)RF/RRM要件と試験規定
前述のとおり，A-IoTデバイスは105ppmといった自走クロックの大きなSFOが前提となる．このようなハードウェア制約に対応するため，RAN4ではA-IoTデバイス向けのRFおよびRRM要件に加えて，基地局や搬送波ノード向けのRF要件を新たに規定した．ここで搬送波ノードとは，A-IoTにおいて新たに規定された構成要素であり，デバイスが後方散乱通信を行うための無変調の搬送波を供給する役割を担う（図2）．
A-IoTデバイスについては，RF要件として，この通信方式に特化した後方散乱電力要件や不要発射*85要件が規定された．さらにRRM要件として，上位レイヤ設計で示されたCBRAおよびCFAに基づく任意接続手順を確実に行うための規定や，A-IoTデバイスのハードウェア制約を考慮した規定が定義されている．
具体的には，A-IoTデバイスは自走クロックの精度が低くSFOが大きいため，D2R送信の開始タイミングについての基準となる時間からの誤差に対する要求は10％以下と規定され，従来の端末の送信に対する要求と比較して緩和されている．この基準時間は，当該D2R送信をトリガするR2D送信における最後のOOKシンボルのエッジ（立上り／立下り）から，D2R送信開始までの時間を指す．
さらに，A-IoTデバイスの処理能力を考慮し，D2R送信終了後から一定区間は次のR2D受信を監視しなくてよいという免除規定が設けられている．この区間は，10マイクロ秒とD2Rチップ長*86の3倍の値のうち，いずれか大きいほうの値として定義される．
また，外部からの給電や微小コンデンサで駆動するA-IoTデバイスを適切に評価するため，電波暗室*87を用いた新たな空間伝搬（OTA（Over-The-Air）*88）試験手法も規定されている．
一方，基地局および搬送波ノードに対しては，無変調の搬送波送信に伴う位相雑音*89要件や，OOK変調特有のRF包絡線（立上り／立下り時間や振幅変動など）に関する送信信号品質要件が規定された．併せて，これらの要件に基づく基地局および搬送波ノードの適合性試験仕様も策定されている．

3.2 多様な配置・接続形態を可能とする5Gトポロジ高度化技術

(1)WAB
WABノードは，基地局機能と端末機能を組み合わせた構成を特徴とする．具体的には，WABノードは，ユーザ端末に対してアクセス通信を提供する基地局機能であるWAB-gNBと，上位ネットワークへの接続を行う端末機能であるWAB-MT（Mobile Termination）から構成される．WAB-gNBは，従来のマクロセルを中心としたモバイルネットワーク向けに定義されるgNB機能[3][4]に基づいて構成される．一方，WAB-MTは端末機能の少なくとも一部をサポートし，無線リンク*90を介して上位ネットワークへ接続することで，WAB-gNBのバックホール*91通信を実現する役割を担う．
①アーキテクチャ
WABアーキテクチャでは，WAB-MTがNR無線インタフェースを用いてネットワークに接続し，その上で確立されたPDU（Packet Data Unit）セッション*92を利用したバックホールとして，WAB-gNBのトラフィックを転送する構成が想定されている．WAB-gNBはNR無線インタフェースを介して端末に対するアクセス通信を提供し，その制御プレーン*93およびユーザプレーン*94のトラフィックは，WAB-MTのPDUセッションを介して5GCへ転送される．この構成により，WAB-gNBのNGインタフェース*95およびXnインタフェース*96のトラフィックに加え，OAM（Operations,Administration and Maintenance）*97通信についても無線バックホール*98を介して伝送することが可能となる．
②ネットワーク確立手順
WABノードのネットワーク確立手順は，大きくWAB-MTの接続手順とWAB-gNBの起動手順の2段階で実施される．まず，WAB-MTは端末と同様の手順によってバックホールRANノードに接続し，RRC接続確立，認証および認可を経てバックホール用のPDUセッションを確立する．このPDUセッションは，WAB-gNBのトラフィックを伝送するバックホールとして利用される．続いて，WAB-gNBの初期化およびネットワーク接続が行われる．WAB-gNBはOAMによってAMF情報やセル構成情報などの設定を受信した後，AMFに対してNGインタフェース接続を確立する．NG接続の確立後，WAB-gNBは端末へのサービス提供を開始する．また，必要に応じてWAB-gNBはバックホールRANノードや周辺のRANノードとの間でXn接続を確立する．
③モビリティ制御*99
WABネットワークにおけるモビリティ制御に関しては，WAB-MTとWAB-gNBの双方について検討が行われている．WAB-MTのモビリティについては，従来端末向けに定義されたモビリティ手順をそのまま再利用する．
一方，WABノードの移動に伴い，WAB-MTのバックホールにおけるPDUセッションが再確立される場合，当該WABに配置されたWAB-gNBに関するNGインタフェース，Xnインタフェース，およびOAMトラフィックに用いるIPアドレスを更新する必要がある．ただし，IPsec（Internet Protocol Security）トンネルモード*100を利用している場合には，MOBIKE（IKEv2 Mobility and Multihoming Protocol）*101を適用することで内側IPアドレスの変更を回避できる．これ以外の場合には，NG-CインタフェースおよびXn-Cインタフェース*102については既存の手順に基づいて新しいIPアドレスへ移行し，NG-U（NG-User Plane）インタフェース*103のGTP-U（GPRS Tunnelling Protocol-User Plane）トンネル*104についても，既存のPDUセッションのリソース変更を通知する手順を用いて移行することができる．また，WABノードの移動中においても，WAB-gNBのOAM接続性を維持することが求められる．
一方，WAB-gNBの移動により，当該WAB-gNB配下の端末が接続すべきAMFが変更される場合には，新たな論理WAB-gNBを生成し，新AMFとの間でNG接続を確立する方式が採用されている．新しい論理WAB-gNBは，WABノードの現在位置に応じてOAMから新AMFへの接続に必要な設定を取得し，新たなTAC（Tracking Area Code）*105，セルID*106，PCI（Physical Cell Identity）*107をもつセルを起動する．RRC_CONNECTED状態*108の端末は，AMF再配置を伴うNGベースのハンドオーバにより，旧論理WAB-gNB配下のセルから新論理WAB-gNB配下のセルへ移行される．一方，RRC_IDLE状態*109またはRRC_INACTIVE状態*110の端末は，旧セルの停波などを契機として新セルを再選択し，新セルがブロードキャストする新TACに基づいてモビリティ登録更新を実施することで，新AMFへ移行する．すべてのRRC_CONNECTED状態の端末の移行が完了した後，旧AMFとのNG接続に対してNG削除手順が適用され，旧論理WAB-gNBのセルもサービスから除去される．
(2）5G Femto
5G FemtoノードはNR無線アクセスのみを提供する基地局として構成され，端末に対してNR接続を提供する．
①アーキテクチャ
5G FemtoノードはNGインタフェースを介して5GCに接続されるが，その接続方式として複数のアーキテクチャが検討された．最も基本的な構成は，5G FemtoノードがNGインタフェースを介して直接5GCに接続する方式である．この方式では，5G Femtoノードは，通常のgNBと同様にAMFおよびUPF（User Plane Function）*111と接続される．追加の中継ノードが存在しないため，制御プレーンの遅延が小さいという利点がある．一方で，大量の5G Femtoノードが直接5GCに接続する場合，コアネットワーク*112側で多数のSCTP（Stream Control Transmission Protocol）*113接続を管理する必要があり，スケーラビリティの観点で課題となる可能性がある．
この課題を解決する方式として，5G Femto GW（5G Femto GateWay）*114を導入するアーキテクチャが想定される．この構成では，5G Femtoノードは5G Femto GWに接続し，5G Femto GWがNGインタフェースを介して5GCと通信する．NR Femto GWは制御プレーンの集約ノードとして機能し，多数のNR Femtoノードを効率的に収容することを可能とする．この構成によりSCTP接続は5G Femto GWに集約されるため，5GC側で管理するSCTP接続数を削減でき，スケーラビリティの課題の緩和が期待される．また，この構成はLTEのHeNB Gateway*115を利用したフェムトセル運用モデルと類似しており，既存の運用ノウハウを活用できるという利点がある．
②セル構成
5G Femtoノードにより提供されるセル構成としては，複数の運用形態が想定されている．まず，最も基本的な構成として，5G FemtoノードがPLMN（Public Land Mobile Network）*116セルを提供する方式がある．この場合，当該セルは通常のPLMNセルとして動作し，既存の端末を含むすべての端末がアクセス可能となる．この方式は，特別な加入者制御を必要としない環境において利用される．
一方で，企業や施設内における専用ネットワークなどの用途では，非公開ネットワーク（NPN：Non-Public Network）*117セルとして運用することも可能であり，特に公共ネットワークと連携して構築されるPNI-NPN（Public Network Integrated-NPN）*118としての利用が想定される．この構成では，加入者情報に基づいたアクセス制御を実現するための仕組みが必要となるが，既存のCAG（Closed Access Group）*119メカニズムを活用することで，端末の契約情報に応じたアクセス制御を実現する．すなわち，5G FemtoノードはセルをNPNセルとして動作させ，当該セルが一般PLMN利用の対象外であることを示すCAG識別子をブロードキャストする．当該セルへの接続は，当該CAG識別子を許可リストとして保持する端末のみに制限される．そのため，企業ネットワークや施設専用ネットワークなどにおいて，契約端末のみが接続可能な閉域通信環境を構築することができる．
さらに，PLMNとPNI-NPNの双方に対応するハイブリッド構成も可能である．この構成では，5G FemtoノードがPLMNおよびNPNの識別情報を同時にブロードキャストするセルを提供する．具体的には，SIB1（System Information Block Type 1）*120においてPLMN識別情報とNPN識別情報の両方を通知することにより，PLMN端末とNPN加入者端末の双方が同一セルに接続可能となる．この場合，セルは通常のPLMNセルとしても認識されるため，CAGに対応していない既存端末も利用可能である一方，CAGに対応した端末に対しては加入者情報に基づくアクセス制御が適用される．

3.3 NTNにおける無線アクセス高度化技術

NTNは，地上系ネットワークでは対応が困難なエリアや用途をカバーするための手段として位置付けられ，Rel-19ではその機能の高度化が進められている．Rel-19においてもRel-17/18のNTN仕様と同様に，中継局としては静止軌道（GEO：GEostationary Orbit）や低軌道（LEO：Low Earth Orbit）などの衛星および成層圏におけるHAPS（High Altitude Platform Station）*121などの飛行体が，端末としてはGNSS（Global Navigation Satellite System）*122機能を備えたVSAT（Very Small Aperture Terminal）端末*123およびスマートフォンなどの小型端末が，それぞれ想定されている．ただし，前述のとおり，衛星が備える機能や端末の形態，利用シーンについて，Rel-17/18と比較してより多様な構成が想定されている．それらの構成やNTNの普及に向けた仕様化について述べる．
(1)DLのカバレッジ改善
Rel-17/18 NTNでは，地上系ネットワーク向けに仕様化されているDLのチャネルおよび信号の構成，ならびにそれらに関連する動作について，原則としてそのままNTNにも適用可能であることが想定されてきた．一方で，これらの検討は，比較的高機能な構成を有する衛星を前提として進められており，実ネットワークにおいて想定され得る，中機能あるいは低機能な構成の衛星を用いた場合には，DLのチャネルおよび信号構成や関連動作が必ずしも十分ではないことが明らかとなった．
そこでRel-19 NTNでは，こうした構成の衛星を想定し，DLの通信品質改善を目的として，以下の2種類の仕様化が行われた．
①各種DLチャネル・信号への繰返し送信の適用
衛星のビーム当りの送信電力には制約が存在し，その結果として得られる受信強度が，必要とされる通信品質を満たさない場合がある．しかしながら，Rel-18までの仕様においては，システム情報取得やランダムアクセス*124，ページングなどに用いられるDL制御チャネル（PDCCH：Physical Downlink Control CHannel）*125や，SIB1用のDLデータチャネル（PDSCH：Physical Downlink Shared CHannel）*126，ランダムアクセスにおける第4メッセージ（Msg4）*127用のPDSCHに対して，繰返し送信を適用することができなかった．
そこでRel-19では，これらのチャネルおよび信号に対して繰返し送信が新たに仕様化され，通信品質の向上が図られた．PDCCHへの繰返し送信の適用は，DLブロードキャストチャネル（PBCH：Physical Broadcast CHannel）*128やシステム情報を介して事前に端末に通知される．一方で，Msg4用のPDSCHへの繰返し送信の適用は，対応するDL制御情報（DCI：Downlink Control Information）*129を介して，送信ごとに動的に通知される．それぞれの実施例を図5に示す．
②同期信号ブロック（SSB：Synchronization Signal Block）*130の周期拡張
衛星において同時に利用可能なビーム数にも制約があるため，送信周期が20msと短い初期アクセス用のSSBについて，すべての衛星ビームに対して一律に送信することが困難となる場合がある．例えば，衛星が同時に利用可能なビーム数が40個であり，さらに1,000個のビーム照射によるエリアをカバレッジとする場合，それぞれのビームを介したSSBの送信について，すべてのビームのSSB送信を完了するためには25msを要する．すなわち，当該衛星を介した通信を継続的に行うことは不可能であった．
Rel-19ではSSBの送信周期として160msが新たに追加され，これにより，それぞれのビームを介したSSBの送信について，上記の例においてもすべてのビームのSSB送信が可能となるとともに，残りの135msにおいて他の送受信を実行することができる．本機能の概要を図6に示す．
(2)ULのキャパシティ改善
NTNでは，カバレッジ内に多数の端末が同時に存在し得ることや，利用可能な帯域幅が限られること，さらにRel-18で仕様化された端末繰返し送信の適用に起因し，ULの容量がひっ迫することが想定されている．すなわち，時間領域または周波数領域*131でリソースを分割する従来の多元接続*132方式のみでは，多数の端末を効率的に収容することが困難である．
そこでRel-19では，同一の時間領域および周波数領域のリソースを複数の端末のPUSCH（Physical Uplink Shared CHannel）*133送信に割り当て，直交カバー符号（OCC：Orthogonal Cover Code）*134を適用した符号領域多重により，端末間の分離を実現する．NTNのUL向けに仕様化されたOCCは，繰返し送信を前提として，複数スロットにわたって乗算される．OCCの長さは2または4であり，OCCの適用有無，OCC長およびOCC系列は，PUSCHをスケジューリングするDCIを介して，送信ごとに動的に通知される．
(3)配信サービスサポート
Rel-17で地上系ネットワーク向けに導入されたマルチキャスト・ブロードキャスト機能*135をNTNセルで実行する際，NTNセルのカバレッジの広さが原因で，ネットワーク事業者の意図する地理的範囲を超える範囲に情報が配信される点が課題であった．
そこでRel-19では，NR-NTNセルで利用可能な新しい報知情報ブロック*136（SIB27）を導入し，マルチキャスト・ブロードキャストサービスが意図する配信対象のエリア情報を報知することができるようになった．
また，ETWS（Earthquake and Tsunami Warning System）*137を配信する際に，すでにCMAS（Commercial Mobile Alert System）*138がサポートしているのと同じように，緊急情報の対象となるエリアを指定できるようになった．なお，ETWSの対象エリアを指定する機能は，NTNセルに限らず，地上系ネットワークのセルでも使用することができる．
(4)再生中継型通信のサポート
Rel-18以前のNTNシステムは，地上にあるNTNゲートウェイ*139がgNBの機能を搭載し，衛星内の中継局はUL・DL両方の信号に対して周波数シフト・増幅のみを行って中継する透過中継型（transparent payload）のアーキテクチャを前提としていた．Rel-19では新たに，衛星内にgNBの機能を搭載する再生中継型（regenerative payload）のアーキテクチャをサポートすることが明確化された．
また，再生中継型の導入によってgNBが衛星とともに上空を移動する構成となることから，フィーダリンク*140の切替えに伴って，gNBが接続する先のAMFが切り替わることになる．このようなAMFの変更をスムーズに行うため，NGインタフェースを削除する機能が導入された．
(5)RedCap/eRedCap端末サポート
前述のとおり，Rel-19において，RedCap/eRedCap端末をサポートするための仕様整備および必要な機能拡張が行われた．具体的には，端末のRF要件の定義および半二重FDD*141の端末向けの動作規定が行われた．
①端末のRF要件の定義
端末のRF要件としては，地上系ネットワーク向けの規定と同様に，データチャネルの帯域幅や端末受信系統数，複信方式*142などに応じた受信性能要件が定められている．
また，LEO衛星は地上に対して高速で移動するため，カバレッジが動的に変化し，端末には迅速なセル再選択やハンドオーバが求められる．しかし，RedCap/eRedCap端末はベースバンドの処理能力が低く，特に半二重FDD動作時には送受信の衝突によって測定機会が減少する．
この課題に対して，NTN特有の長大な伝搬遅延を考慮した測定ウインドウの調整や，測定機会の喪失を前提としたセル探索および無線リンクモニタリング（RLM：Radio Link Monitoring）*143の測定期間の延長要件を規定した．さらに，これらを含むハンドオーバなどのモビリティ要件全般において，アンテナ数が1Rxと2Rxの端末間で生じる受信能力の差異を考慮し，種々の信号測定の精度や各種処理遅延の許容値を個別に規定している．これにより，デバイスの制約とNTN特有のモビリティ性能の両立を図っている．
さらに，NTNにおける最大の技術課題である長距離伝搬に伴うタイミング管理についても，RedCap/eRedCap特有の要件が議論された．衛星の移動によって変化する伝搬遅延に対し，端末はTA（Timing Advance）*144を適切に維持する必要がある．そこで，RRC_INACTIVE状態などの省電力モードにあるRedCap/eRedCap端末がデータ送信を行う際に，端末自身がドップラーシフト*145や伝搬遅延の変化を予測してTAを補正する自律的なTA調整機能について，処理能力の低い端末に対して，どこまでの追従精度や送受信時間差の誤差を許容できるかが規定された．
②半二重FDDの端末向けの動作規定
RedCap/eRedCap端末の動作規定については，Rel-18までに策定された地上系ネットワーク向けの仕様を適用することが想定される．当該仕様には半二重FDDが含まれ，DL受信とUL送信が時間的にオーバラップした場合，それぞれのチャネルまたは信号の種別に応じて規定された動作が実行される．
ただし，地上系ネットワークにおいては，基地局が各端末のDL受信タイミングおよびUL送信タイミングを把握しているため，オーバラップしているDL受信およびUL送信の双方が準静的に設定されたチャネルまたは信号である場合（以下，ケースA），ならびに双方が動的にスケジューリングされたチャネルまたは信号である場合（以下，ケースB）については，基地局側で適切に回避されることが想定され，半二重FDDで動作する端末の動作は規定されていない．
一方で，NTNでは，端末の送信タイミングがその端末の位置情報に基づいて決定されるため，基地局が端末の正確な送信タイミングを常に把握することは困難である．そこでRel-19では，ケースAおよびケースBのそれぞれについて，半二重FDDで動作する端末向けの新たな動作が規定された．原則としてはDL受信が優先され，UL送信は実行されないが，基地局が必要と判断した場合には，UL送信を優先させるための設定を行うことができる．また，一部のチャネルおよび信号種別については，例外的に端末が自律的に動作を決定することが規定されている．

04. あとがき

本稿では，3GPP Rel-19における産業創出およびソリューション協創に向けた検討の背景と，それを支える主要な無線アクセス技術について解説した．Rel-20においてもA-IoTやNTNの拡張技術に関する検討が進められており，さらに6Gに向けた標準化議論も開始されている．ドコモは，引き続き5Gのさらなる発展と6G時代を見据えた標準化活動を通じて，産業連携ソリューションの創出に貢献していく．