🐿️

5G-Advanced解説（3GPPリリース18 SA2機能）後編

2022/02/10に公開

3gpp

5ga

tech

3GPP SA2における5G-Advancedの検討状況

本記事は、5G-Advanced解説（3GPPリリース18 SA2機能）前編に対する続きです。
概要と新サービス/既存サービス拡張の分析については前編をご確認ください。

WID/SID分析

IoT/TSC/URLLC

WI/SIコード	タイトル	ラポーター1	ラポーター2	RAN影響	承認済WID/SID
FS_UAS_Ph2	Study on Phase 2 for UAS, UAV and UAM	Stefano Faccin, Qualcomm	-	RAN2	SP-211632
FS_REDCAP_Ph2	Study on RedCap Phase 2	Qian, Chen, Ericsson	-	RAN1	SP-211635
FS_PIN	Study on Personal IoT Networks	Zhenhua Xie, vivo	-	-	SP-211643
FS_DetNet	Study on Extensions to the TSC Framework to support DetNet	György Miklós, Ericsson	-	-	SP-211633
FS_5TRS_URLLC	Study on 5G Timing Resiliency and TSC & URLLC enhancements	Devaki Chandramouli, Nokia	-	RAN1	SP-211634

FS_UAS_Ph2, Study on Phase 2 for UAS, UAV and UAM, Stefano Faccin, Qualcomm, -, SP-211632
予備知識
ここでは、本SIの検討に至る経緯を簡単に説明する。3GPP公式の解説記事(UAS-UAV)を参考にしている。
無人航空システム（Unmanned Aerial Systems：UAS）のニーズに対応するため、3GPP WGでは、5Gシステムがの接続ニーズを満たすようにするための標準化が行われてきた。UASは、無人航空機（Unmanned Aerial Vehicle：UAV（別名：ドローン））とUAVコントローラで構成される。（下図）

UAVの安全な運用のためだけでなく、他のユーザーがUASに接近しても安全にサービスを継続できるよう研究と新機能の標準化が行われてきた。

関連WI/SI

Release-15 - Enhanced LTE Support for Aerial Vehicles (TR 36.777, TS 36.311)：性能強化、干渉対策、モビリティ性能、UE識別のための検討が行われた。干渉対策として2つのReporting Events、UEの高度の閾値を表すH1(above)とH2(below)がTS 36.311に追加された。
Release-16 - Remote Identification of Unmanned Aerial Systems (TS 22.125, Section 5)：リモート識別(Remote Identification)の要件、ユースケース、サービスを規定。
Release-17 - Study on supporting Unmanned Aerial Systems Connectivity, Identification, and Tracking (TR 23.754)：リモート識別を前提とした上で、Command & Control機能の検討を行った。LOSとNLOSの両方で、UAV同士およびUTM(UAS Traffic Management)との間で、どの程度接続を確立できるか検討した。
Release-17 - Study on application layer support for Unmanned Aerial System (UAS)(23.755)：SA1からのUAS識別とトラッキングの要件に基づきアプリケーションレイヤにどのような影響があるかSA6で検討されている。特にUTMのアプリケーションサポート／イネーブラ機能、およびUASとUTM間のサービス相互作用（例：飛行ルート認証、位置管理、グループ通信サポート）への影響の可能性について調査している。ミッションクリティカルおよびV2Xサービス用に開発されたアーキテクチャとソリューションを、航空システムで再利用することを検討している（see SP-181252）
Release-17 - 5G Enhancement for UAVs (TS22.125; TS22.261)：新しいKPI（Command & Control用、On-board radio access node (UxNB)、UAVサービス制限、NEF）の検討

背景
SA1のTS 22.125 Relese 17では、3GPP SA2でカバーされていない新しい要件が定義されているため、どの要件をサポートする必要があるかをギャップ分析が必要。

USS（UAS Service Supplire）が、ある地域および／またはある時間における UAV の通信リンク状態およびサービス状態（ネットワークが一定の QoS で UAV への通信サービスを提供できるかどうかの情報）に関するリアルタイム情報の要求および取得する手段を提供すること。（see R-6.2-001、R-6.2-002、 R-6.3-002）。
あらかじめ定義された C2通信(Command & Control Communication)モデルにおいて、要求された QoS を満たすC2通信を USS/UTM が監視すること（R-6.5.003 参照）。

注：GSMA-GUTMA の共同活動である Aerial Connectivity Joint Activity (ACJA)は、成果物「ACJA - WT2: Interface for data exchange between MNOs and UTM ecosystem - NetworkCoverage Service Definition」において、本目的のためのインタフェースを既に定義している。

この要件はUrban Air Mobility（UAM）にも適応されうる。

航空業界では、混雑した空域でUAVとUAMが安全に共存するためのDAA（Detect And Avoid）をサポートするため、DAAソリューションの要件を開発している。カバー内およびカバー外のシナリオとPLMN間シナリオの両方を考慮してUAV間の通信を可能にすることを要件としている。TS 22.125 では、PC5などを使用した UAV-to-UAV 直接通信に関する要件(see R-5.2.2-001, R-5.2.2-004 to R-5.2.2-0011)が含まれている。

目的
本SIでは、Uncrewed Aerial System (UAS)、Uncrewed Aerial Vehicle (UAV)、Urban Air Mobility (UAM)の追加シナリオと要件をサポートするための5GSとEPSのアーキテクチャとシステムレベルの拡張の可能性を検討し特定する。

既存のメカニズム(PC5)を再利用できる方法とその可否、および必要なアーキテクチャと機能の修正を特定することにより、3GPPシステム経由でBroadcast Remote IdentificationとC2 Coummunicationを伝送する方法の検討
Detect And Avoid（DAA）などの航空(Aviation)アプリケーションをサポートするために既存のメカニズムを再利用できる方法とその可否、必要なアーキテクチャと機能の修正に関する特定を行う。

FS_REDCAP_Ph2, Study on RedCap Phase 2, Qian, Chen, Ericsson, -, SP-211635
背景
SA2では、Rel-17において、NRのRedcapのサポートを規定しているが、RRC_INACTIVE状態でのDRXサイクルの延長は、最大10.24秒に制限されている。10.24秒より長いDRXサイクルのサポートは、SA2からRAN2/RAN3/CT1へ発出されたS2-2106978に記載されているように、Rel-18で検討されることが合意されている。
RRC_IDLE状態およびRRC_INACTIVE状態に関するRAN TR 38.875の分析によると、Extended DRXサイクルのサポートは省電力化の観点で重要であり、5GSでは、RRC_INACTIVE状態での長いExtended DRXサイクルをサポートするソリューションを提供することが求められる。

目的
本SIでは、RRC_INACTIVE状態のDRXサイクルの10秒超のサポートを可能にするための5GSの拡張の検討する。特に、RANページング（PTWおよびeDRXサイクル値など）のRRC_INACTIVE状態での10.24秒より長いeDRXサイクルのサポート、およびRRC_INACTIVE状態で長いeDRXサイクルを持つUE向けのMT信号およびデータ処理を検討する。

FS_PIN, Study on Personal IoT Networks, Zhenhua Xie, vivo , -, SP-211643
背景
現在、一部のウェアラブル端末を除き、IoT端末は、有線アクセスを使用する中継器やゲートウェイ、またはモバイルネットワークにアクセスするUEを介してのみインターネットにアクセスすることができている。どちらの場合も、モバイルコアネットワークはIoTデバイスを意識することはない。5Gサービスを活用しオペレータの「付加価値」を増やすには、5GシステムがIoTデバイスを認識する必要がある。
ユーザーは、パーソナルIoTネットワーク(Personal IoT Network)を構築する。PINはそれを形成するデバイスと、Customer premisesネットワークの一部であるデバイスで構成される。PINを構成するデバイス（PIN Element）には、通信機能を持つデバイス、ゲートウェイ機能を持つデバイス（PIN Element with Gateway Capability）、管理機能を持つデバイス（PIN Element with Management Capability）に分類できる。
本SIでは、SA1によるTR 22.859と3GPP TS 22.261に含まれるPINの要件を満たすため、PINを形成するユーザに5G体験を提供し、ネットワーク管理と性能を向上させることを検討する。

目的
本SIでは以下の項目を検討する。

PIN（Personal IoT Networks）の管理、PEGC（PIN Element with Gateway Capability）を介したPINへのアクセス、PINの通信、PINおよびPIN内のPINエレメントの識別をサポートするためのアーキテクチャの拡張。
5GCレベルでPINとPINエレメントを識別し、認証/認可を行う方法。
PINの管理（例：PINの作成、PIN要素の認証／非認証、PEMC(PIN Elements with Management Capability)の認証／非認証、PEGC(PIN Elements with Gateway Capability)の認証／非認証、PINの持続時間の設定など
ネットワーク発見手順、PINエレメント発見手順、PINエレメント発見の能力、および可用性と到達性の発見（PEMCによりアシストされる）のための手順

FS_DetNet, Study on Extensions to the TSC Framework to support DetNet, György Miklós, Ericsson, -, SP-211633
背景
IETFで標準化されたDeterministic Networking（DetNet）は、IPとMPLS（Multiprotocol Label Switching）層で動作し、パケットロス率がほぼゼロで遅延が拘束されることを保証するタイムセンシティブ機能を提供する。DetNetは、単一の管理統制下にあるネットワークや閉じた管理統制グループ内のネットワークを対象としており、インターネットのような大規模なドメイン群を対象とはしていない。IETF DetNet WGとIEEE Time-Sensitive Networking (TSN) TGの間には、密接な協力関係がありり、DetNetの機能はTSNのものと非常によく似ている。
DetNetはIETFにおいて成熟してきており、多くのRFCが発行され、いくつかのIETFドラフトはRFC化が待たれている。DetNetは、産業用機器間通信やスマートグリッドなど産業オートメーション分野の多くのユースケースに適用することが期待されている。
この検討では、5GSはDetNet IP data plane network内に配置されるとする。この場合、3GPPにおけるDetNetのサポートは、リリース17に含まれるDeterministic QoSおよび時間同期サービスのためのTSCフレームワークの再利用で実現できる。

以下は、参考としてRFC 8655の和訳の抜粋です。

DetNetはIPレイヤーで動作し、MPLSやIEEE 802.1 Time-Sensitive Networking（TSN）などの下位レイヤーテクノロジーを介してサービスを提供します。 DetNetは、リンク帯域幅やバッファスペースなどのネットワークリソースをDetNetフローやDetNetフローのクラスに専用化し、複数のパスに沿ってパケットを複製することにより、信頼性の高い利用可能なサービスを提供します。未使用の予約済みリソースは、すべての保証が満たされている限り、DetNet以外のパケットで使用できます。
https://tex2e.github.io/rfc-translater/html/rfc8655.html

目的
本SIでは、DetNetをサポートするためのTime Sensitive Communications (TSC) フレームワークの拡張を検討する。

3GPPがDetNet（IPベースのDetNet）をサポートし、セントラルDetNetコントローラと5Gシステム間のマッピングを提供するかどうか、またどのようにサポートするかを検討する。マッピングには、DetNetトラフィックプロファイルおよびフロー仕様の5GS QoSパラメータおよびTSCAIへの変換が含まれる。
5GシステムからDetNetコントローラに公開される必要がある情報。

FS_5TRS_URLLC, Study on 5G Timing Resiliency and TSC & URLLC enhancements, Devaki Chandramouli, Nokia, -, SP-211634
背景

SA1はTR 22.878 Study on 5G timing resiliency systemで、GNSS障害時に5Gシステムの耐障害性を維持し、5Gシステムがバックアップとして機能し、他のアプリケーション（金融、電力網システムなど）向けに無線および屋内対応の時間同期サービスを提供するための要件を規定している。
IPとETHアプリケーションのための5GSへの汎用TSCとNEFの強化が必要。現在のNEFは、AFがQoSパラメータを要求しトラフィック特性を提供することを可能にしますが、一部のIPおよびETHアプリケーションにとって重要である信頼性の側面は提供していない。
低遅延、低ジッターをサポートするために、TSNトランスポートネットワークとの連携を検討する必要がある。トランスポートネットワークにTSNネットワークを適用することも可能とする。そのような形態では、トランスポートネットワークも遅延保証を提供できるように相互運用できることが有益となる。

目的
本SIでは、以下の検討を目的とする。

UEおよびサードパーティアプリケーション（AF）に対して、5GSネットワークのタイミング同期状況（UTCからの発散や5GSネットワークのタイミングソースの劣化など）を報告する方法。
AFが特定のカバレッジエリアで時刻同期サービスを要求できるようにする方法と、カバレッジエリアを強制する方法。
5G 時刻同期サービスをサブスクリプションに基づいて制御する方法
AFがNEF/PCFに明示的にPERを提供することを可能にする方法
5G Timing Resiliency 要件のサポート
低遅延への対応

アーキテクチャ拡張

WI/SIコード	タイトル	ラポーター1	ラポーター2	RAN影響	承認済WID/SID
FS_SFC	Study on System Enabler for Service Function Chaining	Ellen Liao, Intel	-	-	SP-211594
MPS_WLAN	MPS when access to EPC/5GC is WLAN	Robert C Streijl; Peraton Labs	-	-	SP-211595
FS_GMEC	New SID on generic group management, exposure and communication enhancements	Qianghua Zhu, Huawei	Sang-Jun Moon, Samsung	-	SP-211603
FS_ATSSS_Ph3	New SID on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3	Apostolis Salkintzis, Lenovo	-	-	SP-211612
FS_eNPN_Ph2	Study on enhanced support of Non-Public Networks phase 2	Hedman, Peter, Ericsson	-	-	SP-211656
FS_VMR	Study on Vehicle Mounted Relays	Hong Cheng, Qualcomm	-	RAN2	SP-211636
FS_EDGE_Ph2	Study on Edge Computing Phase 2	Patrice Hédé, Huawei	-	-	SP-211638
FS_5WWC_Ph2	Study on the support for 5WWC Phase 2	Laurent Thiebaut, Nokia	-	-	SP-211640
FS_AMP_Ph2	Study on 5G AM Policy Phase 2	Chen, Zhuoyi, China Telecom	-	-	SP-211642
FS_UEPO	Study on of 5G UE Policy	Changhong Shan, Intel	-	-	SP-211649
FS_5GSATB	Study on 5G System with Satellite Backhaul	Hucheng Wang, CATT	-	RAN2	SP-211639
FS_5GSAT_Ph2	Study on satellite access Phase 2	Jean-Yves Fine, Thales	Sherry(Yang) Shen, Xiaomi	RAN2	SP-211651
FS_UPEAS	Study on UPF enhancement for Exposure And SBA	Yan Han, China Mobile	-	-	SP-211652
FS_SUECR	Study on Seamless UE context recovery.	Lalith Kumar, Samsung	-	-	SP-211654
FS_5G_ProSe_Ph2	Study on Proximity-based Services in 5GS Phase 2	Qiang Deng, CATT	Fei Lu, OPPO	RAN?	SP-211653

FS_SFC, Study on System Enabler for Service Function Chaining, Ellen Liao, Intel, -, SP-211594
背景
SA1 Release 18(TS22.101 30.1, TS22.261 6.35, TS22.115 5.2.14)では、5GS向けのサービスファンクションチェイニング（SFC:Service Function Chaining）のサービス要件が合意されている。この中には、3rdパーティがSFCポリシーに基づいてネットワーク事業者が提供するSFCを要求したり、3rdパーティが要求したSFCの管理および課金といった側面も含む。

目的
このSIではSFCポリシーを定義するかどうか、どのように定義するかを検討し、SFC機能を持つ5Gネットワークが非ローミングおよびホームルーティングローミングのシナリオでU-Planeトラフィックを識別／検出／分類し、SFC処理のために順序付けられたサービス機能のチェーンにトラフィックを誘導するソリューションと手順を検討する。その結果に基づいて、このSIでは、AF(Application Function)がネットワーク能力公開機能（例えば、特定のトラフィックフローのSFCを要求する）を要求できるようにするためのNorthbound APIの拡張を規定する。

MPS_WLAN, MPS when access to EPC/5GC is WLAN, Robert C Streijl; Peraton Labs, -, SP-211595
背景
Rel-18では、TS 22.153(Multimedia priority service)が更新され、EPC/5GC へのアクセスが WLAN（non 3GPP アクセス）である場合の MPSを明示的にカバーするようになった。UEがWLANにアクセスする場合のMPSのサポートは、3GPPアクセス・ネットワーク（LTE および NR）が利用できない、または劣化した場合など、特定の災害シナリオにおいて重要となる。

目的
このWIではEPC/5GCへのアクセスがWLANの場合のマルチメディア優先サービス（MPS） - アタッチ/登録手順中に3GPP MPS加入情報をWLAN/UEに伝える既存の手順を拡張し、MMTEL音声/ビデオ通話用MPSの4Gベアラ/5G QoSフローとデータ伝送サービスセッション用MPSのためにMPS優先表示(MPS priority indication)をWLANに渡すことを目的としている。これはUE（またはIoTデバイス）がEPC/5GCへのWLANアクセスを持っている場合のシナリオに適用される。

FS_GMEC, New SID on generic group management, exposure and communication enhancements, Qianghua Zhu, Huawei, Sang-Jun Moon, Samsung, SP-211603
前提知識
5G-LANタイプサービスとは、Release-16で導入された、UPFをローカル環境に設置し、端末とUPF間で折返し通信を行うことを可能とする技術。サービス要件はTS 22.261で、機能要件はTS 23.501 5.29で規定される。コアネットワークを経由しないLAN環境が構築できる。一部の端末のみLAN通信を行い、他の端末はコアネットワークと通信させるような制御も可能。また、5G-LANタイプサービスでは、5G VN(Virtual Network)グループ識別、メンバーやグループデータの管理が可能。5G VNはプライベート通信を行うUEセットから構成される。5G VNグループ管理は、オペレータの管理者が設定することも、3rdパーティのアプリケーション（AF:Application Function）で管理することもできる。

背景
Release-16の5G-LANタイプサービスは、UEとUEの背後にあるデバイスに対して、単一のSMFによって制御される最適化された通信経路を使用してIPおよび/またはnon-IPタイプの通信のプライベート通信を提供する。しかし、5G VNが非常に大きい場合でも、Release-16では5G VNあたりのSMFの数は1つに制限されている。例えば、大規模なマルチサイト企業、複数の国にまたがる大規模な産業環境などでは、複数のSMFをサポートする必要がある。
Release-18 SA1 TR 22.867 Study on 5G Smart Energy and Infrastructure "5SEI "では、5GシステムがUEに対して、異なるグループのUEに同時にデータを送信するサービスを要求できること、およびUEの通信グループごとに異なるQoSポリシーを許容することを含む新しい要件（TS 22.261 6.13.2,6.28、TS 22.104 5.2,5.6,9）が合意されている。
最近、5G Alliance for Connected Industries and Automation（5G-ACIA）は、5GCと産業アプリケーションドメイン間の一定の情報交換のサポート、および5G機能の公開という観点から、5GSが満たすべき一連の機能要件を含むホワイトペーパー（S2-2102128）を3GPPに提供した。主な目標は、5G技術に関する深い知識に頼ることなく、企業の観点からネットワークやネットワークサービスの管理、運用、監視、利用を簡単に行えるようにすることである。デバイス管理に関するいくつかの要件（接続性管理、接続性監視、グループ管理など）はまだ満たされていないため、さらなる検討が必要。

目的
このSIでは、以下の3つのタスクについて検討する。

産業用および自動化アプリケーションのための5G能力公開(5G capabilities exposure)、例えば、（グループ属性管理およびグループ・ステータス・イベント報告の強化、トラフィック特性のプロビジョニングと所定のグループの各UEに適用されるパフォーマンス特性のモニタリングのための能力公開を可能にするためのNEF強化の有無と方法の検討）。
5G VNグループコミュニケーションの強化（すなわち、5G VNグループコミュニケーションの改善。複数のSMFをサポートする5G VNのグループ通信のサポート（5G VNグループ通信の信頼性のためのSMF冗長性のサポートを含む）。
UEが異なるグループ（各グループは異なるQoSポリシーを有する）に同時にデータを送信できるグループ通信に必要な追加のメカニズムまたは拡張機能とサポート方法。

FS_ATSSS_Ph3, New SID on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3, Apostolis Salkintzis, Lenovo, -, SP-211612
前提知識
Release-15では5GSでnon-3GPPアクセスを有効とすると、non-3GPPアクセスのみを使用して5Gサービスにアクセスすることが可能になる。さらに、Release-16から、オプション機能として3GPPアクセスと非3GPPアクセスを同時に使用するATSSS（Access Traffic Steering, Switching and Splitting）が標準化された。ATSSSの「ステアリング」とは、ユーザープレーンのトラフィックに対してサービス（データフローのQoSタイプ）に応じて最適なリンクを選択できることを指し、「スイッチング」とは、必要に応じてサービスを中断せずに他のリンクにハンドオーバーできることを指し、「スプリッティング」は、2つのリンクを同時に使用（ボンディング）することを指す。

ATSSS-LL(ATSSS Low-Layer)はUEとUPF間の低レイヤ（below IP layer）のステアリング機能を提供する。イーサネットPDUの場合、ATSSS-LLはATSSSで利用可能な唯一のメカニズムとなる。
MPTCP(Multipath TCP) RFC 8684は、高レイヤー（above IP layer）のステアリング機能を提供する。IETFのMPTCPワーキンググループで標準化され、Linuxカーネルではバージョン3.10以降、iOSではバージョン7以降で使用可能になっている。
PMF(Performance Measurement Function)はセッションの両端であるUEとUPFの両方に含められリアルタイムのパフォーマンス測定（RTTや負荷）を実施して、各リンクの状態に基づいた低レベルのトラフィック管理を実施する。

関連WI/SI

Release-16 - Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture(FS_ATSSS) (TR 23.793)
Release-16 - Access Traffic Steering, Switch and Splitting support in the 5G system architecture(ATSSS) (TS 23.501,TS 23.502,TS 23.503)
Release-17 - Study on Access Traffic Steering, Switch and Splitting support in the 5G system architecture Phase 2 (TR 23.700-93)：追加のステアリングモデル、IETFのプロトコル（QUIC/MP-QUIC）に準拠した実現方式、5GC経由の非3GPPアクセスパスとEPC経由の3GPPアクセスパスのMA PDUセッションの検討。
Release-17 - Access Traffic Steering, Switch and Splitting support in the 5G system architecture; Phase 2 (ATSSS_Ph2)：TR 23.700.93の8.1と8.3の仕様化。

背景
ATSSSは、UEとUPFの間で複数のパス（通常は3GPPアクセスパスと非3GPPアクセスパス）を同時に経由して通信することを可能にする機能である。複数のパスで同時に通信を行うことにより、5Gシステムでは、ユーザー体験を向上させたサービスの提供、ポリシーに基づく複数のアクセスへのトラフィック分散、新しい高データレートサービスの提供などが可能になる。
ATSSSのRelease-17のSI/WIでは、以下の機能がATSSSから除外されて後続のリリースに延期された。

ブランチングポイントまたはULCLを使ったMA PDUセッションはサポートされなかった。
QUICベースのステアリング機能はnon-TCPトラフィック向けにRelease-17で研究されたが十分に規定はされなかった。
Release-17 ATSSSでは、冗長ステアリングモードが検討された(see TR 23.700-93 solution 4)。送信側（UEまたはUPF）が性能測定と閾値に基づいて、パケット送信の冗長性（すなわち、両方のアクセスでのパケットの複製）を有効または無効にすることを決定する。しかし、このソリューションは完全には規定されていない。
UEが3GPPアクセスでアイドルであり、LADNサービスエリアから外れた場合、UEは非3GPPアクセス上でデータ交換を続けてしまう可能性がある。この問題を回避するため、Release-17では、LADNでMA PDUセッションを禁止する制限を加えた。この制限を回避するために、UEがLADNサービスにアクセスする際に、ATSSSのサポートを有効にするソリューションが必要。

また、ATSSSの新しいユースケースやシナリオが特定されており検討を行う必要がある

現在、ATSSSは、1つの3GPPアクセスパスと1つの非3GPPアクセスパス間のトラフィック分散のみをサポートすることができる。しかし、次のようなシナリオもサポートすることが望まれる（see S2-2105753）。
- 2つの非3GPPアクセスパス（例：SNPN経由でNWuを使用するパスと、信頼できる非3GPPアクセス経由でNWtを使用するパス）
- 2 つの異なるPLMNにおける2つの3GPP アクセスパス（例：PLMN1経由の3GPP NTNアクセスを使用するパスと、PLMN2経由の3GPP TNアクセスを使用するパス）
- 同じPLMN内にある2つの3GPPアクセスパス。（例：LTE/EPCを使用するパスとNR/5GCを使用するパス）
現在、ATSSSは、5GC経由の非3GPPアクセスパスとEPC経由の3GPPアクセスパスのMA PDUセッションをサポートしているが、5GC経由の3GPPアクセスパスとEPC経由の非3GPPアクセスパスのMA PDUセッションはまだサポートされていない。後者のサポートも望まれる。

目的
本SIではATSSSのさらなる強化・最適化を目指し、以下のトピックを検討する。
非TCP トラフィックフローのステアリング／スイッチング／スプリットを可能にする新しいステアリング機能のサポート方法、GBR/非GBRトラフィックに関する冗長トラフィックステアリングのサポート方法、マルチアクセス（MA）PDU セッションのアクセスパスの種類のサポート方法、5GCによる1つの3GPP アクセスパスおよびePDG/EPCによる1つの非3GPPアクセスパスでMA PDU セッションをサポートできる方法などを検討する。

FS_eNPN_Ph2, Study on enhanced support of Non-Public Networks phase 2, Hedman, Peter, Ericsson, -, SP-211656

前提知識
MNOが提供する通信サービスと対比してNPN(Non Public Network)は、5GSをプライベートネットワークとして特定のユーザやグループにサービスを提供することを可能にする。NPNは、Stand-alone Non-Public Network（SNPN）とPublic Network Integrated Non-Public Network（PNI-NPN)の２つに分類される。SNPNはPLMNとは独立してNPNオペレータにより構築・運用されるが、PNI-NPNはその機能の一部、もしくは、全部をMNOの5GSと共有する形で構築・運用される。SNPNとPNI-NPNはそれぞれTS 23.501 5.30.2と5.30.3で規定されている。
NPNの前提知識として以下のドコモのテクニカルジャーナルを確認しておくとよいです。

出典：NTTドコモテクニカルジャーナル Vol.28 No.3 産業創出・ソリューション協創に向けた5G高度化技術

背景
NPN(Non Public Network)の基本的な機能はRelease-16で導入され、Rel-17では、異なるネットワーク/異なるエンティティ間の幅広い連携を可能にし、IMSおよびVIAPA関連のユースケースと同様に、事前にネイティブな認証/加入情報を持たないUEにアクセスを提供するNPN向けのユースケースをサポートするために拡張された。
Release-17 FS_eNPNでは、合計4つのkey issueを解決したが、TR 23.700-07に記載があるように、Release-17の時間枠では以下2つのキーイシューが解決されていない。

Equivalent SNPNのサポート
SNPNサービスにおける非3GPPアクセスのサポート

Release-17 eNPNでは、5GSの基本的なUEオンボーディング機能に対応したが、オンボーディングプロセスに関与するエンティティ（オンボーディングSNPN、サブスクリプション所有者SNPN、プロビジョニングサーバなど）の関係が1対1に限定されない場合に対して、完全なソリューションが必要となる可能性がある。また、制御プレーンプロビジョニングにより、3GPPネットワークは、3GPP外のメカニズムに依存することなくオンボーディングプロセス全体を制御することができ、オンボーディング機能の展開をより効率的にすることができる。上記のようなRelease-17ではされない部分を検討する必要がある。

目的
本SIではNPNに関連する幅広いユースケースを可能にするための5GSの拡張を検討する。

新しいネットワークを選択せずにSNPN間のIdelおよびConnectedモードモビリティのサポートを可能にするモビリティ強化
SNPNの非3GPPアクセス
ローカルホスティングNPNによるローカライズサービスの実現
UEによるローカルホストNPNの発見、選択、アクセスおよびホスティングNPNによる適切な認可のローカライズサービス
特定のネットワーク経由（ホームネットワークなど）でいつ、どのように、サービスにアクセスできるかのサポート

FS_VMR, Study on Vehicle Mounted Relays, Hong Cheng, Qualcomm, -, SP-211636
背景
都市部ではビルなどのインフラに基地局を追加設置する場合、不動産の利用可能性やコスト、規制の制約など、様々な課題や負担に直面することがある。一方、ユーザーの高密度化に伴い、公共/民間旅客輸送、商品配送、フードトラックなど、低速/歩行者速度で移動する多くの車両が存在する。これらの車両は、車両外の近隣のUEに5Gのカバレッジと接続性を提供するためのリレーとして機能する車載基地局（または基地局要素）を設置するのに便利で効率的な場所となりえる。リレーは5G コアに接続されたマクロネットワーク（固定ドナー基地局）に向けて、5G ワイヤレスバックホールを使用することとなる。
車両メーカーまたは車両所有者に対しては車両にリレーを設置し運用することを奨励するインセンティブを設けることが考えられる。
SA1は2020年9月にSI（FS_VMR、SP-200798）を開始し、車両搭載リレー（VMR）に関する新しい潜在的なユースケースとサービス要件はTR 22.839にまとめられた。対応するNormative workは2021年8月に完了し、TS 22.261などに以下の要件が規定された。

モバイルBSリレーの動作、プロビジョニング、制御、設定のサポート
UEアクセスコントロール、チャージング、QoS、マルチPLMN RANシェアリング
サービス継続性（UEおよび/または中継のモビリティを含む）
マルチリンク接続性（例：マクロ-リレー間、リレー-リレー間）
リレーのローミング、規制要件、緊急サービス、セキュリティ、優先サービス、RAN管理。

目的
本SIでは、UEへの無線アクセスと5GCへの無線セルフバックホールのためにNRを使用し、車両に搭載可能(Vechicle Mouted)な基地局（BS）リレーの動作をサポートするための5Gシステムのアーキテクチャとシステムレベルの拡張を検討する。

UEまたはUEグループの効率的なモビリティとサービス継続性により、異なるモビリティシナリオ（移動基地局リレーのモビリティを含む）中に効率的にデータを配信することができる。
リレー構成、地理的制限、QoS、移動基地局リレーを介したUEアクセスの認可と制御などを管理するためのプロビジョニング、ポリシー、メカニズム。リレー構成はIABのみを考慮する。
移動基地局中継のローミング（MTおよびDUコンポーネントのローミングを含む）、レギュレーション要件（緊急、優先サービス、公共安全など）のサポート、移動基地局中継にアクセスするUE向けの位置情報サービスのサポート

FS_EDGE_Ph2, Study on Edge Computing Phase 2, Patrice Hédé, Huawei , -, SP-211638

前提知識
ここでは、3GPP公式の解説記事(Enabling Edge Computing Applications in 3GPP
に基づき過去の3GPPのEdge Computingの検討内容を記載している。

エッジコンピューティングは、サービスをユーザの近くでホストすることを可能にするコンセプトで、エンドツーエンドの遅延を大幅に削減し、トランスポートネットワークの負荷を減らすことで効率的なサービスを提供する。仮想現実や拡張現実、IoT、産業用IoT、自律走行、リアルタイムマルチプレイヤーゲーム、スプリットコンピューティングなど、いくつかの新しい拡張ユースケースへの展望が期待されている。
エッジコンピューティングには、複数のプロバイダー間の関係が必要となる。Edge Computing Service Providers(ECSP)は、MNOやApplication Service Providers (ASP)との合意に基づき使用されるインフラを提供する。

Release 17では、3GPPネットワークにおけるエッジコンピューティングのネイティブサポートを提供することを目標とし、アプリケーション層アーキテクチャ(SA6)、コアネットワーク(SA2)、セキュリティ(SA3)、メディア処理(SA4)、および管理の側面(SA5)をそれぞれで検討がなされた。

2020年1月、SA6はTR 23.758に基づき、エッジアプリケーションを可能にするアーキテクチャのnormative workを開始した。この作業で、UE上で動作するアApplication Clients (AC) と、エッジデータネットワーク上に展開されたEdge Application Servers (EAS)間の通信を可能とするためのenablingレイヤーが定義された。サービス継続のためのEAS間のアプリケーションコンテキスト転送や、サービスイネーブルメント、EASへのNEFサービスを提供することも目的としていた。

上記のアプリケーションアーキテクチャ（3GPP TS 23.558）は、主にEASの検出を担当するEdge Enabler Server (EES)、UE内のACにEAS検出などのサポート機能を提供するEdge Enabler Client (EEC)、EECにEASとの接続設定を行うEdge Configuration Server (ECS)から構成されている。

関連TR, TS
SA2: 3GPP TR 23.748 - Study on enhancement of support for Edge Computing in 5GC
SA3: 3GPP TR 33.839 - Study on Security Aspects to support Edge Computing in 5GC
SA4: 3GPP TR 26.803 - Study on Streaming Architecture extensions For Edge processing
SA5: 3GPP TR 28.814 - Study on enhancements of Edge Computing management
SA6: 3GPP TR 23.758 - Study on application architecture for enabling Edge Applications
SA6: 3GPP TS 23.558 - Architecture for enabling Edge Applications

以下、SA2,SA6のものをピックアップ。（最新化2022/12/27）
Release-17
SA2 FS_enh_EC→eEDGE_5GC
SA6 FS_EDGEAPP→EDGEAPP

SA2 Rel-17 TR 23.748 Study on enhancement of support for Edge Computing in 5G Core network (5GC)
SA2 Rel-17 TR 23.948 Deployment guidelines for typical edge computing use cases in 5G Core network (5GC)
SA2 Rel-17 TS 23.548 5G System Enhancements for Edge Computing; Stage 2

SA6 Rel-17 TR 23.758 Study on application architecture for enabling Edge Applications
SA6 Rel-17 TS 23.558 Architecture for enabling Edge Applications

Release-18
SA2 FS_EDGE_Ph2→EDGE_Ph2
SA6 FS_eEDGEAPP→EDGEAPP_Ph2

SA2 Rel-18 TR 23.700-48 5G System Enhancements for Edge Computing; Phase 2
SA6 Rel-18 TR 23.700-98 Study on enhanced Architecture for enabling Edge Applications

背景
エッジコンピューティングは、Rel-15以降、5GSでサポートされている。Rel-17 FS_enh_EC studyでは、EASの発見と再発見、エッジの再配置など、エッジコンピューティングをサポートするためのさらなる機能拡張が検討されている。FS_enh_EC研究からの4つの重要課題は結論に達し、TR 23.748に従って標準化フェーズに移行しました。Rel-17のスケジュールにより、異なるN6-LANでの連続トラフィックステアリングに関するキーイシューは、Rel-17では対応されませんでした。
さらに、Rel-17検討中に提起されたものの、Rel-17の時間的制約により検討されなかった課題もある。その課題とは以下の通りです。

ローミング時の VPLMN 内のエッジ・ホスティング環境（EHE）へのアクセスのサポート .
現在の仕様では、UE が Home Routed PDU セッションを介して EAS にアクセスすることはサポートされていません。したがって、ローミング中のUEがVPLMNに配備されたEHE内のEASにアクセスしたい場合、ローカル・トラフィック・ルーティング用に専用のLBO PDUセッションを確立し、その他のサービス用に別のHR PDUセッションを確立しなければなりません。HLPMNによって決定されるURSPルールでは、これらのアプリケーションに1つ以上の専用DNNを割り当てる必要がある。
ローカルUPF/NEFを介したエッジ・アプリケーション・サーバへのUEトラフィック関連情報の高速かつ効率的なネットワーク公開を改善し、ネットワーク輻輳ステータスなどの追加情報の公開をサポートする。
より詳細な UE のセットに対するオフロード・ポリシーの定義のサポート。
UEがあらかじめ定義されたグループのメンバーではなく、同じように扱われるべきシナリオ（UEが移動している間、マルチユーザーゲームやプラトゥーニングなどで同じEASを使用しようとする場合など）において、UEの収集のためのPSA-UPFおよびEAS（再）ロケーションに影響を及ぼす。
デバイスの接続設定の競合（例：3GPP接続以外の手段（例：非統合Wifi））により、UEがEC PDUセッションおよび5GSからECトラフィックを完全に切り換えることを回避するための潜在的な必要性と解決策を検討する。
どのEASを使用したいかを5GCに示すために、今日、AFは対応するDNAIを提供することが要求されている。しかし、DNAIは5GCの情報であり、AFに提供し、最新に保つことは難しい。その場合、5GCは、設定されたマッピングに基づいて、IPアドレスまたはIP範囲に関連するDNAIを提供するサービスをAFに提供することができる。
最後に、SP-210583 の SA#92E LS で示されたように、進行中の GSMA Operator Platform Group の作業が SA2 作業に影響を与える可能性がある。
この研究は、5GSにおけるエッジコンピューティングのサポートを完了するために、上記の問題をさらに調査する。

目的
本SIでは、以下の項目を検討する。

VPLMNにおけるEHEへのアクセスをサポートするためのローミングの改善
ローカルUPF/NEFを介した追加データ公開によって恩恵を受ける可能性のあるユースケース（データの特性およびユースケースを満たすためのデータ配信の説明を含む）
ローカルUPF/NEFを介して共通のエッジアプリケーションサーバーに UE トラフィック関連情報をネットワークで公開するためのソリューションとその実行可能性および適合性
事業者内部の設定をサードパーティのAFに公開することなく、UEのより詳細なセットに適合するオフロード・ポリシーをサポートするためのソリューション
UEが同じEAS(Edge Application Servers)を使用する必要があり、事前に定義されたグループのメンバーではない場合など、UEの収集のためにPSA-UPFおよびEAS（再）ロケーションの影響に対するソリューション
デバイス内の接続設定の競合により、UEがEC PDUセッションおよび5GSからECトラフィックを完全に切り離すことを回避するためのソリューション。

FS_5WWC_Ph2, Study on the support for 5WWC Phase 2, Laurent Thiebaut, Nokia, -, SP-211640
前提知識
WWC(Wireless-Wireline Convergence)アーキテクチャは、固定アクセスと移動アクセスの両方を5Gシステムに統合するFMC(Fixed Mobile Convergence)を実現するため、3GPPとBBFで共同で仕様策定を行ってきた。
WWCの全体アーキテクチャ（3GPP/BBFの担当区分も含む）はBBF TR-470にて記載されている。

5G-RG(5G Residential Gateway):5G能力(NAS,QoS,MA PDU等)を備えたRG、ダイレクトモード
ACS(Auto Configuration Server):5G-RGとFN-RGの設定サーバ
AGF(Access Gateway Function):Wireline ANと5GCを接続する
BNG(Broadband Network Gateway):Legacy wireline access IP edge
ES(End System):家庭内デバイス(3GPP手順はサポートしない)
FMIF(Fixed Mobile Interworking Function):BBF A10をN1/N2/N3にインタワークする機能
FN-RG(Fixed Network Residential Gateway):5G-RGとは異なり5G能力を備えないRG、アダプティブモード
TNAP(Trusted Network Access Point):5G-RG内に位置しTrusted Accessである5G-RGに3GPP手順を提供する
TNGF(Trusted Network Gateway Function):5GC側に位置しTrusted Accessである5G-RGに3GPP手順を提供する

背景
有線アクセスのサポートはTS 23.501/502/503およびRelease-16のTS 23.316で規定されている。しかし、いくつかのシナリオはRelease-16のSI/WIでの検討が不十分だった。未解決の問題はRelease-18でさらに検討する必要がある。
SA2はBBFから、Release-16 5WWCでサポートされていない以下のような機能を5GCでサポートするよう要望を受けている。

5G-RGの背後にある異なる非3GPPデバイスのための差別化サービスをサポートする方法

Release-17のTEI17_N3SLICEのでは、信頼できる非3GPPアクセスネットワーク経由での登録時にUEが要求したS-NSSAIをサポートするTNGF/N3IWFを選択する方法について、N3SLICEがUEに影響を与えないという制約があり、上記は解決されていない。

目的
本SIでは5WWCに関して以下の検討を行う。

5G-RG（5Gレジデンシャル・ゲートウェイ）の背後に接続するデバイスのサポート強化（5G-RGの背後に接続するUEおよび非3GPPデバイスに対する差別化サービス（QoSおよびチャージングなど）の提供
信頼できる/信頼できない非3GPPアクセスネットワーク（例：UEが必要とするS-NSSAIをサポートするTNGF/N3IWFを選択する方法）。

FS_AMP_Ph2, Study on 5G AM Policy Phase 2, Chen, Zhuoyi, China Telecom, -, SP-211642

前提知識
5Gで導入されたAccess and Mobility policy(以下、AMポリシー)制御には、サービスエリア制限の管理、RFSPの管理、UE-AMBRの管理、UE Slice-MBRの管理、PCFによるSMF選択の管理が含まれている。
現在(Release-17)のAM Policy情報の一覧はTS 23.503 Table 6.5-1から確認できる。

RFSPインデックスについてはTS 23.501 5.3.4.3 Radio Resource Management functionsで以下のような説明がある。
RANの無線リソース管理をサポートするため、AMFはN2を通じてRANに 'Index to RAT/Frequency Selection Priority' (RFSP Index)パラメータを提供する。RFSPインデックスは、RANで利用可能なあらゆる情報を考慮しながら、特定の RRMストラテジーを適用するために、RANによってローカルに定義された構成にマッピングされる。RFSPインデックスはUE固有のもので、すべての無線ベアラに適用される。RFSPインデックスは例えばRANで以下のように利用される。

idel mode campingを制御するためのUE固有のcell reselection prioritiesを導出する
active mode UEを異なる周波数レイヤーまたはRATにリダイレクトすることを決定する

HPLMNは、Subscribed S-NSSAIに基づいてRFSPインデックスを設定することも可能。AMFは、例えばRegistration手順において、UDMからSubscribed RFSP Indexを受け取る。

なお、RFSP IndexはRANではSPID (Subscriber Profile ID for RAT/Frequency Priority)にマッピングされる。SPIDは8bitで1-128はOperator specific SPID valueに、129-256はreference valueに割り当てられている。(see TS 36.300 Annex I, TS 38.300 Annex D)

背景
Release-17 SA2の課題と要件に基づいて、以下のAMポリシーの機能拡張が望まれる。

AMポリシーは、4G/5Gインターワーキング・シナリオにおいてPCFからAMFにのみ提供され、EPCではサポートされない。シナリオによって、UE の加入データまたはローカルで構成されたポリシーが5G優先であるにもかかわらず、RFSP インデックスが更新されてUEが5Gから4Gに誘導されることがある。MMEはPCFからRFSPインデックスの更新を受信できないため、ネットワークが4Gと5Gで異なるRFSPインデックスを配信した場合、ping-pong問題が発生する可能性がある。(see Discussion Paper S2-2103936 "Discussion on PCF providing RFSP Index to MME/RAN)。5Gから4Gまで"back to 4G"RFSPインデックスを保持する場合、コアネットワークはUEに5Gに戻るよう要求する方法がない。上記より、EPC側でAMポリシー更新をサポートするためのメカニズムを検討する必要がある。

目的
本SIでは、UEが5GCからEPCに移動する(その逆も含む)際にAccess and Mobility（AM）ポリシー制御を提供するために現在のメカニズムの拡張を必要に応じて検討する。

FS_UEPO, Study on of 5G UE Policy Phase 2, Changhong Shan, Intel, -, SP-211649
前提知識
5GCでは、PCFからUEにポリシー情報を提供することができる。UEポリシー情報には、以下が含まれる。

Access Network Discovery & Selection Policy (ANDSP)：UEが非3GPPアクセス・ネットワークを選択する際に使用される。TS 23.503で定義される。
UE Route Selection Policy (URSP)：このポリシーは、UEが送信トラフィックのルーティング方法を決定するために使用される。トラフィックは、確立されたPDUセッションにルーティングすることも、PDUセッションの外部で非3GPPアクセスにオフロードすることも、ProSe Layer-3 UE-to-Network Relayを介してルーティングすることも、新規PDUセッションの確立をトリガーすることもできる。TS 23.503で定義される。
V2Xポリシー（V2XP）：PC5またはUu、あるいはその両方におけるV2X通信のための設定パラメータをUEに提供する。TS 23.287で定義される。
ProSeポリシー（ProSeP）：ProSe Direct Discovery、ProSe Direct Communication、ProSe UE-to-Network Relay、および Remote UE のための構成パラメータをUEに提供する。TS 23.304で定義される。

UEポリシーはN15インタフェースでAMFを経由してNAS-MM内でUEに送信されます。(TS 23.501 Figure 8.2.2.1-1)

TS 23.503 Annex AにはURSP ruleの例が記載されていますので、どのようなことができるかイメージをつかむのに確認しておくとよいです。

背景
UE Policyの現在のデザインにはいくつかの問題点がある。

URSPはHPLMNのH-PCFによってのみ提供され、ローミングの場合、H-PCFはHPLMNとローミング契約している各VPLMNに対して有効なURSPルールを提供するというのが現在の前提となっている。シナリオによっては、異なるVPLMNで使用される場合、同じアプリケーションに要求されるURSPルールが異なる場合がある。さらに、URSP構築は、エッジコンピューティング関連のURSPルール更新（DNN、SSCモード、S-NSSAI更新など）などのよりダイナミックなケースを満たさない可能性がある。そのため、home-routedとLBOの両方のローミングシナリオでVPLMN URSP更新をサポートするために、例えばV-PCFが関与するなど、より動的なメカニズムを検討する必要がある。
オペレータは特定のネットワークスライス（例えばS-NSSAIとDNNの組み合わせに基づく）の使用を、特定の3rd partyサービス事業者に制限することができる。これは、PCFで適切なURSPルールを構築してUE側にそれを提供することで実現できるが、現在5GネットワークはUEによってURSPが施行されたかどうかを把握していない。3rd partyのサービス事業者のアプリケーションがプロビジョニングされたURSPルールを使用してルーティングされた場合、ネットワークはそれを認識する必要がある場合がある。
5GS および EPS における UE ポリシー（URSP）のインターワーキングの取り扱いは TS 24.526 で規定されていますが、ANDSF が展開されていないネットワークや、UEがEPCでURSPを受信できない場合がある。このような場合、EPC側のポリシーが不足しており、UEのポリシーを更新できないため、EPCカバー下にあるときのUEの動作に齟齬が生じる。
GSMA 5GJA は SA2 (S2-2105356) に対し、URSP のトラフィック記述子(traffic descriptor)において、標準的なトラフィックカテゴリー（例：エンタープライズ、ゲーム、ビデオストリーミング等）とoperator-specificトラフィックカテゴリーの両方をサポートする方法を調査するよう要請している。

目的
本SIでは、以下の内容を検討する。

URSP(UE Route Selection Policy)ルールのプロビジョニングと更新手順（HPLMNに基づくポリシー制御の既存のフレームワークを維持しながら、ホームルートおよびLBOローミングシナリオに対応）
UE Policyの要求およびプロビジョニング関連の最適化
5GCおよびEPC間で一貫したURSPでUEプロビジョニングするための拡張
URSPのトラフィック記述子における標準およびオペレーター固有のトラフィックカテゴリーのサポート

FS_5GSATB, Study on 5G System with Satellite Backhaul, Hucheng Wang, CATT, -, SP-211639
前提知識
Release-17 TR 23.737では衛星アクセスにおける5GSでのアーキテクチャの側面の検討がなされた。
衛星アクセスを利用する2つのシナリオとして、以下が記載されている。

normative workにおいては、5GSにおける衛星バックホールをサポートするための機能拡張として以下が規定されている。

ネットワーク・コンフィギュレーションに基づく衛星バックホール・カテゴリの検出
バックホール変更時のPCFへのイベント報告
サテライトバックホールのカテゴリに基づくポリシー決定
サテライトバックホールカテゴリの変更に関するAFへの通知

背景
衛星はモバイルブロードバンドアクセスの広範なカバレッジを提供できる。通信キャリアは、フリンジ領域（例：遠隔ルーラルエリア）、緊急または一時的な措置（例：災害地域、免許承認待ちの間のマイクロ波リンクの代わり）の場合に、衛星をgNB用のバックホールサービスを提供するために使用できる。
Release-17では、5GSのための衛星バックホール接続が検討されてた。この検討は主に、CPとUPのバックホール接続に1つの衛星（GEOまたはNGSO衛星）だけが関与する基本的なケースに焦点を当てていた。

5GSでサテライトバックホール接続を使用する以下のケースは、Release-17では検討されなかった。

gNBが衛星を経由して5GCとISL（Inter Satellite Link:衛星間リンク）接続する場合。
ハイブリッドバックホール（例：衛星と地上のバックホール、または異なるタイプの衛星バックホール）を使用して5GCに接続するgNB。

バックホール接続にISLが含まれる場合、衛星バックホールカテゴリは、ネットワーク構成に基づいてのみ決定することができず（例えば、LEOとGEO間のISLが含まれる場合）、PCFとAFは既存のQoS要件を満たすことができるかどうか判断できなくなる。

衛星リンクはパケット配信の遅延が大きく、帯域幅に制限があるため、衛星バックホールがUEに使用される場合、EC（エッジコンピューティング）サービスの提供や衛星でのローカルスイッチングを可能にするなど、バックホール接続を短縮することが有益と考えられる。
衛星上でECまたはローカル・スイッチングをサポートするという現在のアーキテクチャ要件によると、UPFを衛星上に展開する必要があり、5GSを拡張して衛星上でUPFをサポートする必要がある。さらに、ECサービス（IoTアプリケーションのコンピューティングサービスなど）を提供するためには、衛星上にECサーバを配備する必要もある。

目的
本SIでは以下のトピックを調査することを目的とする。

衛星バックホールのみを有するgNBの場合、遅延の変化や帯域制限のあるバックホールへの対応のためのアーキテクチャ拡張（UPパス上の衛星バックホールのパケット到達遅延や帯域の検出に基づくポリシー／QoS制御の拡張、バックホール情報のAFへの公開などを含む）。
地上のgNBを持つGEO衛星に展開されたUPFをサポートするためのアーキテクチャの強化（データ伝送の待ち時間を短縮し、バックホール資源の消費を最小限に抑えるために、搭載されたUPFを介して衛星エッジコンピューティングサービスを有効にするかどうか、またその方法、通信中のUEが搭載されたUPFによってサービスを受ける場合のローカルスイッチを強化する方法などを含む）。

FS_5GSAT_Ph2, Study on satellite access Phase 2, Jean-Yves Fine, Thales, Sherry(Yang) Shen, Xiaomi, SP-211651
前提知識
Release-17のSIであるFS_5GSATでは、5Gにおける衛星アクセスのサービス要件に対応するため各種検討を行い結果をTR 23.737にまとめている。下の図はTR 23.737で提起されたKey issuesとそれに対するSolutionsの対応を示している。背景が白のKey issuesはsolutionが提示されなかったもの、また背景が白のSolutionsは提示されたものの、比較検討により採用されなかったものを示している。

背景
Release-17の5GSAT_ARCHでは、5Gにおける衛星アクセスのサービス要件に対応するためのnormative workだったが、いくつかの側面は考慮されておらず十分に実現されていない。１つがNGSO再生(regenerative-based)ベースの衛星アクセス。Key Issue #6(RAN mobility with NGSO regenerative-based satellite access)とその解決策はTR 23.737で示されたが、RANがこの機能をサポートしていないため、Release-17では解決策が規定できなかった。

Release-18での優先順位付けの後、NGSO再生ベース衛星アクセスの5GCアーキテクチャへの影響に関する検討を行う予定となっている。

RAN WGでは、5GCに影響を与える機能として、不連続カバレッジ(Discontinuous coverage)も提案されている。不連続カバレッジの動的なサポートは、最初のNGSOコンステレーション展開に必要であり、衛星故障、コンステレーションのマイグレーションに対応するためにも必要となる。UE は、コンスタレーションがまばらであるため、特定の時間や場所でのみ衛星サービスのカバレッジにアクセスすることとなる。UEは、効率的なページングのためネットワークがUEの位置を認識できない時間が発生する。このため、モビリティ管理を強化する必要がある。また、特にMIoT UEでは、電力効率の観点からUEが常時起動している必要はないかもしれない。そのため、UEが一時的に圏外になった場合の予測、UEウェイクアップ時間の認識・通知、データの保存・転送に関するメカニズムが必要となる可能性がある。また、動的なビーム構成の使用によりビーム/セルが断続的になる動的なGEOシステムに関連する不連続なカバレッジも重要な側面となる。この問題は、ブロードキャスト／マルチキャストの場合にも適用される。
Release-18 の検討のための優先順位付けプロセスの後、ブロードキャスト/マルチキャストの不連続カバレッジをサポートするためのアーキテクチャの強化はこのSIDから除外され、RANの要求があればRelease-18中に再び検討される可能性がある。

目的
本SIでは、衛星アクセス時の5GC/EPCの拡張をさらに検討する。

モビリティ強化（例：ページング強化）のための不連続カバレッジのサポート
UEウェイクアップ時間の予測・認識・通知の検討
省電力最適化

FS_UPEAS, Study on UPF enhancement for Exposure And SBA, Yan Han, China Mobile, -, SP-211652
背景

目的
本SIでは、UPFの5GC SBAへのより良い統合のためのサポートのため以下を検討する。

UPF event exposureサービスの登録／解除、およびNRFを介した発見。
PCF、NWDAF、CHF、NEF、Trusted AF、およびその他の NF による UPF 公開サービスの消費(consumption)などをサポートする UPF event exposureサービス。
アーキテクチャへの影響を考慮した UPF event exposureサービスの使用状況の評価。

FS_SUECR, Study on Seamless UE context recovery., Lalith Kumar, Samsung, -, SP-211654
背景
UEには特定のイベント(以下)があり、その処理はUEの実装に委ねられている。

モデムでのサイレント・リセット
セキュリティパッチの更新
OSのアップグレード
モデムSWの更新
OMA-DMによるモデム設定変更時の端末リブート

これらをUEの実装に任せることにより以下の問題が生じる。
上記のイベントのうち、OSのアップグレードやモデムソフトウェアの更新（一般にバイナリ更新とも呼ばれる）を実行するには、デバイスメーカー、オペレータ、アプリケーションファンクションの3者が関わってくる。UEがバイナリをダウンロードした後、UEがアップグレードを実行するタイミングはUEの実装に委ねられており、一部のUE実装はユーザーの入力を求めますが、オペレーターやアプリケーションファンクションからの入力は得られません。これらのUEは、UEでこのような操作が行われるたびに、数分単位で使用できなくなる。UEはコアネットワークの事前情報なしに利用できなくなるため、「unavailability period」中に、アプリケーションファンクションの重要の動作に影響を与える可能性がある。
そのため、UEとオペレータ／アプリケーションファンクションとの間で調整を行う必要がある。

目的
本SIでは、5GSでUEの「unavailability period」が決定される可能性を調査する。これは、モデムソフトウェアのアップグレード、OSのアップグレード、セキュリティパッチの更新など、UEの実装次第で数分単位でUEが利用できなくなるシナリオにおいて、UEとオペレータ/アプリケーションファンクション間の調整の必要性に対応するものである。

FS_5G_ProSe_Ph2, Study on Proximity-based Services in 5GS Phase 2, Qiang Deng, CATT, Fei Lu, OPPO, SP-211653
前提知識
ProSe（Proximity based Services）は、商用サービスと公共安全(Public Safety)サービスの両方をサポートするために、Release-12からEPSで開発されてきた。Release-14では、LTE上のV2Xサービスがサポートされた。
5GSでは、ProSeは、さまざまなアプリケーションやサービスをサポートするための重要な機能となることが期待されている。Release-16では、PC5ベースのアーキテクチャと通信が開発され、高度なV2Xサービスがサポートされた。
5G ProSeは以下から構成される。

5G ProSe Direct Discovery：5G ProSe 対応の UE が NR を使用して近接していることを識別する
5G ProSe Direct Communication：NR を使用して直接通信範囲にある 2 つ以上の 5G ProSe 対応 UE 間の通信パス確立を可能にする
5G ProSe UE-to-Network Relay：5G ネットワークと UE の間の間接的な通信を可能にします（例：ネットワークのカバレッジから外れたUEなど）

5G ProSeはTS 22.278、TS 22.261、TS 22.115 に定義されたサービス要件に基づきTS 23.304で規定されている。以下は、TS 23.304で規定されるアーキテクチャ図。

ここで、5G DDNMF (5G Direct Discovery Name Management Function) は、動的な5G ProSe Direct Discoveryに必要なネットワーク関連アクションを処理する論理機能となる。5G DDNMF は、PC3a上の手順を使用して 5G ProSe対応UEと対話し、5G ProSe Direct Discovery で使用する ProSe Applications IDとProSe Application Codeのマッピングを割り当てて解決する。

UE-to-Network Relayに関しては、Layer-3リレーとLayer-2リレーのアーキテクチャがそれぞれ定義されている。

Release-17 - Study on System enhancement for Proximity based Services in 5GS (FS_5G_ProSe) TR 23.752
Release-17 - Study on Security Aspects of Enhancement for Proximity Based Services in 5GS (FS_5G_ProSe_Sec) TR 38.847
Release-17 - Proximity based Services (ProSe) in the 5G System (5GS) (5G_ProSe) TS 23.304

背景
以下のProSe機能は、Release-17で標準化されている。

近接サービスのための 5G システムアーキテクチャ
PC5 ダイレクト・ディスカバリーのサポート（カバレッジ内およびカバレッジ外のケースを含む）
PC5 ユニキャスト、グループキャスト、ブロードキャストモード通信のサポート（カバレッジ内およびカバレッジ外のケースを含む）
PC5サービス認可とポリシー/パラメータプロビジョニングのサポート
PC5とUuの間の直接通信経路選択のサポート
PC5への課金サポート
レイヤー3およびレイヤー2ベースのUE間中継のサポート（QoSおよびサービス継続の側面を含む）

しかし、時間的制約のため、SA#86会議において、以下はRelease-17 FS_5G_ProSe検討項目から外された。

UuインタフェースとPC5インタフェース間の直接通信パス切り替えのサポート

また、SA2#145eでは、UE-to-UE Relay は Release-17 5G ProSe WIで検討されないことが決定された。
TS 22.278 および TS 22.261 で定義されたサービス要件をさらに満たすために、Release-17 内で標準化されていない上記のすべての項目は、Release-18 のSIでさらに検討される必要がある。
また、TS 22.278 および TS 22.261 に含まれる近接サービスに関する新しい要件（リレーを介した緊急サービスなど）もあり、Release-18 SIで検討する必要がある。

目的
本SIでは、以下の項目をサポートするための5GS拡張を検討する。

ユニキャストのためのシングルNR PC5ホップUE-to-UE Relayのサポート
UE-to-Network Relay（NR PC5とNR Uuが使用されている場合）のための2つの間接的なネットワーク通信経路を切り替える際のサービス継続性
直接NR Uu通信路と直接NR PC5通信路のパス切り替えの対応（非リレーの場合など）
レイヤ 2 のUE-to-Network Relayにおいて、直接網通信路と間接網通信路を切り替えた場合のサービス継続性
信頼性またはデータレートの向上のため、 UE-to-Network Relayに1つの直接ネットワーク通信経路と1つの間接ネットワーク通信経路のみを使用するマルチパス伝送
UE-to-Network RelayによるリモートUEへの緊急サービス対応

自動化と最適化

WI/SIコード	タイトル	ラポーター1	ラポーター2	RAN影響	承認済WID/SID
FS_AIML	Study on System Support for AI/ML-based Services	Tricci So, OPPO	David Gutierrez Estevez, Samsung	-	SP-211648
FS_eNA_Ph3	Study on Enablers for Network Automation for 5G - Phase 3	Aihua Li, China Mobile	Xiaobo Wu, vivo	-	SP-211650
FS_eNS_Ph3	Study on Network Slicing Phase 3	Jinguo Zhu, ZTE	Myungjune Youn, LGE	RAN?	SP-211641

FS_AIML, Study on System Support for AI/ML-based Services, Tricci So, OPPO, David Gutierrez Estevez, Samsung, SP-211648
背景
Release-18 ステージ1のAMMT研究（AI/ML Model Transfer）は既に完了しており、5GSがアプリケーション層上でAI/MLベースのサービス転送をどのようにサポートするか要件を規定している。
この研究では、アプリケーション層のAI/MLモデルの配信と転送（ダウンロード、アップロード、更新など）をサポートする5Gシステムのユースケースと潜在的パフォーマンス要件に取り組み、さまざまなアプリケーション（映像/音声認識、ロボット制御、自動車、その他の垂直分野など）のAI/MLモデルの配信、転送、トレーニングのトラフィック特性を解決してきた。
Release-17 5GSでは、ネットワーク自動化のためにNWDAFを介して5GC内でAI/MLトレーニングおよび推論をサポートする予定だが、デバイスベースのアプリケーションAI/MLトレーニングまたは推論サービスをサポートするための5GSランスポートソリューションは存在せず、検討が必要となる。

目的
本SIは、映像/音声認識、ロボット制御、自動車など様々なアプリケーションのためのAI/MLモデルの配布、転送、トレーニングをサポートするために、5GS支援によるAI/MLサービス＆トランスミッションを調査することを目的とする。AI/ML操作のAI/MLエンドポイント間の分割、5Gシステム上でのAI/MLモデル/データの配布と共有、5Gシステム上での分散/フェデレーテッド学習（Federated Learning）を含む。

アプリケーション層のAI/ML運用をサポートするために可能なアーキテクチャと機能拡張の検討
通常の（非アプリケーションAI/ML）5GSユーザートラフィックをサポートしながら、アプリケーションAI/ML運用トラフィックをサポートするためのQoS、ポリシー強化の可能性を検討する。
UE上で動作するアプリケーションクライアントとアプリケーションサーバー間の協調的なアプリケーションAI/MLベースのFederated Learning操作を促進するために、AFとUEがFL操作とモデル配布/再分配を管理するための支援を提供する5GS拡張を検討する。

FS_eNA_Ph3, Study on Enablers for Network Automation for 5G - Phase 3, Aihua Li, China Mobile, Xiaobo Wu, vivo , SP-211650
前提知識
5GCでは、ネットワークの自動化とデータ分析のため3GPP Release-15でNWDAFが導入された（仕様はRelease-16から規定）。NWDAFは、5GC NFおよび運用管理（OAM）に分析を提供する。ネットワークポリシーの決定は、ネットワーク分析に基づいて行われ、ポリシー制御機能（PCF）またはNWDAF出力をサブスクライブしている他の5GC NFが、NWDAFによって提供される分析情報を考慮して、ポリシーの更新などの決定を実行できる。NWDAFから提供される分析情報には以下のようなものがある。(see TS 23.288)

以下の記事、資料もNWDAFの前提知識を得るには以下がおすすめです。
NTTドコモテクニカルジャーナル：3GPP Release 16における5Gコアネットワークの高度化技術の概要
KDDIの中野先生の資料：3GPP概要にも

関連WI/SI

Release-16 - Study of enablers for Network Automation for 5G (TR 23.791)
Release-16 - Architecture enhancements for 5G System (5GS) to support network data analytics services (TS 23.288)
Release-17 - Study on Enablers for Network Automation for 5G - phase 2 (TR 23.700-91)
Release-17 - Study on User Plane Function (UPF) enhancement for control and 5G Service Based Architecture (SBA) (TR 23.753)

背景
Release-15とRelease-16での作業に基づいて、Release-17では、5GC情報公開とネットワークデータ分析を活用したネットワーク自動化をサポートするためのさらなるフレームワークとソリューションが検討されている。アーキテクチャのさらなる強化、新しいケース、Rel-17の積み残しについて議論することは有益であると思われる。この研究はまた、NWDAFの様々な展開オプションを調査することを目標とする。

目的
本SIは、5GSがネットワークの自動化をサポートするためのNWDAFをさらに拡張することを目的としている。具体的には、5GC NFの意思決定をサポートすることを目的とした分析に焦点を当てている。NWDAFへの必要なインプットと必要なNWDAFのアウトプットをさらに調査し、ネットワークデータ解析のためのアーキテクチャ拡張、新しいシナリオ、Rel-17の残課題を検討する。

NWDAF分析の正確さを向上させるための可能なメカニズム
NWDAFがどのようにアプリケーション検出を支援できるかを確認する
ローミング時のデータおよび解析の交換をサポート
データ収集とデータ保存の強化
異なるベンダーのMLモデル共有のためのトレーニングの強化
MDAS/MDAFの機能をデータ収集と分析に活用するためのNWDAF間の相互作用
QoS Sustainability 分析に関する機能強化。

FS_eNS_Ph3, Study on Network Slicing Phase 3, Jinguo Zhu, ZTE, Myungjune Youn, LGE, SP-211641
背景
Rel-17のRAN3は、TR 38.832の次のシナリオとソリューション候補を調査した。

ターゲットRANノードでネットワークスライスがサポートされない、またはネットワークスライスのリソースが制限されることによるUEモビリティ時のスライスサービス継続のサポート

SA2はS2-2102068でLSを送り、TRに記載されたシナリオが有効であることを確認した（すなわち、ネットワークスライスがPLMNのすべてのTAで利用可能である必要はない）。しかし、CN/UEに影響を与えるソリューションは推奨されず、追求する前にエンドツーエンドシステムの観点からSA2研究が必要となる。
このようなシナリオがある：Requested NSSAIのS-NSSAIは、TAではサポートされていため拒否されるが、近隣のTAではサポートされている可能性がある
AMFは、Allowed NSSAIのS-NSSAIのためにそうすることが最適であるため、登録領域に近くのTAを含める必要があるかもしれない。したがって、これが実行され、rejection causeが「not supported in the RA」である場合、UEは、UEがRAから移動するまで、拒絶されたS-NSSAIで登録を試みることができない。これが望ましくない場合、AMFは、現在のTAおよびRejected S-NSSAIがサポートされていないTAに限定されたRAを割り当てることができ、これにより、UEがRejected S-NSSAIをサポートする近くのTAに移動したときに、UEがRejected S-NSSAIに登録することが可能になるだけである。この研究では、AMFがRAのサイズを縮小することを強制することなく、UEが要求しているがTAで利用できないネットワークスライスを選択し、RAの他のTAで利用可能なUEが要求可能にする能力を向上させるソリューションを調査する。

SA1 は、TS 22.261 6.1.2.1の新しい要件に合意している。

ローミング中の UE が、サービング・ネットワークから提供されていないが、他のネットワークからそのエリアで利用可能なネットワーク・スライスを必要とするサービス／アプリケーションをアクティブ化する場合、HPLMN は、UE がそのネットワーク・スライスのために登録できる VPLMN の優先順位情報を提供できるようにしなければならない（shall）

UEが登録を実行する際、UEは「Configured S-NSSAI」、「Allowed-NSSAI」に基づいて「Requested-NSSAI」を生成し、さらにURSPルールを考慮することもできる。UEは、使用する予定のないS-NSSAI（例えば、実行中のアプリケーションによるネットワーク・スライスのPDUセッションの確立）を一度に登録し、場合によっては本RAに登録されていない可能性があります。アプリケーションが終了した後も同様であり、PDUセッションは、UE内の他のアプリケーションによって使用（例えば、PDUセッションを介して実行中のアプリケーショントラフィックを配信）されない可能性がある。これは、例えばNSACが展開された場合、追加のUEがこのS-NSSAIを登録できず、PDUセッションのためのS-NSSAIを要求することになるため、オペレータの顧客は問題として認識する可能性がある。
もう1つの問題は、可用性に関連するSLAを顧客と締結している場合があることです。ネットワーク・スライスが混雑し、他のネットワーク・スライスが SLA をより良く提供できる場合、ネットワークは UE トラフィック・フローを別のスライスで提供した方が良いと判断する可能性があります。この検討では、UEの登録や PDU セッションの確立を含むネットワークスライス使用のネットワーク制御動作を保証するためにシステムを強化する可能性を調査する必要があります（例えば、NSAC を実行するときにネットワークスライスが実際のアクティビティを持つ UE/PDU セッションを提供できるようにするため）。
特定のネットワークスライス上で提供されるサービスは、サービスエリア（展開されたTA境界と一致しない）および／またはデプロイメント時間（例えば、あるイベントをカバーするために提供されるサービス）が制限されている場合がある。このようなシナリオを可能にするために、ネットワークスライスの終了に特に重点を置いて、運用と混乱を最小化するためにより最適に展開をサポートするメカニズムを定義することが望ましいと思われる。
リリース17では、NSACFはネットワークスライス入場制御（NSAC）を実行するために定義されています。1つのネットワークスライスに複数のNSACFが関連付けられる可能性がある。現在、1つのネットワーク・スライスに関連するすべてのNSACF間で共通の最大許容数を動的に使用するメカニズムが定義されていないため、オペレータはネットワーク・スライスのPDUセッションまたはUEの最大許容数を各NSACFに分割する必要がある。

目的
本SIではネットワーク・スライシングのさらなる強化として、以下を検討する予定。

RAの最初のTAで拒否されたが、RAの別のTAで利用できる可能性がある拒否されたS-NSSAIの登録手順を開始する方法。
ローミングシナリオにおいて、UEが使用したいネットワークスライスをサポートするVPLMNからサービスを選択し取得できるように、ローミング国で利用可能なVPLMNのネットワークスライスの利用可能性に関する情報を拡張する。
UE登録やPDUセッションの確立を含むネットワークスライス利用のネットワーク制御された動作を保証するためのシステム強化方法
提供されるサービスが、既に展開されているトラッキングエリアと重複しないサービス領域を持っている場合、および/または寿命が限られている場合の展開の検討、およびネットワークスライスを含む既存のメカニズムがそのようなシナリオのサポートに役立つ方法
1つのPLMN内のネットワークスライスまたはローミングにおいて、複数のNSACFがUEまたはPDUセッションの共有最大許容数の実施に関与する場合、共有最大許容数の断片化を避けるために、NSACのサポートを強化する方法。

3GPP SA2における5G-Advancedの検討状況

WID/SID分析

IoT/TSC/URLLC

アーキテクチャ拡張

自動化と最適化

Discussion