🗺️

5G-Advanced解説(3GPPリリース18 SA2機能)前編

2022/01/22に公開

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

2021年12月20日、3GPP SA TSGのSAプレナリー会合#94e(SP-94e)において、リリース18でSA2で取り組む合計28個のWork Item/Study Item (WI/SI)の承認を行いました。3GPPリリース18は、5G-Advancedの最初のリリースとなります。承認されたWI/SIには、TSN、ネットワークスライシング、エッジコンピューティングのさらなる拡張、ネットワークオートメーション、ロケーションサービス、AI/MLベースのサービス、XRサービスなど、いくつもの項目が含まれているようです。この記事では、それらの5G-Advancedに対して承認されたWI/SIのそれぞれについて解説します。

この記事ではSA TSGの中でもSA2にのみ解説します。その他のSA WGやRANで承認されたWI/SIの全リストについては3GPP公式のこちらを参照して下さい。赤枠の箇所が今回の範囲です。

本記事に関連して3GPP標準化関係の記事を書いておりますので、基礎的なところを確認されたい方は以下の記事も目を通していただけると嬉しいです。
https://zenn.dev/nic/articles/0d71b805e8b5fe

https://zenn.dev/nic/articles/0c3be6394b2000

3GPPリリース18 SA2機能

3GPPリリース18 SA2機能で現在承認されているWI/SIセットを表で示します。
各WI/SIついて以降のセクションで詳しく説明します。

WI/SI一覧

表はSP-211655を参照に作成し、著者の主観で「新サービス/既存サービス拡張」「IoT/TSC/URLLC」「アーキテクチャ拡張」「自動化と最適化」に分類してみました。また、コアネットワークだけでなくRANへ影響がありSA2とRANxと共同で検討が進められると予想されるWI/SIについて「RAN影響」の列で印を付けています。また、WID/SIDに対するリンクも貼っていますので1次情報を直ぐに確認することもできます。

新サービス/既存サービス拡張

WI/SIコード タイトル ラポーター1 ラポーター2 RAN影響 承認済WID/SID
FS_XRM Study on XR (Extended Reality) and media services Dan Wang, China Mobile Hui Ni, Huawei RAN2 SP-211646
FS_MMTELin5G Study on evolution of IMS multimedia telephony service Yi Jiang, China Mobile - - SP-211644
FS_5MBS_Ph2 Study on 5G multicast-broadcast services Phase 2 Meng Li, Huawei - RAN2 SP-211645
FS_eLCS_Ph3 Study on 5GC LoCation Services Phase 3 Ming Ai, CATT Runze Zhou, Huawei RAN1 SP-211637
FS_Ranging_SL Study on Ranging based services and sidelink positioning Sherry (Yang) Shen, Xiaomi - RAN2 SP-211647

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

アーキテクチャ拡張

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

自動化と最適化

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

WID/SID分析

ここからは各WI/SIのWID/SIDの中身について解説していきます。
各WI/SI毎に「背景」「目的」を記載していますが、それぞれWID/SIDの「3 Justification」「4 Objective」に対応しており、私が一通り読んだ上で自動翻訳にかけてある程度要約して読みやすくしたものになります。私としても情報ソースはこれだけなので、不明点やもっと詳しく知りたい場合はぜひご自身でWID/SIDを読んでみて下さい。
一部のSIには「前提知識」として、SIを理解する上で必要となる基礎知識の解説や、この検討につながるまでの経緯などを記載するようにしました。検討フェーズが2以上のものについてはなるべく記載しています。

なお、この記事では「新サービス/既存サービス拡張」「IoT/TSC/URLLC」「アーキテクチャ拡張」「自動化と最適化」のうち、最初の「新サービス/既存サービス拡張」についてのみ解説をしています。その他の解説は本記事の後編(執筆予定)を参照下さい。

新サービス/既存サービス拡張

FS_XRM, Study on XR (Extended Reality) and media services, Dan Wang, China Mobile, Hui Ni, Huawei, SP-211646
背景
5G時代には、モバイルメディアサービス、クラウドAR/VR、クラウドゲーミング、動画による機械やドローンの遠隔操作など、5Gネットワークへのトラフィックの貢献度がますます高まると予想されている。すべてのメディアトラフィックは、どのコーデックが使用されたかにかかわらず、いくつかの共通した特徴を持っている。これらの特性は、より良い伝送制御と効率化のために非常に有用です。しかしながら、現在、5GS では、これらの情報を十分に活用することなく、メディア・サービスを他のデータ・サービスと一緒に処理するために、一般的な QoS メカニズムを使用しています。
トラフィック特性の例としては以下が挙げられる。

  • アプリケーションはフレームをデコードするためにこれらのパケットをすべて必要とするため、フレーム内のパケットは互いに依存関係にあります。そのため、1つのパケットが失われると、他のパケットは正常に送信されていても役に立たなくなります。例えば、XRアプリケーションでは、単一のパケット/PDUではなく、メディアユニット(Application Data Units)単位で要件が課されます。
  • 同じビデオストリームであっても、異なるフレームタイプ(I/Pフレーム)やGoP(Group of Picture)内の異なる位置のパケットは、ユーザー体験への貢献度が異なるため、ビデオストリーム内のレイヤーQoS処理は、要件を緩和し、高効率につながる可能性があります。

本SIでは、XRや他のメディアサービスの特性を考慮したQoSメカニズムの拡張を検討する。

目的
本SIでは、高データレート低遅延 (HDRLL(High Data Rate Low Latency)) サービス、AR/VR/XR サービス、触覚/マルチモダリティ通信サービスなど、先進メディアサービスのサポート向上に関連するシステムアーキテクチャについて、以下のトピックを含めて検討する。

  • マルチモダリティ・サービス対応のための機能強化
  • 5GSとアプリケーション間の相互作用をサポートするためのNEFの拡張
  • XRサービスやメディアサービスにおけるQoSやポリシーの強化のための伝送
  • メディアサービスのトラフィックパターンを考慮した電源管理の拡張

FS_MMTELin5G, Study on evolution of IMS multimedia telephony service, Yi Jiang, China Mobile, -, SP-211644
背景
3GPP ネットワーク事業者は、インターネットアクセス、音声、マルチメディア通信などの既存サービスのサポートに伴い、継続的に増加するトラフィック需要に対応するよう努めている。AR/VRメガネ、カメラ、ロボット、スマートウェアラブル、トランク型デバイスなど、より多くの種類のデバイスが出現している。また、リアルタイム通信は産業用途にも広がっています。これらの要件は、現在のネットワークトラフィックやサービスモデルを定義しているものとは大きく異なり、既存のネットワークに大きな課題を突きつけています。
これらバーティカル・インダストリーのサービス要件は、通常の電話サービスとは異なるため、IMSアーキテクチャやIMS手順の拡張が必要になる場合がある。

目的
本SIでは、以下の観点からのシステムアーキテクチャのソリューションを検討する。

  • リリース18 eMMTEL の要件のサポートが、ARテレフォニー通信をサポートし、また、事業者ネットワーク経由で第三者が検証すること(例:従業員が特定のID情報の使用または参照を許可されていること)をサポートするために、IMS アーキテクチャと機能性にどのような影響を与えるか検討する。
  • IMS ネットワークでのデータチャネル使用をサポートするための IMS アーキテクチャと手順の影響。これには、CP とメディアプレーンを分離したデータチャネルサーバー、およびデータチャネルアプリケーションリポジトリ用の IMS アーキテクチャで定義されているか、どのような機能性があるかが含まれる
  • 後方互換性を考慮し、SIPをIMSのコア信号プロトコルとして維持しつつ、可能な限り新しいアプリケー ションと効率的なメディア処理のために既存と新規の両方の機能をサポートする、Cx/DxおよびSh/Dh以外のサービスベースの アーキテクチャに適用できるIMSメディア制御インタフェース。

FS_5MBS_Ph2, Study on 5G multicast-broadcast services Phase 2, Meng Li, Huawei, -, SP-211645
背景
Rel-17では5G MBS(マルチキャストブロードキャストサービス)が定義された。具体的には、指示されたロケーションエリアへの配信、モビリティ、MBSセッション管理、QoS、およびEPCベースの公共安全向けeMBMSとの相互運用がTR 23.757で検討され、TS 23.247で規定された。
しかし、Rel-17 の標準化作業中に、RAN WG によって Rel-17 の作業から除外されたいくつかの側面は解決できなかった。1つの側面としてRRCインアクティブ状態でマルチキャストMBSデータを受信できるようにすることは、特定地域に多数のUEが存在する場合に有益となる。この他にも、RAN WGsによるRel-18での機能拡張の可能性があり、新しいMBS機能が強化される可能性がある。したがって、対応する機能がRel-18で適切に対処されるように、FSが必要となる。
バックグラウンドオーディオ/ビデオストリーム、ゲーム中のステータス/警告アップデート、共同インタラクティブアプリケーションの共有ストリーミングなど、ユーザーグループによって共有されるサービスについては、サービス用の一時的なマルチキャストグループを有効にすると、事業者がリソース効率よくサービスを提供できるようになり、サービスによって必要なときに動的にマルチキャストセッションを作成し、不要なときに解放するなど、柔軟性が高まるため有益と考えられます。基本的な関連機能はRel-17で利用可能ですが、潜在的な機能強化は今後検討が予定される。
4Gで定義されたeMBMSはIoTデバイスのグループ・メッセージ配信をサポートしていましたが、Rel-17で定義された5G MBSはまだこの機能を提供していない。また、省電力化により、IoTデバイスが調整された時間にMBSコンテンツを受信できない可能性がある。

目的
本SIでは、エンドツーエンドの手順/機能およびアーキテクチャを含むMBSの範囲を拡大するために、5Gマルチキャスト/ブロードキャストアーキテクチャをさらに拡張することを検討する。

  • 多数のUEを含むエンドツーエンドのMBSトラフィック配信のサポートと拡張
  • AFをトリガーとしたオンデマンドマルチキャストMBSセッションのサポート、および特定のサービスに対してマルチキャストおよび/またはユニキャスト配信を選択する5GCを介した効率的なリソース使用
  • NEFの拡張、既存の省電力機構とMBSの共存など、能力に制限のある機器へのグループメッセージ配信をサポート
  • 公共安全 UE の数が多い場合の潜在的な性能問題を調査し、見つかった場合は、そのシナリオに必要な5MBSの機能強化を検討する。

FS_eLCS_Ph3, Study on 5GC LoCation Services Phase 3, Ming Ai, CATT, Runze Zhou, Huawei, SP-211637
背景
位置情報サービスは、IIoTユースケースなどのユースケースにおける位置情報サービスの高精度かつ低遅延のサポートを含む、レギュレーションおよび商用位置情報サービスの両方をサポートするためにRel-15、Rel-16、Rel-17で規定されている。
Rel-17では、SA2およびSA6においてエッジコンピューティング機能のサポートがさらに進展しています。エッジ・コンピューティング導入シナリオでは、いくつかの問題(E2Eの観点からロケーション・サービスのレイテンシをどのように削減するか、UEの位置推定をエッジのアプリケーションにどのように公開するかなど)がまだ検討されていない。
Rel-16以降、NWDAFはネットワークデータの解析を他のネットワーク機能に提供するよう拡張されている。しかし、ロケーションサービスがNWDAFの恩恵を受けられるかどうか、またどのように受けられるかについては、まだ検討されていない。
Rel-15以降、ネットワークスライスのサポートが強化され、GSMA NG.116などの他のSDOからの要件が考慮されるようになった。例えば、GSMA NG.116 3.4.20 において、ポジショニングサポート属性は、ネットワークスライスがジオロカライゼーション方式またはサポート方式を提供するかどうかを記述しているが、SA2では5GSがこの要件をサポートしているかどうか検討していない。
上記の考察に基づき、SA2は位置情報サービスに関する作業を継続すべき。

また、Rel-17では、5GSシステムが強化され、衛星アクセスによる5GCのサービス要件がサポートされている(WID: Architecture aspects for using satellite access in 5G内)。ただし、衛星アクセスによる5Gの位置情報サービスについては、以下の点が課題としてある。

  1. UEが衛星アクセスにより5Gにアクセスする場合、緊急通報サービスや通信傍受などの規制要件を持つ一部のサービスでは、UEが報告した位置情報に依存せずにUEの位置を十分な精度で決定するための信頼できる確実な方法が必要とされるが。しかし、Network based UE locationはまだ検討されていない。
  2. TS 22.261v18.4.0 6.3.2.3 節は、衛星アクセスの測位要件を定義しており、TS 22.261v18.4.0 7.3.2.2 節は、衛星アクセスの測位性能要件を定義しています。しかし、これらの要件に対応できるかどうか、またどのように対応できるかは評価されていない。

目的
本SIでは、LCSのアーキテクチャ拡張(例:エッジコンピューティングなどのシナリオ)を検討する。

  • UPによる測位信号をサポートし、LCS遅延、信号オーバーヘッド、位置推定値を低減が含まれる。
  • LCSがNWDAFの報告やユースケースをどのように活用できるか。(例えばTA/セルより小さい単位での位置特定または人口フロー統計データにおける精度の向上など)
  • 低消費電力高精度測位に関連する要件を含む低消費電力測位(RedCap)をサポートするための機能強化
  • UEパワーセービングのための柔軟で効率的な定期的およびトリガーに基づくよる測位をサポートするための拡張機能。
  • 測位基準ユニット(PRU:Positioning Reference Unit)の使用に関連する特定のネットワーク機能。
  • EPSと5GS間のUEモビリティのためのLCS継続性をサポートするための機能拡張。
  • ネットワークで検証されたUEロケーションと、5G衛星アクセスのためのネットワーク制御測位をサポートするためのLCSアーキテクチャの拡張。

FS_Ranging_SL, Study on Ranging based services and sidelink positioning, Sherry (Yang) Shen, Xiaomi, -, SP-211647
背景
測距(Ranging)とは、デバイスの直接接続により、2つのUE間の距離および/または一方のUE(ターゲットUE)と他方のUE(オブザーバーUE)の方向を決定することを指します。3Dの場合、方向には、水平(Horizontal)方向と仰角(Elevation)方向が含まれます。
レンジングベースサービスは、コンシューマー、スマートホーム、スマートシティ、スマート交通、スマートリテール、インダストリー4.0など、さまざまな分野で利用が期待される。
(ここでは省略しますが、いろいろなユースケースが書いてあって面白いので興味がある方はSIDを御覧ください。)

目的
本SIでは、5Gネットワークのカバー内(in-coverage)、部分カバー(partial coverage)、カバー外(out-of-coverage)における商業、V2X、公共安全のユースケース向けにRanging-based services and sidelink positioningをサポートする5GC拡張を検討する。

  • UEまたはUEグループに対する認可およびポリシー/パラメータのプロビジョニング
  • 2台のUE間、1台のUEと複数のUE間、または他のUEのアシスタントを介したレンジング装置の発見とサービス動作の手順
  • サービスを要求した UE またはアプリケーションサーバーへの測距およびサイドリンク測位サービスの公開。

IoT/TSC/URLLC

アーキテクチャ拡張

自動化と最適化

続きは後編を御覧ください!

https://zenn.dev/nic/articles/2aaf208dd201e9

Discussion