3GPP Release 19における5GCの高度化技術概要　—システムアーキテクチャ—

01. まえがき

3GPP（3rd Generation Partnership Project）*1 SA（Service and System Aspects） Working Group 2*2 Release 19（以下，Rel-19）では，5G-Advancedの高度化を進めるとともに，将来の6G時代を見据えたAI活用，自律的なネットワーク運用，エネルギー効率向上への対応が重要な方向性となっているため，下記についての標準仕様が規定された．
・AI/ML（Artificial Intelligence / Machine Learning）*3を活用した高度なQoS（Quality of Service）*4/Policy決定，シグナリングストーム分析
・XR（Extended Reality）*5関連サービスへの暗号化トラフィック対応
・音声サービスへのなりすまし防止対策
・A-IoT（Ambient Internet of Things）*6システムの提供
・エネルギー関連情報開示機能の追加による効率化

本仕様を用いる5Gネットワークによって，さらに幅広いユースケースや高度なソリューションが実現できる．本稿では，これら標準化内容について解説する．

02. AI/ML機能拡張

2.1 背　景

ネットワーク運用の自動化・高度化に向け，5Gコアネットワーク（5GC：5G Core network）*7におけるAI/MLの活用が進んでいる．その中核を担うネットワークデータ分析機能（NWDAF：Network Data Analytics Function）*8はRel-15で導入され，Rel-16以降で表1に示すような機能追加が行われた．
またRel-19では，以下の4つの機能が追加された．
①AIベースによる位置測位のサポート
②プライバシー保護のため，異なる事業者やドメイン間でデータ交換をせずにモデル学習を行う垂直連合学習*9
③QoSをより効率的に決定するため，将来的な体感品質（QoE：Quality of Experience）*10を予測する分析機能
④通信事業者におけるネットワーク防御のために，突発的な信号量の増加を予測・検知する分析機能

本稿では，特にオペレーションへの活用が期待される，上記③④の2つの分析機能に焦点を当て，解説する．

2.2 ネットワーク分析

(1)QoSとPolicy支援分析
従来，QoSパラメータはPCF（Policy Control Function）*11が自身の情報（AF（Application Function）*12からの要求やNWDAFが提供する分析など）に基づいて決定していたが，この枠組みには2つの課題があった．
・1つ目は，PCFが理想的なQoSパラメータを導出するまでに，決定したパラメータがサービス要求を満たしているか設定後に確認し，満たせなければ再設定するという調整を繰り返す必要があり，最適なQoSパラメータを提供するまでに時間がかかることであった［1］．
・2つ目は，映像ストリーミングやV2X（Vehicle-to-Everything）*13・XRM（Extended Reality Media）*14のように高い品質要求をもつサービスではPDU（Protocol Data Unit）セッション*15の変更に伴い，5GC・RAN（Radio Access Network）*16・端末にわたる広範なシグナリングを要していたことであった．

これらの課題を解決するために，QoSフローの確立・変更に先立ってNWDAFでQoEを予測し，事後の再設定とそれに伴うシグナリングを抑えるための分析が規定された．
TS23.288は，新たに「QoSとPolicy支援分析」を定義した[2]．図1(a)に示すように，(a)-①NWDAFは，分析結果を利用するPCFから5QI（5G network Quality of service class Identifier）*17や遅延上限といったQoSパラメータの複数候補と，任意で要求するQoEを受け取る．また，AF・OAM（Operations, Administration and Maintenance）*18・5GCの各NF（Network Function）*19（セッション管理機能（SMF：Session Management Function）*20，AMF（Access and Mobility management Function）*21，ユーザプレーン機能（UPF：User Plane Function）*22など）が保持する既存の観測サービス体感分析やネットワーク性能分析も収集することができる．(a)-②次に，NWDAFはPCFから提示された候補に対して，それを適用した際に達成見込みのQoEを予測する［2］．このとき(a)-①で収集した既存のサービス体感分析やネットワーク性能分析を再利用することもできる．(a)-③NWDAFはPCFなどの分析の利用者に分析結果を渡す．(a)-④NWDAFから受け取った分析を基に，PCFは，所望のQoEの達成見込みの高いQoSパラメータを試行錯誤なしに選択し，Policyを導出し，(a)-⑤SMFに適用する．これにより，PCFは初回から適切なQoSを設定できるため，QoSの再設定に伴う遅延やシグナリングを削減できる．また，過剰なリソース割当を防ぎ，ネットワーク利用効率を向上できる．特にV2XやXRMのような高品質が求められるサービスでは，品質劣化を未然に防ぎながら，ユーザ体感と収容効率の両立を実現できる．
(2)シグナリングストームの分析
シグナリングストームとは，制御信号*23（シグナリング）の発生頻度が正常時の水準から大きく逸脱し，異常に増大することを指す［2］．例えば，停電復旧時に一斉接続を試みて多数のIoT端末が同時にデータを送信すると，特定エリアで短時間に大量の信号が発生する［1］．しかしながら，NFに起因する問題のみを扱う既存の分析（NF負荷情報，異常動作，分散型サービス妨害（DDoS：Distributed Denial of Service）*24の疑いなど）だけではシグナリングストーム検知に対処できないため，Rel-19でNF起因・端末起因の双方を統計・予測でとらえる新たな分析を規定した．
TS23.288では，新たに「シグナリングストーム分析」を定義した［2］．図1(b)に示すように，NWDAFはまず，(b)-①入力としてAMF・SMF・NRF（Network Repository Function）*25からの各種統計やNFプロファイル*26・負荷情報，運用保守系や管理データ分析機能（MDAF：Management Data Analytics Function）*27からの輻輳*28・障害予測情報，SCP（Service Communication Proxy）*29からの信号統計などを収集する．(b)-②次にNWDAFは異常な信号発生頻度の状態を統計または予測として提供し，その原因が多数の端末によるものか，NFの異常動作によるものかを分析する．(b)-③最後に，SMFやUPF，PCF，SCPといった分析結果を利用するNFは，分析に基づく措置を実行する．なお，NWDAFによる分析後の措置は例のみ定義されており，最終的に実行される措置は，オペレータのPolicyとNF・SCPの実装に委ねられている．

03. XRM機能拡張

3.1 背　景

Rel-18およびRel-19のXRM仕様には，AR（Augmented Reality）*30，VR（Virtual Reality）*31，MR（Mixed Reality）*32，クラウドゲーム，および5GS（5G System）上のマルチモーダル*33対話型サービスなど，高データレートかつ低遅延が求められるXRアプリケーションをサポートするためのメカニズムが導入されている．Rel-18では，PDU SetというQoSフローを束ねる機能が導入されたことにより，ユーザ体感の良い通信を行うことが可能となった．Rel-19では，暗号化されたXRトラフィックのサポートなど，より安心・安全・快適を目的とした機能に対応した．

3.2 Rel-19 XRMの拡張機能

Rel-19においては，UE（User Equipment）*34と外部サーバの間で行われる暗号化されたXRトラフィックに対応した．XRトラフィックの中身が暗号化されているとXRとトラフィックにかかわる管理情報も暗号化されるため，音声，映像，センサ情報などを正しく同期できない．この問題を解決するために，管理情報をMRI（Media Related Information）*35としてXRトラフィックとは独立したデータとして扱い，データバースト（一時的に大量のデータが流れる状態）の終了表示，優先転送，データバーストサイズ*36，および次のデータバーストまでの時間情報などをUPFに伝達可能になった．MRIの中でバーストに関する情報を独立に扱うことで，XRコンテンツの中身が暗号化された状態でもバーストの発生を予見でき，あらかじめ必要なリソースの調整ができる．リソース調整によって効率的にXRコンテンツがユーザまで転送され，ユーザは快適にXRコンテンツを享受することができる．

04. RCD活用によるなりすまし防止

4.1 背　景

近年，音声通話において，発信者のなりすましや迷惑電話が増えており，発信者の信頼性を高めることが重要な課題になっている．これまで，IETF（Internet Engineering Task Force）*37およびATIS（The Alliance for Telecommunications Industry Solutions）*38によって発信者の電話番号（Caller ID）を保証する仕組みが規定されていた．
ただし，この仕組みでは発信元の電話番号がなりすましではないか，改ざんされていないかという点は保証できても，発信元の正当性を判断するための情報は含まれていなかった．このため，着信者は発信者の電話番号でしか判断できないという課題があった．この課題を解決するために，IETFでは，発信者の名前やロゴ，発信理由といった電話番号に追加の情報を付与するRCD（Rich Call Data）*39を扱う仕組みが定義された．3GPPでも，この仕組みをIMS（IP Multimedia Subsystem）*40に取り込むことで，多様な発信者情報を着信者に提供する仕組みがRel-19で追加された．これにより，着信を受ける側は複数の情報要素から着信に応答するかどうかという判断が可能となる．

4.2 IMSにおけるRCDの署名および検証のアーキテクチャ

IMSにおけるRCDの署名および検証は，発信側および着信側のIMSとUEが連携して実現される．システムの全体像を図2に示す．①UE-Aが発呼する．②～④発信側IMSにおいて，IMS AS（Application Server）は，HSS（Home Subscriber Server）*41からRCDサーバアドレスを取得し，それを基に，RCDサーバから発信者のRCD情報を取得することができる．⑤発信側IMS ASは，AS for signing（署名用AS）を用いてRCD情報へ署名を付与することができる．⑥～⑨SIP（Session Initiation Protocol）*42信号とともにRCD情報が発信側IMS ASから着信側S-CSCF （Serving Call Session Control Function）*43へ転送される．⑩～⑫着信側IMSでは，IMS ASが発信側IMSから受信したRCD情報の署名の検証を起動する．このときに，着信側IMSは発信側IMSから受信したRCD情報が偽装・改ざんされたものでないか確認した上で着信処理を行う．⑬着信側S-CSCFはUE-Bへ着信を伝達する．このときにUE-Bは取得したRCD情報を着信者に表示する．
以下に代表的な構成要素を紹介する．
(1)HSS
加入者の識別情報やサービス情報などを管理するデータベースである．HSSは，RCD構成情報として，加入者ごとにRCDサーバアドレスまたはRCD URLを保持するか，加入者情報と独立する形でRCD情報（発信者名，会社名，メールアドレスなど）を管理することができる．
(2)IMS AS
留守番電話や着信転送などの付加サービスを実現するために，加入者情報を用いてサービス制御を行うノード*44である．Rel-19では，RCD情報の取得やRCD情報への署名・検証といった機能がサポートされる．
(3)RCDサーバ
発信者に関する詳細情報を保持するサーバである．IMSネットワークは，セッション確立時にこのサーバから情報を取得することで，動的に発信者情報を付与することが可能になる．
(4)AS for signing / AS for verification
RCD情報とRCD URLの署名（signing）・検証（verification）を行う．

05. A-IoT

5.1 背　景

近年，IoTデバイスの利用はさまざまな分野で拡大している．一方で，多数の小型デバイスを長期間にわたり運用する環境では，電池交換や充電に伴う保守対応が課題となる．特に，人手による対応が困難な場面では，従来の電池駆動型の仕組みでは適用が難しい場合がある．このような課題に対応するため新たなIoTの仕組みとして，従来の電池駆動型IoTでは対応が難しかった領域を対象とし，周囲の電波や光などのエネルギーを活用して動作するA-IoTがある．
3GPPでは，A-IoTに対応するシステム構成がRel-19で規定された［3］．Rel-19では，その初期段階として検討期間の制約から特定の機能に制限したデバイスを対象とし，ネットワークからの制御に応じて応答する構成を前提とし，適用範囲をプライベートネットワーク*45のみに限定している．
以下では，Rel-19におけるA-IoTのシステム構成と主な機能について解説する．

5.2 A-IoTの特徴と設計思想

A-IoTでは，多数の低機能デバイスを対象とすることを前提として，通信や処理をネットワーク側に集約する設計が採用されている．特にRel-19にて対象とするA-IoTデバイスは機能が大きく制限されているため，デバイス主導ではなくネットワーク主導で処理を行う構成となる．想定される利用形態としては，識別用デバイスとしてA-IoTを用いて倉庫や工場内に配置される多数の物品の在庫管理を行う場面が挙げられる．このような場面では，通信速度よりも，多数のデバイスが長期間にわたって安定運用されることが重要となる．

5.3 アーキテクチャ構成

Rel-19におけるA-IoTのアーキテクチャは，デバイス，無線アクセスネットワーク，およびコアネットワークからなる構成で定義されている（図3）［3］．A-IoTデバイスは必要な応答のみを行い，無線アクセスネットワークは複数のデバイスからの応答を受信してコアネットワークへ転送する．この構成では，デバイス側の機能を抑える代わりに，ネットワーク側に処理を集約する設計が採用されている．その中心となる機能がAIOTF（Ambient IoT Function）*46である．AIOTFは，AFからの要求に基づき，無線アクセスネットワークへの検出指示を行うとともに，複数デバイスからの応答結果を集約する役割を担う（図3）．また，AIOTFと無線アクセスネットワークの連携方式としては，無線アクセスネットワークと直接連携する構成に加え，中継機能を介する構成も規定されている．いずれの場合も，コアネットワーク内のAIOTFを中心として処理を行う点は共通である．

5.4 提供機能

Rel-19のA-IoTでは，デバイスの検出を行うInventory機能と，検出結果に基づき対象デバイスに対して指示を行うCommand機能が定義されている［3］．
Inventory機能は，外部機能より指定された無線エリアに存在するデバイスを把握するために用いられる．また，Command機能は，検出されたデバイスに対する情報の読出し，書込みおよび無効化を行うために用いられる．これらの処理は，AIOTFを中心としてネットワーク側で実行され，デバイス側の処理負荷の軽減とともに多数デバイスに対する効率的な処理を可能とする構成となっている．
デバイスの検出においては，個別の識別情報による指定に加え，条件に基づいて対象を絞り込む方法も規定されている．また，多数のデバイスを対象とすることから，無線アクセスネットワークおよびAIOTFにおいて結果をまとめて扱う仕組みも定義されている．
このように，A-IoTの提供機能は，単にデバイスを検出・制御するだけでなく，多数デバイスを前提とした効率的な処理をネットワーク側で支えるよう設計されている．

06. エネルギー効率化フレームワーク

6.1 背　景

エネルギー効率を踏まえたサステナビリティは，電気通信ネットワークにおける重要な課題の1つである．Rel-19ではエネルギーの効率的利用をめざし，従来のNF／スライス／セル単位の管理よりも細かいUE/PDUセッション単位といった粒度でネットワーク内部の詳細なエネルギー情報を収集・公開する機能と，エネルギーの効率的利用を意識したPolicy制御を導入した．エネルギー効率が向上することでSDGs（Sustainable Development Goals）*47への貢献やコスト削減が期待できる．

6.2 エネルギー消費公開アーキテクチャ

表2に示すとおり，Rel-19では取得できるエネルギー情報がRel-18から拡張され，より粒度の細かいエネルギー情報が取得できるようになっている．
粒度の細かいエネルギー情報，公開メカニズムおよび5GC内でのPolicy決定の支援を行うために，Rel-19では，エネルギー情報の支援機能としてEIF（Energy Information Function）*48が5GCに導入されている．EIFを使用すると，エネルギー関連の情報を細かい粒度で収集，処理および公開できる．
エネルギー効率をサポートするRel-19 5GCの概念アーキテクチャを図4に示す．
EIFは，5GC内の一元化されたエネルギー情報集約および公開機能（詳細エネルギー情報）を提供する．
図4に示すように，EIFはネットワーク内の複数のソースから，エネルギー消費量やトラフィック関連統計情報など，さまざまな情報を収集する．OAMや5GCから得た情報を基にEIFはエネルギー消費量をトラフィック挙動と関連付けることができる．
図4におけるEIFに関連する動作を説明する．
①EIFは，OAMからRANおよびUPFのノード単位のエネルギー消費量を取得する．
②EIFは，トラフィックに関する情報をOAMおよびSMF/UPFから取得する．この際，OAMからはRANのノード単位で，SMF/UPFからはUE/PDUセッション単位で受け取る．
③EIFは，エネルギー消費情報を計算し，AFおよびPCFなど他の5GC機能へその情報を提供する．提供された情報の使用例としては，AFがエネルギー消費情報に基づき，トラフィック状況への対応，バックグラウンドデータ転送の延期を行い，それによって，アプリケーションの動作を最適化するといったことが考えられる．さらに，PCFなどのPolicy関連ネットワーク機能へのエネルギー情報の共有により，次に述べるエネルギー対応Policy制御を導入できる．

6.3 エネルギー対応Policy制御

Rel-19では，省エネに関する情報をネットワーク内でより広範囲に活用できるようになった点が大きな特長である．
Rel-19にて，Energy Saving Indicatorが導入された．このIndicatorは，UE加入者情報に含まれ，UEがオペレータ定義の省エネ動作の対象であることを示す．Rel-19においては，AMF/PCFに対して拡張が行われたが，詳細は標準化されておらず，概念的な導入にとどまっている．Rel-20において具体的な仕様が議論中であるが，各オペレータは自社の運用方針に応じて，UEに対して省電力制御を行うことが期待されている．
Rel-19ではまた，特定エリアのUEに対してネットワークの非混雑時間帯などにデータ転送を行うBDT（Background Data Transfer）*49において，エネルギー関連情報を考慮する概念が導入された．AFがBDTを要求するときに，ネットワークにエネルギー関連の指標または優先傾向を提供するEnergy aware BDTという仕組みが導入された．Energy aware BDTでは，ネットワークがエネルギー消費を抑えながらネットワーク全体の効率を改善するために，緊急度の低いデータをいつ，どのように転送するかを最適化することを可能にする．仕様は明示的な最適化アルゴリズムを定義していないが，このアーキテクチャにより，ネットワーク条件およびオペレータPolicyとともにエネルギー関連の要因を考慮することができる．

07. あとがき

本稿では，3GPP SA Working Group 2 Rel-19における主な機能拡張について解説した．AI/MLを活用した高度なQoS/Policy決定，シグナリングストーム分析，XR関連サービスへの暗号化トラフィック対応，音声サービスへのなりすまし防止対策提供，A-IoTシステムの提供，エネルギー関連情報開示機能の追加による効率化など，多岐にわたる新機能が標準化された．これらは，ネットワーク運用の高度化，利用範囲やユースケースの拡大，サステナビリティへの対応，そして利用者利便性の向上を図るものであり，今後もさらなる機能拡張と深化が期待される．Rel-20においても引き続きAI/MLやA-IoTに関して標準化議論を継続する．