3GPP（3rd Generation Partnership Project） Release（Rel）-15で策定された5GC（5G Core network）のアーキテクチャは、Rel-16およびRel-17での拡張に引き続き、5G-Advancedの最初のリリースと位置付けられるRel-18においても、さまざまな分野で拡張がありました。
・拡張現実感を与えるアプリケーション、および対話型メディアサービスでは、輻輳＊1状況におけるQoS（Quality of Service）の機能が拡張されました。また、端末の電力消費削減のための機能が拡張されました。
・時刻サービスと確定性通信では、時刻同期の機能が拡張されました。また、確定性通信がトランスポートネットワーク（TN：Transport Network）＊2に導入され、さらなる低遅延通信が可能となりました。さらに、IP（Internet Protocol）ベースの確定性通信の仕組みが導入されました。
・ネットワークスライシングでは、スライスの可用性に問題がある場合の対処、スライスが地域限定の場合の対処、必要なネットワークスライスに必要なときだけ接続させるためのポリシーに関する機能が拡張されました。
・RNAA（Resource owner-aware Northbound API Access）＊3が、API（Application Programming Interface）利用により影響を受けるユーザの認可のもとでAPIアクセスを許容する仕組みとして、5GCに導入されました。
・インテント駆動管理は、ネットワークに関する詳細な知識を必要とせずに、システムを駆動していく管理手法であり、その仕様が拡張されました。
本稿では、これらの拡張について解説します。

＊　本特集は「NTTドコモ・テクニカル・ジャーナル」（Vol.32, No.3, 2024年10月）に掲載された内容を編集したものです。
＊1 輻輳：通信の要求が短期間に集中してネットワークの処理能力を超え、通信に支障が発生した状態。
＊2 トランスポートネットワーク（TN）：無線アクセスネットワークとコアネットワークを接続するネットワーク。かつ、それぞれのネットワーク内の装置間を接続するネットワーク。
＊3 RNAA：API使用者がリソースオーナからの認可を必要とするAPI起動シナリオ。

Rel-18では、「XR（Extended Reality）サービス（AR（Augmented Reality）/VR（Virtual Reality）サービス）」および「対話型メディアサービス」の処理効率化を図るために、いくつかの拡張機能が導入されました。

Rel-18では、1つのQoSフローの中で、PDU（Protocol Data Unit）の目的を識別し、NG-RAN（Next Generation‐Radio Access Network）でのQoSの扱い（すなわち無線リソーススケジューリング）をPDUごとに変えることができます。

Rel-18では、ConnectedモードDRX（Discontinuous Reception）が拡張され、ネットワークはXRメディアストリームの周期性に基づいてDRXタイマを調整することができます。また、DRXサイクルタイマを、ビデオフレームレートと一致するように非整数値に設定できます。

IETF（Internet Engineering Task Force） RFC 9331^（1）で定義された輻輳制御メカニズムL4S（Low Latency、Low Loss、Scalable Throughput）を導入しました。NG-RANは輻輳が生じた場合にIP層でECN（Explicit Congestion Notification）マーキングを生成し端末に送信します。あるいは、NG-RANはUPF（User Plane Function）に報告し、UPFがIP層でECNマーキングを実行し端末に送信します。端末はECNマークを送信者に送信し、送信者は、データレートを調整します。

Rel-18では、アプリケーション機能（AF）が5GSにクロック品質受入れ基準を提供する手段が規定されました。AFは、これにより、管理する端末が適切な精度の時刻情報を得ているかを監視することができます。

Rel-18では、TNに配備されたTSN（Time Sensitive Network）機能の5GSへの統合がサポートされています。その目的は、確定的なトラフィックを伝送する5GS QoSフローのQoS要件とトラフィック特性（例：バースト到着時間、バースト間隔、要求最大遅延）をTNに示すことによって、TNでの確定的な通信を可能にすることです。

Rel-18では、NG-RANがAFにBAT（Burst Arrival Time）補正値を提供できます。これにより、AFはBATを、NG-RANで次に予想されるストリームのバーストの送信機会に合わせることができます。同様に、NG-RANは、AFに、調整後のトラフィックの周期性を通知することもできます。本機能は、非常に低い遅延を満たす必要があるアプリケーションを対象としています。

DetNet（Deterministic Networking）機能は、IEEE TSNに似ていますが、IPベースの技術であるため、広範囲のネットワークに適しています。IETF DetNetに基づく確定性通信をサポートするために、5GSはIETF RFC 8655^（2）で定義されている論理中継DetNetルータ（5GSルータ）として機能します（図1）。

（1）　一時的に利用可能なネットワークスライスの最適化された処理
事前に知られている限られた時間のみ利用可能となるネットワークスライスがあります。Rel-18では、ネットワークスライスの登録管理およびセッション管理の状態の遷移に関する信号負荷を軽減するために、S-NSSAI（Single-Network Slice Selection Assistance Information）＊4有効期間を定義しました。
（2）　ネットワークスライス置換のサポート
ネットワークスライス置換機能は、S-NSSAIが利用できなくなった場合、または輻輳した場合に、一時的にS-NSSAIをAlternative S-NSSAIに置き換える機能です（図2）。

＊4 S-NSSAI：5GC において用いられるNetwork Sliceを特定する識別子。

Rel-18で導入したスライス使用ポリシーには、端末内のアプリケーションがネットワークスライスでのデータ転送を必要とする場合にのみ、端末がそのネットワークスライスに登録する設定が含まれます。また、ネットワークスライスに関連付けられている最後のPDUセッションが解放された後に、そのネットワークスライスを登録解除するためのタイマを含めることもできます。

Rel-18では、既存のTA境界と一致しない、地理的に限定された可用性を持つネットワークスライスが使用できます。

RNAAにより、CAPIF（Common API Framework）はリソースオーナに対しリソースの使用のための認可を求めることが実現可能となりました。RNAAは、IETFで標準化されているIETF OAuth 2.0＊5をベースとしています。
Rel-18では、RNAAで用いる認可付与方式は複数規定されていますが、本稿では代表的な認可コード付与方式によるRNAAを解説します。

＊5 OAuth 2.0：正当なクライアントに対してシステムの操作を認可する仕組み。RFC6749。

RNAAのアーキテクチャを図3に示します。リソースオーナはRNAAを通じて保持するリソースの権限に対する許可をAPI呼出し元に付与します。
各機能などの詳細を以下に述べます。
（1）　リソースオーナ機能
リソースオーナへの認可要求を管理するために、CAPIFコア機能内にある認可機能と連携するRNAAの機能部です。OAuth 2.0ではリソースオーナに相当します。
（2）　認可機能
リソースオーナ機能と連携し、認可コード発行のための認可を実施するRNAAの機能部です。OAuth 2.0では認可サーバに相当します。
（3）　API呼出し元
CAPIF APIおよびサービスAPIの呼出し元であり、ネットワークオペレータや端末上にあるサードパーティのアプリケーションを指します。OAuth 2.0ではクライアントに相当します。
（4）　CAPIFコア機能
CAPIF APIを提供し、API呼出し元の認証・認可やサービスAPIの登録、ポリシーの管理など、CAPIFで提供する各種機能においての中心的な役割を果たすCAPIFの機能部です。RNAAにおける認可処理はCAPIFコア機能内の（2）認可機能が担います。
（5）　APIプロバイダドメイン機能
サービスAPIを提供し、「API開示機能」「API発行機能」「API管理機能」を総称するCAPIFの機能部です。
（6）　API開示機能
API呼出し元からのサービスAPI呼出しを受け入れるCAPIFの機能部です。OAuth 2.0ではリソースサーバに相当します。
（7）　API発行機能
サービスAPIをAPI呼出し元が利用できるようにするために、CAPIFコア機能宛にサービスAPI情報を発行するCAPIFの機能部です。
（8）　API管理機能
発行されたサービスAPIの管理を担い、サービスAPI呼出しログの監査やサービスAPIの状態の監視などを行うCAPIFの機能部です。
なお、（7）と（8）の機能に関しては以降の説明にかかわらず参考情報として記載します。

API呼出し元がCAPIFのサービスAPIを呼び出す際のオプションとして、リソースオーナの同意を取得するケースがあり、その際にRNAAの機能を用います。RNAAの手順例を図4に示します。
なお、RNAAを用いる前提として、事前に下記の条件を満たしている必要があります。
・CAPIF側にAPI呼出し元がオンボード登録されていること。
・CAPIF側でサービスAPIの発行が完了されており、サービスAPIが発見可能な状態となっていること。
・CAPIF側にAPI呼出し元が認証されていること。
・CAPIF側で、API呼出し元とAPI開示機能間の認証認可を実施する際のセキュリティメソッド〔本稿ではOAuthトークンを用いたTLS（Transport Layer Security）方式とする〕が決定されていること。
・CAPIF側でRNAA利用時のリソースオーナの同意を取得する際の認可の付与方式（本稿では認可コード付与方式とする）が決定されていること。
図4にある各手順について以下に解説します。
①　API開示機能によるAPI呼出し元の認証：API呼出し元はAPI開示機能に対し、事前に決定されたセキュリティメソッドを用いて認証を要求し、内容を検証したAPI開示機能はAPI呼出し元の認証を実施します。
②　サービスAPIの認可要求：API呼出し元は、CAPIFコア機能内にある認可機能に対し、サービスAPIの認可要求を送信します。
③　リソースオーナからの認可同意取得：認可要求を受信した認可機能はリソースオーナを認証し、認可要求に対する同意・不同意を求めます。リソースオーナが同意すると、認可機能はAPI呼出し元への権限移譲を実施します。このときAPI呼出し元は認可機能から認可コードを受け取ります。
④　サービスAPIの認可：API呼出し元は認可機能に対し認可コードを送信し、認可機能はAPI呼出し元の認証や認可コードの検証を行い、問題がなければAPI呼出し元に対しアクセストークンを発行します。
⑤　サービスAPIの実行：API呼出し元はAPI開示機能に対し、アクセストークンを含むサービスAPIの実行を要求するメッセージを送信し、内容を検証したAPI開示機能は、CAPIFコア機能と連携して、サービスAPIを実行します。

インテント駆動管理とは、実現したい状態として表現されたインテントに従い、ネットワークに関する詳細な知識を必要とせずに、実現したい状態を提供できるようにシステムを駆動していく管理手法です。
インテントに関する説明として、TS28.312^（3）にて下記が記載されています。
・インテントは、人間が理解でき、機械が曖昧さなく解釈できるものである。
・インテントは、達成する必要がある「何（What）」を説明することに重点を置いており、必要な結果を達成するための「方法（How）」にはあまり焦点を当てていない。これにより、インテントの要求元は、実装の詳細を知る負担が軽減され、インテントの処理先は代替オプションを検討し、最適なソリューションを見つける余地が生まれる。
・インテントによって表現される期待は、基盤となるシステムの実装、テクノロジ、インフラストラクチャに依存しない。
・インテントは、達成状況を測定および評価できるように、ネットワークデータから定量化できる必要がある。
（1）　インテントの分類
インテントは、図5（TS28.312^（3））に示す内容に分類されています。
・通信サービスカスタマ（CSC：Communication Service Customer）からのインテント（Intent-CSC）：例として、「特定の時間内に、ある車両のグループに対してV2X（Vehicle to Everything）通信＊6サービスを有効にする」といったものがあります。
・CSPからのインテント（Intent-CSP）：例として「高速道路417号線のV2X通信をサポートするネットワークサービスを提供し、同時に500台の車両をサポートする」といったものがあります。
・ネットワークオペレータ（NOP：Network OPerator）からのインテント（Intent-NOP）：例として、「特定のエリアで指定されたカバレッジ要件と端末スループット要件を満たす無線ネットワークサービスを提供する」といったものがあります。
（2）　インテントの数値目標
インテントは、下記のようにネットワーク管理のニーズによって異なる特定の数値目標を記述できます。
・ネットワークおよびサービス関連オブジェクト＊7を配置するためのインテント期待値の場合では、例えば「指定された周波数情報・トランスポート情報・無線情報、ネットワーク容量および性能情報を使用して、指定されたエリアに無線ネットワークを配置する」といった設定を行うことができます。
・ネットワークおよびサービス関連オブジェクトに対するインテント期待値の場合では、例えば「指定されたエリアの無線ネットワークが、特定の予想されるRANと端末間のスループット目標を満たしていること」といった設定を行うことができます。

＊6 V2X通信：V2Xは、自動車、他の自動車、信号機や道路標識などのインフラ、歩行者が直接に相互通信することを目的とした無線通信システムの総称。
＊7 オブジェクト：現実世界に実体や概念として存在するものをプログラム上で扱えるように表現したもの。実体の属性を表すデータと、実体に対する操作の組合せとして表現されます。

データモデルでは、インテントが持っている属性（期待内容や優先度など）が定義されています^（3）。また、インテントの要求元と処理先にてインテントをやり取りするさまざまな手順が定められています^（3）。

本稿では、Rel-18で規定された拡張について、拡張現実感とメディアサービス、時刻サービスと確定性通信、ネットワークスライシング、RNAA、インテント駆動管理に焦点を当てて解説しました。NTTドコモは、今後も3GPPにおける標準化に寄与し、移動通信のさらなる発展に貢献していきます。

■参考文献
（1）　IETF RFC 9331：“The Explicit Congestion Notification （ECN） Protocol for Low Latency, Low Loss, and Scalable Throughput （L4S），”Jan. 2023．
（2）　IETF RFC 8655：“Deterministic Networking Architecture，”Oct. 2019．
（3） 3GPP TS28.312 V18.4.0：“Management and orchestration；Intent driven management services for mobile networks，”June 2024．