omusubi techblog

This website is my technical memo (Mobile/Wireless)

3GPP TS23.501 5.7 Qos model を読んでいく

この記事は 3GPP TS23.501(V17.6.0)を読んでいく Advent Calendar 2022

の1日目の記事として執筆したものです。
その他の記事はQiitaのアドベントカレンダーページからどうぞ！

Calendar for 3GPP TS23.501(V17.6.0)を読んでいく | Advent Calendar 2022 - Qiita

[2022/12/2追記]
最終日の12/25には応用編として、実際のユースケースにあてはまるとどうなる？
を解説したいと思います。お楽しみに！

 

はじめに

一日目ということで本カレンダーの趣旨を簡単に紹介します。

5Gに関する仕様は3GPPで標準化され、公開されています。

中でも、全体アーキテクチャや手順を記載した下記が有名です。

  • TS23.501 System architecture for the 5G System (5GS) →5Gのアーキテクチャ
  • TS23.502 Procedures for the 5G System (5GS) →5Gにおける各種手順
  • TS38.300 NR and NG-RAN Overall Description →基地局・無線関連の概要

いずれも500ページを超えるような大長編かつ、概ね3ヶ月毎に改版されているため、これらを解説するような記事は、日本語英語問わず、現時点で私が知る限りありません。

#もしご存知でしたら教えてください...!

 

ということで、今回は基本の基本、5Gアーキテクチャの仕様であるTS23.501最新版をみんなで手分けして読み解いていきたいと思います！

サマリ

本記事では、本文を日本語訳しつつ重要な箇所をハイライト・解説していきますが、かなりの分量なので、以下のサマリを読むだけでもOKです。

  • 5GおけるQoS制御の最小粒度単位はQoSフローであり、QFIとよばれる識別子がついている
    • 1つのPDU Sessionの中に複数のQoSフローが存在している
  • QoSフローは大まかに2種類存在する
  • 各QoSフローはQoSプロファイルを持っていて、QoS制御を実施するためのQoSルールやQoSパラメータがそこには書かれている
    • QoSルール: どのパケットをどのQoSフローにマッピングするか、など
      • パケットはパケットフィルタセットを用いて識別する
    • QoSパラメータ:各QoSフローをどうやって優先度付け/分類するか、など
  • DL/ULでそれぞれQoSルールは異なっているが、DLのQoSルールからULのQoSルールを導出して適用する、Reflective QoSが導入された
  • 代表的なQoSパラメータは、「5QI」「ARP」
    • 5QI:想定サービス毎に、パケットロス率・遅延目標等が標準化された指標
      • QoSフロー毎に設定し、QFIと同一の場合もある
    • ARP:QoSフロー間の優先度（輻輳時にリソースを横取りするか、等）
  • 通知制御は、１UEやPDUセッション毎のビットレート制限が可能
    • Session-AMBR:特定のPDUセッションの総ビットレートをUPFで制限する
    • UE-AMBR:各UEのすべてのPDUセッションの総ビットレートをRANで制限する
    • UE-slice-AMBR:各UEの特定のS-NSSAIを持つPDUセッションの総ビットレートをRANで制限する
      • UE-slice-AMBRのみGBR/non-GBRの両方を制限可能

 

5.7 QoS model

5.7.1.1 QoS flow

5G QoS モデルは、QoS フローに基づいています。 5G QoS モデルは、保証されたフロー ビット レートを必要とする GBR QoS フロー と、保証されたフロー ビット レートを必要としないnon-GBR QoS フロー の両方をサポートします。

5G QoS モデルは、Reflective QoS もサポートします (5.7.5 節を参照)。
QoS フローは、PDU セッションにおける QoS 差別化の最も細かい粒度です。

QoS フロー ID (QFI) は、5G システムでQoS フローを識別するために使用されます。 PDU セッション内で同じ QFI を持つユーザープレーントラフィックは、

同じトラフィック転送処理(スケジューリング、許可しきい値など) を受け取ります。 QFI は、N3（および N9）のカプセル化ヘッダーで伝送されます。つまり、E2Eの パケット ヘッダーは変更されません。 QFI は、すべての PDU セッション タイプに使用されます。


QFI は、PDU セッション内で一意でなければなりません。 QFI は動的に割り当てられるか、または 5QI と等しい場合があります (5.7.2.1 節を参照)。
5GS 内では、QoS フローは SMF によって制御され、PDU セッション確立手順 (TS 23.502 [3] の 4.3.2 節を参照)、または PDU セッション変更手順を介して、事前に構成または確立することができます。 

 

5.7.1.2 QoS プロファイル


QoS フローは、その QoS プロファイルに応じて「GBR」または「non- GBR」のいずれかになります。 QoS フローの QoS プロファイルは RANに送信され、以下で説明する QoS パラメータが含まれます (QoS パラメータの詳細は、5.7.2 節で説明します)

 

各 QoS フローについて、QoS プロファイルには QoS パラメータが含まれます。
- 5G QoS 識別子 (5QI)
- 割り当てと保持の優先順位 (ARP)

各non-GBR QoS フローに対してのみ、QoS プロファイルには 下記QoS パラメータも含まれる場合があります。
-  Reflective QoS 属性 (RQA)

各 GBR QoS フローに対してのみ、QoS プロファイルには 下記QoS パラメータも含まれます。
- 保証フロー ビット レート (GFBR)

- 最大フロー ビット レート (MFBR)

GBR QoS フローのみの場合、QoS プロファイルには下記QoS パラメータも含まれる場合があります。
- 通知制御
- 最大パケット損失率※
※このリリースの仕様では、最大パケット損失率は、音声メディアに属する GBR QoS フローに対してのみ提供されます。


各 QoS プロファイルには、QoS プロファイル自体には含まれていない、対応する 1 つの QoS フロー識別子 (QFI) があります。
QoS フローに動的に割り当てられた 5QI を使用するには、さらに QoS プロファイルの一部として完全な 5G QoS 特性 (5.7.3 節で説明) のシグナリングが必要です。
標準化または事前構成された 5QI が QoS フローに使用される場合、5G QoS 特性の一部が QoS プロファイルの一部として通知される場合があります (5.7.3 節で説明)。

5.7.1.2a Alternative QoS Profileは省略

5.7.1.3 QoS フローの制御


QoS フローを制御するために、次のオプションがサポートされています。
1. non-GBR QoS フローの場合、標準化された 5QI または事前設定された 5QI が使用され、5QIがQFI の範囲内 (つまり、64 未満の値) の場合、 5QI値はQFIとして使われる場合があります。

　(a) デフォルトの ARP は、RAN で事前に構成されます。また
　(b) ARP と QFI は、PDU セッションの確立時または PDU セッションの変更時、および 　　PDU セッションのユーザー プレーンがアクティブ化されるたびに、N2を介して 　　RAN に送信されるものとします。

2. 他のすべてのケース (GBR およびnon-GBR QoS フローを含む) では、動的に割り当てられた QFI が使用されます。
5QI 値は、標準化されていて、事前に構成されている、または動的に割り当てられている場合があります。

QoS プロファイルと QoS フローの QFI は、PDU セッションの確立/変更時、および NG-RAN が使用されるときに、PDU セッションのユーザー プレーンがアクティブ化されるたびに、N2 を介して RAN に提供されます。
1.(b) と 2. のみが 3GPP-RAN に適用されます。1.(a)、1.(b)および 2. は、non- 3GPP アクセスに適用される場合があります。

5.7.1.4 QoS ルール


UE は、QoS ルールに基づいて、UL ユーザープレーントラフィックの分類とマーキング、つまり、UL トラフィックの QoS フローへの関連付けを実行します。

これらの QoS ルールは、UE に明示的に提供される場合があります。 (つまり、PDU セッション確立/変更手順を使用して明示的にシグナリングされた QoS ルール)、UE で事前に構成されているか、またはReflective QoS を適用することによって UE によって暗黙的に導出されます (5.7.5 節を参照)。

QoS ルールには、関連する QoS フローのQFI、パケット フィルタ セット (5.7.6 節を参照)、および優先値 (5.7.1.9 節を参照) が含まれます。明示的に通知された
QoS ルールには、PDU セッション内で一意であり、SMF によって生成される QoS ルール識別子が含まれています。
同じ QoS フロー (つまり、同じ QFI) に関連付けられた複数の QoS ルールが存在する場合があります。


デフォルトの QoS ルールは、PDU セッションの確立ごとに UE に送信する必要があり、QoS フローに関連付けられています。 IP タイプの PDU セッションまたはイーサネット タイプの PDU セッションの場合、デフォルトの QoS ルールは、パケットフィルタを含む可能性がある PDU セッションの唯一の QoS ルールです。 すべての UL パケットを許可するように設定します。この場合、最高の優先順位の値が QoS ルールに使用されます。
UE が QoS ルールのパケット フィルタ セットに対して UL パケットを評価する方法は、5.7.1.5 節で説明されています。


デフォルト QoS ルールにパケット フィルタ セットが含まれていないか、すべての UL パケットを許可するパケット フィルタ セットが含まれている限り、デフォルト QoS ルールが関連付けられている QoS フローにReflective QoS を適用してはいけません。


5.7.1.5 QoS フロー マッピング


SMF は、QoS およびサービス要件に基づいて、PCC ルールを QoS フローに紐づけます。 SMF は、新しい QoS フローに QFI を割り当て、QoSプロファイルが紐づきます。

具体的には、対応する UPF への命令および QoS ルールを、QoS フローに紐づけされたPCC ルールおよび PCF によって提供されるその他情報から取得します。


該当する場合、SMF は QoS フローに関する次の情報をRAN に提供します。
- QFI
- QoS プロファイル(5.7.1.2 で説明 )
- (オプション) 代替 QoS プロファイル


QoS フローに紐づけされた各 PCC ルールについて、SMF は次の情報を UPF に提供し、ユーザープレーントラフィックの分類、帯域幅の適用、およびマーキングを有効にします (詳細は 5.8 節で説明されています)。
- SDF テンプレートの DL 部分を含む DL PDR;
- SDF テンプレートの UL 部分を含む UL PDR;

※SDF=Service Data Flow , PDR=Packet Detection Rule

- 対応するパケット マーキング情報 (例: QFIトランスポートレベルマーキング値 (例: 外部 IP ヘッダーの DSCP 値)

 

QoS フローに紐づけされた各 PCC ルールについて、該当する場合、SMF は次の原則に従って明示的にシグナリングされたQoS ルール (5.7.1.4 節を参照) を生成し、追加オペレーションとともに UE に提供します。
- (PDU セッションに対して) 一意の QoS ルール識別子が割り当てられます。
- QoS ルールの QFI は、PCC ルールが紐づけされている QoS フローの QFI に設定されます。
- QoS ルールのパケット フィルタ セットは、UL SDF フィルタと、オプションで PCC ルールの DL SDF フィルタから生成されます
- QoS ルール優先値は、QoS ルールが生成される PCC ルールの優先値に設定されます。
- 動的に割り当てられた QFI の場合、QoS フローに関連付けられた QoS ルールに加えて、QoS フロー レベルの QoS パラメータ (たとえば、5QI、GFBR、MFBR) が UE に通知されます。


ユーザー プレーン トラフィックの分類とマーキング、および QoS フローの RAN リソースへのマッピングを図 5.7.1.5-1 に示します。

QoSフローのRANリソースへのマッピング

DL では、着信データは、DL PDR のパケットフィルタ セットに基づいて UPF によって優先順位に従って分類されます (追加の N4 シグナリングを開始することはありません)。 UPF は、QFI を使用して N3 (および N9) ユーザープレーンマーキングを介して、QoS フローに属するユーザー プレーントラフィックの分類を伝達します。

RAN は、QoS フローを RANリソース (つまり、3GPP RAN の場合のデータ無線ベアラー) に紐づけます。QoS フローと RAN リソースの間に厳密な 1:1 の関係はありません。 QoS フローをマッピングできる必要な RAN リソースを確立し、それらを解放するのは、RAN 次第です。 RAN は、QoS フローがマッピングされている AN リソースが解放された時点を SMF に通知する必要があります。一致する DL PDR が見つからない場合、 UPFはDLデータ パケットを破棄します。

ULでは、
- IP またはイーサネットの PDU セッションの場合、UE は、一致する QoS ルール (つまり、そのパケットフィルターが UL パケットに一致する) が見つかるまで、ULパケットを評価します。
- 一致する QoS ルールが見つからない場合、UE は UL データ パケットを破棄する必要があります。
UE は、対応する一致する QoS ルールの QFI を使用して、UL パケットを QoS フローに紐づけます。次に、UE は QoS フローを RAN リソースに紐づけます。 

5.7.1.6 DL トラフィック


DL トラフィックの処理には、次の特性が適用されます。
- UPF は、PDR に基づいてユーザー プレーン トラフィックを QoS フローに紐づけます。
- UPF は、5.7.1.8 節で指定されているように Session-AMBR enforcementを実行し、課金のためのパケットカウントを実行します。
- UPF は、5GC と RAN の間の単一のトンネルで PDU セッションの PDU を送信します。UPF は、カプセル化ヘッダーに QFI を含めます。さらに、UPF は、カプセル化ヘッダーにReflective QoS 有効化の指示を含めることができます。
- UPF は、QoS フローごとに DL でトランスポート レベルのパケット マーキングを実行します。 UPF は、SMF によって提供されるトランスポート レベルのパケット マーキング値を使用します (5.8.2.7 節で説明)。
- RAN は、QFI および関連する 5G QoS プロファイルに基づいて、QoS フローからの PDU をアクセス網のリソースに紐づけし、DL パケットに関連する N3 トンネルも考慮します。


5.7.1.7 UL トラフィック


UL トラフィックの処理には、次の特性が適用されます。
- UE は、格納された QoS ルールを使用して、UL ユーザープレーントラフィックと QoS フローの間のマッピングを決定します。 UE は、一致するパケット フィルタを含む QoS ルールの QFI で UL PDU をマークし、RAN によって提供されるマッピングに基づいて、QoS フローの対応するアクセス網のリソースを使用して UL PDU を送信します。

- RAN は、UPF に向けて N3 トンネルを介して PDU を送信します。 RAN から CN に UL パケットを渡すとき、RAN は UL PDU のカプセル化ヘッダーに QFI 値を含め、N3 トンネルを選択します。
- RAN は、5QI、プライオリティ レベル (明示的にシグナリングされた場合)、および関連する ARP プライオリティレベルに基づいて決定されるトランスポート レベル パケット マーキング値を使用して、QoS フローごとに UL でトランスポートレベル パケット マーキングを実行します。
- UPF は、UL PDU 内の QFI が UE に提供された QoS ルールと一致しているか、またはReflective QoS の場合はUE によって暗黙的に導出されているかどうかを評価します。
- UPF と UE は、5.7.1.8 節で指定されているように Session-AMBR enforcementを実行し、UPF は課金のためにパケットのカウントを実行します。


5.7.1.8 AMBR/MFBR の実施とレート制限

※AMBR=Aggregated Maximum Bit Rate , MFBR=Maximum Flow Bit Rate

UPF が SMF から Session-AMBR 値を受信した場合、UL および DL Session-AMBRは UPF によって実施されるものとします。

UL Classifier PDU セッションの場合、UL および DL Session-AMBRは、UL Classifier 機能をサポートするSMF において選択されたUPF で実施されるものとします。さらに、DL Session- AMBR は、N6を終端するすべての UPF で個別に実施されます(つまり、UPF 間の相互作用を必要としません) 


マルチホーム PDU セッションの場合、UL および DL Session-AMBR は、分岐点機能をサポートするUPF で実施されるものとします。 さらに、 DL Session-AMBR は、N6を終端するすべての UPF で個別に実施されるものとします (つまり、UPF 間の相互作用を必要とせずに) 
※DL Session-AMBR は、N6 を終端するすべての UPF で実施され、UL Classifier/分岐点機能を実行する UPF によって破棄される可能性のあるトラフィックの不要な転送を減らします。 DL Session-AMBR  UL Classifier/Branching Point で DL パケットを破棄すると、課金をサポートする際に、誤ったカウントが発生する可能性があります。
RANは、non-GBR QoS フローの UE ごとに、UL および DL で UE-AMBRを実施します。


UE は、Session-AMBR を受信した場合、Session-AMBR を使用して、Non-GBR トラフィックの PDU セッション単位でUL レート制限を実行する必要があります。


QoS ルールの優先順位の値と PDR の優先順位の値は、それぞれ QoS ルールまたは PDR が評価される優先度を決定し、優先度が高いものから実行されます。


5.7.1.10 UE-Slice-MBR の実施とレート制限


RAN が AMF から S-NSSAI の UE-Slice-MBR を UE に対して受信した場合、RAN はその UE のすべての PDU セッションにこの UE-Slice-MBR を適用する必要があります。

特に、RAN はこの UE-Slice-MBR を次のように実施します。


1. GBR QoS フローの確立または変更の要求が受信されるたびに、RAN アドミッション コントロールは、許可された GBR QoS フローの GFBR 値の合計が UE-Slice-MBR を超えないことを保証する必要があります。許可できない場合、RAN は QoS フローの確立/変更を拒否するものとします。

2. RAN は、PDU セッションに属するすべての GBR およびnon-GBR QoS フローにわたる集約されたビットレートが UE-Slice-MBR を超えないことを保証するものとします。

5.7.1.11 QoS aspects of home-routed roamingは省略

5.7.2 5G QoS パラメータ

QoSパラメータ表の一部


5.7.2.1 5QI


5QI は、 QoS フローの QoS 転送処理を制御するノードのパラメータに適用されます (例: 重みのスケジューリング、許可しきい値、キュー管理しきい値、リンク層プロトコル設定など)
標準化された 5QI 値は、QoSパラメータ表で指定されているように、5G QoS 特性の標準化された組み合わせに1対1でマッピングされます。

事前設定された 5QI 値の 5G QoS 特性は、RAN で事前設定されます。
標準化または事前構成された 5G QoS 特性は、5QI 値によって示され、変更手順が実施されない限り、どのインタフェースでも通知されません。

 

5QI が動的に割り当てられた QoS フローの 5G QoS 特性は、QoS プロファイルの一部として通知されます。
※N3 では、各 PDU セッション は、カプセル化ヘッダーで運ばれる QFI を介して 1 つの 5QI に関連付けられます。


5.7.2.2 ARP


QoS パラメータ ARP には、優先レベル、プリエンプション機能、およびプリエンプション脆弱性に関する情報が含まれています。これにより、QoS フローの確立/変更/ハンドオーバーを受け入れるか、またはリソースが制限された場合に拒否する必要がある
かを決定できます (通常、GBR トラフィックのアドミッション制御に使用されます)。

また、リソース制限中にどの既存の QoS フローを横取りするか、つまりリソースを解放するためにどの QoS フローを解放するかを決定するためにも使用できます。


ARP優先度は、QoS フローの相対的な重要性を定義します。 ARP プライオリティ レベルの範囲は 1 ～ 15 で、1 が最高プライオリティです。
ARP優先度 1 ～ 8 は、オペレータ ドメイン内で優先処理を受けることが許可されているサービスの QoS フローにのみ割り当てる必要があります。

ARP優先度9 ～15 は、サービスの QoS フローに割り当てられます。

このサービスは、ホーム ネットワークによって承認され、したがって UE がロー
ミングしているときも適用されます。

注: これにより、将来のリリースで ARP 優先度レベル 1 ～ 8 を使用して、下位互換性のある方法でオペレータ ドメイン内の緊急サービスや、その他の優先サービスなどを示すことができるようになります。これは、優先度レベルの互換性のある使用を保証する適切なローミング協定が存在する場合、ローミング状況での ARP 優先度レベル 1 ～ 8 の使用を妨げるものではありません。


ARP プリエンプション機能は、優先度の低い別の QoS フローにすでに割り当てられているリソースを QoS フローが取得できるかどうかを定義します。

ARP プリエンプションの脆弱性は、優先度の高い QoS フローを許可するために、QoS フローが割り当てられたリソースを失う可能性があるかどうかを定義します。

ARP プリエンプション機能と ARP プリエンプションの脆弱性は、「有効」または「無効」に設定する必要があります。
デフォルトの QoS ルールが関連付けられている QoS フローの ARP プリエンプションの脆弱性を適切に設定して、この QoS フローのリリースのリスクを最小限に抑える必要があります。

5.7.2.3 RQA


Reflective QoS 属性 (RQA) は、この QoS フローで伝送される特定のトラフィック (必ずしもすべてではない) がReflective QoS の対象であることを示すオプションのパラメーターです。 RQA が QoS フローに対してシグナリングされた場合にのみ、RAN は、
この QoS フローに対応する RAN リソースの RQI(Reflective QoS Indicator) の転送を有効にします。 RQA は、NG-RAN での UE コンテキストの確立時、および QoS フローの確立/変更時に、N2 を介して NG-RAN にシグナリングされます。


5.7.2.4 通知制御
5.7.2.4.1 一般


QoS パラメータ通知制御は、QoS フローの存続期間中に QoS フローの「GFBR を保証できなくなった (または再び保証できる)」場合に、NG-RAN から通知を要求するかどうかを示します。アプリケーション トラフィックが QoS の変更に適応できる場合 (たとえば、レート適応をトリガーできる場合)、GBR QoS フローに通知制御を使用できます。
SMF は、QoS フローに紐づけされた PCC ルール (PCF から受信) に QoS 通知制御パラメータが設定されている場合にのみ、通知制御を有効にします。通知制御パラメータは、QoS プロファイルの一部として NG-RAN に通知されます。 

 

5.7.2.5 フロー ビット レート


GBR QoS フローの場合のみ、次の追加の QoS パラメータが存在します。
- 保証フロー ビット レート (GFBR) 
- 最大フロー ビット レート (MFBR)
GFBR は、平均時間にわたってネットワークによって QoS フローに提供されることが保証されているビット レートを示します。 MFBR は、ビット レートを QoS フローで期待される最高ビット レートに制限します (たとえば、過剰なトラフィックは、UE、RAN、UPF でのシェーピングまたはポリシング機能によって破棄または遅延される可能性があります)。

GFBR 値を超えて MFBR 値までのビット レートには、QoS フローの優先度レベルによって決定される相対的な優先度が提供される場合があります。
GFBR と MFBR は、QoS プロファイルでRAN に通知され、個々の QoS フローごとに QoS フロー レベル QoS パラメータとして UE に通知されます。
※GFBR は、サービスが存続する最低許容サービスビットレートとして推奨されます。
※ネットワークは、特定の QoS フローの MFBR を、オペレータ ポリシーとアプリケーション/サービス レベルでのレート適応のサポートに基づいて、GFBR よりも大きく設定できます。


5.7.2.6 集約ビットレート


各PDUセッションは、次の集約レート制限QoS パラメータに関連付けられています。
- セッションごとの総最大ビット レート (Session-AMBR)

Session-AMBRは、UPFに通知され、特定の PDU セッションのすべてのnon-GBR QoS フローの総ビット レートを制限します。Session-AMBR は、標準化された値である AMBR 平均ウィンドウで測定されます。 Session-AMBR は、GBR QoS フローには適用されません。


各UEは、次のレート制限QoS パラメータに関連付けられています。
- UE集約最大ビット レート (UE-AMBR) 
UE-AMBR は、UE のすべてのnon-GBR QoS フローで提供されると予想される総ビット レートを制限します。各RAN は、その UE-AMBR を設定する必要があります。

アクティブなユーザープレーンを持つすべてのPDU セッションのSession-AMBR の合計はUE-AMBRに設定されます。 UE-AMBR は、UDM もしくはPCFから取得され、AMF によって RAN に提供されるパラメータです 。 AMF は、PCF によって提供された UE-AMBR をRAN に提供します。 UE-AMBR は、標準化された値である AMBR 平均化ウィンドウで測定されます。 UE-AMBR は GBR QoS フローには適用されません。

 

各UEの、同じスライス (S-NSSAI) に対するの PDU セッションの各グループは、次の集約レート制限 QoS パラメータに関連付けることができます。
- スライス最大ビット レート (UE-Slice-MBR) 


UE-Slice-MBR は、アクティブなユーザー プレーンを持つ同じスライス (S-NSSAI) の UE の PDU セッションに対応する、すべての GBR およびnon-GBR QoS フローの総ビット レートを制限します。 UE-Slice-MBR は、標準化された値である AMBR 平均ウィンド
ウで測定されます。 


5.7.2.7 デフォルト値


PDU セッション設定ごとに、SMF はSession-AMBR 、5QI および ARP のデフォルト値をUDM から取得します。デフォルトの 5QI 値は、標準化された値の範囲からのnon-GBR 5QI でなければなりません。
デフォルトの QoS ルールに関連付けられた QoS フロー以外の PDU セッションの QoS フローの場合、SMF は、ARP 優先度レベル、ARP プリエンプション機能、および ARP プリエンプション脆弱性を、それぞれの値に設定する必要があります。

動的 PCC が展開されていない場合、SMF は DNN ベースの構成を持つことができ、デフォルトの QoS ルールに関連付けられた QoS フローとして GBR QoS フローを確立できます。


5.7.2.8 最大パケット損失率

最大パケット損失率 (UL/DL) は、アップリンクおよびダウンリンク方向で許容できる QoS フローの損失パケットの最大率を示します。これは、GFBR に準拠しているQoS フローに提供されます。
※この仕様のリリースでは、最大パケット損失率 は、音声メディアに属する GBR QoS フローに対してのみ提供できます。

5.7.3 5G QoS 特性


5.7.3.1 一般


この節は、5QI に関連する 5G QoS 特性を指定します。特性は、QoS フローが UE と UPF の間でE2Eで受信するパケット転送処理における、次のパフォーマンス観点を含みます。

 

1.リソースタイプ (non-GBR、GBR、遅延クリティカル GBR)。
2.優先レベル
3.パケット遅延バジェット (コア ネットワーク パケット遅延バジェットを含む)
4.パケットエラー率
5.平均化ウィンドウ( GBR および遅延クリティカル GBR のみ)
6.最大データ バースト ボリューム (遅延クリティカルGBRのみ)


5G QoS 特性は、3GPP 無線アクセスリンク層プロトコルなど、各 QoS フローのノード固有のパラメーターを設定するためのガイドラインとして理解する必要があります。

 

標準化または事前構成された 5G QoS 特性は、5QI 値によって示され、特定の 5G QoS 特性が変更されない限り、どのインタフェースでも通知されません。 
※デフォルト値が指定されていないため、事前設定された 5G QoS 特性には、上記のすべての特性が含まれている必要があります。


5.7.3.2 リソースタイプ


リソース タイプは、QoS フローレベル保証フロー ビット レート (GFBR) 値に関連する専用ネットワーク リソースが 永続的に割り当てられるかどうかを決定します(たとえば、基地局のアドミッション制御機能によって)


GBR QoS フローは通常、動的なポリシーと課金制御を必要とする「オンデマンド」で承認されます。 GBR QoS フローは、GBR リソース タイプまたは遅延クリティカル GBR リソース タイプのいずれかを使用します。 

non-GBR QoS フローは、静的ポリシーと課金制御によって事前に承認される場合があります。non-GBR QoS フローは、non-GBR リソース タイプのみを使用します。

 

5.7.3.3 優先度


5G QoS 特性に関連付けられた優先度レベルは、QoS フロー間でリソースをスケジューリングする際の優先度を示します。
優先度レベルは、同じ UE の QoS フローを区別するために使用され、異なる UE からの QoS フローを区別するためにも使用されます。
輻輳の場合、1 つ以上の QoS フローに対してすべての QoS 要件を満たすことができない場合、優先度レベルを使用して、優先度レベル値 N の QoS フローが優先されるように、どの QoS フローに対して QoS 要件が優先されるかを選択する必要があります。

より高いプライオリティ レベル値を持つ QoS フロー (つまり、N+1、N+2 など)。輻輳がない場合は、優先度レベルを使用して QoS フロー間のリソース配分を定義する必要があります。さらに、スケジューラは、アプリケーションのパフォーマンスとネットワーク容量を最適化するために、他のパラメータ (リソース タイプ、無線状態など) に基づいて QoS フローに優先順位を付けることができます。
すべての標準化された 5QI は、QoS 特性表 5.7.4.1 で指定された優先度レベルのデフォルト値に関連付けられています。
優先度レベルは、標準化された 5QI とともにRAN に通知することもできます。受信した場合は、デフォルト値の代わりに使用されます。

優先度レベルは、事前設定された 5QI と一緒にRAN に通知することもできます。受信した場合は、事前設定された値の代わりに使用されます。


5.7.3.4 パケット遅延バジェット


UPFで UE と N6 の間でパケットが遅延する可能性がある時間の上限を定義します。 PDB(Packet Delay Budget) は、UPF が N6を介して受信する DL パケットと、UE が送信する UL パケットに適用されます。特定の 5QI では、PDB の値は UL と DL で同じです。 3GPP アクセスの場合、PDB は、スケジューリングおよびリンク層機能の構成をサポートするために使用されます (たとえば、スケジューリング優先度の重みと HARQの設定)。


5.7.3.5 パケット エラー率


Packet Error Rate (PER) は、リンク層プロトコル (3GPP アクセスの RAN 内の RLC など) の送信者によって処理されたが、上位層への対応する受信機 (例: 3GPP アクセスの RAN における PDCP)に正常に配信されなかった PDU (IP パケットなど) のレートの上限を定義します。

したがって、PER は、非輻輳関連のパケット損失率の上限を定義します。 PER の
目的は、適切なリンク層プロトコル構成 (たとえば、3GPP アクセスの RAN における RLC および HARQ) を可能にすることです。 5QI ごとに、PER の値は UL と DL で同じです。

 

5.7.3.6 アベレージング ウィンドウ


各 GBR QoS フローは、平均化ウィンドウに関連付けられます。平均化ウィンドウは、GFBR と MFBR が計算される期間を表します。
すべての標準化された 5QI (GBR および遅延クリティカル GBR リソース タイプの) は、平均化ウィンドウのデフォルト値に関連付けられています。平均化ウィンドウは、標準化された 5QI とともにRAN および UPF に通知することもでき、受信した場合は、デフォルト値の代わりに使用されます。

 

5.7.3.7 最大データ バースト ボリューム


遅延が重要なリソース タイプを持つ各 GBR QoS フローは、最大データバースト ボリュームに関連付けられます。
Maximum Data Burst Volume (MDBV)は、PDB の期間内にサービスを提供するために必要な最大量のデータを示します。
すべての標準化された 5QI は、MDBV のデフォルト値に関連付けられていて、受信した場合は、デフォルト値の代わりに使用されます。

 

5.7.5 Reflective QoS


5.7.5.1 一般


Reflective QoS により、UE はSMF が提供する QoS ルールなしで UL ユーザー プレーン トラフィックを QoS フローにマッピングでき、 IP PDU セッションおよびイーサネット PDU セッションに適用されます。これは、受信した DL トラフィックに基づいて UE で UE 派生的な QoS ルールを作成することによって実現されます。

Reflective QoS と non-Reflective QoS を同じ PDU セッション内で同時に適用することが可能です。
Reflective QoS 機能をサポートする UE の場合、UE は、受信した DL トラフィックに基づいてULトラフィック用に UE 派生 QoS ルールを作成する必要があります。 UE は、UE が作成した QoS ルールを使用して、UL トラフィックの QoS フローへのマッピングを決定します。

 

5.7.5.2 UE派生QoSルール


UE 派生 QoS ルールには、次のパラメータが含まれます。
- 1 つの UL パケット フィルタ 
- QFI
- 優先度
DL パケットを受信すると、受信した DL パケットから導出された 1 つの UL パケット フィルタを使用して、PDU セッション内の UE派生 QoS ルールを導出します。

DLパケットに基づいて次のように導出されます。
- プロトコル ID / 次のヘッダーが TCP または UDP に設定されている場合は、送信元と宛先の IP アドレス、送信元と宛先のポート番号、およびプロトコル ID / nextヘッダー フィールドを使用します。

- Protocol ID / Next Header が UDP に設定されている場合、受信した DL パケットが UDP カプセル化されたIPSec保護パケットである場合、送信元および宛先 IP アドレス、送信元および宛先ポート番号など

UE 派生 QoS ルールの QFI は、DL パケットで受信した値に設定されます。

 

5.7.5.3 Reflective QoS 制御


Refelective QoS は、N3 (および N9) のカプセル化ヘッダーの RQI を QFI と一緒に使用し、Reflective QoS タイマー (RQ タイマー) 値と一緒に使用することで、パケット単位で制御されます。 PDU セッション確立時に UE に送信するか、デフォルト値に設定します。コアネットワークによって提供される RQ タイマー値は、PDU セッション単位の粒度です。

UPF が SMF から RQI マーキングを適用するように指示された場合、UPF は、この SDF に対応するすべての DL パケットの N3 (または N9) のカプセル化ヘッダーに RQI を設定する必要があります。RQI が N3の DL パケットでRAN によって受信されると、RAN はその DL パケットの QFI と RQI を UE に通知する必要があります。
RQI 付きの DL パケットを受信すると、次のようになります。
・DL パケットに対応するパケット フィルタを持つ UE 派生 QoS ルールがまだ存在しない場合
　- UE は、DL パケットに対応するパケット フィルタを使用して、新しい UE 派生 QoS ルールを作成する必要があります

- UE は、この UE 派生 QoS ルールのために、RQ タイマー値に設定されたタイマーを開始する必要があります。

・ DL パケットに対応するパケットフィルタを持つ UE 派生 QoS ルールが存在する場合
　- UE は、この UE から導出された QoS ルールに関連付けられたタイマーを再起動する必要があります。
　- DLパケットに関連付けられた QFI が、UE から派生した QoS ルールに関連付けられた QFI と異なる場合、UE は、この UE から派生した QoS ルールを新しい QFI で更新する必要があります。

UE 派生 QoS ルールに関連付けられたタイマーが満了すると、UE は、対応する UE 派生 QoS ルールを削除します。


5.7.6 パケット フィルタ セット


5.7.6.1 一般


パケット フィルタ セットは、QoS ルールと PDR で使用され、1 つまたは複数のパケット (IP またはイーサネット) フローを識別します。

パケット フィルタ セットには、1 つまたは複数のパケット フィルタが含まれる場合があります。すべてのパケット フィルタは、DL 方向、UL 方向、または両方向に適用できます。

PDU セッション タイプに対応して、IP パケット フィルタ セットとイーサネット パケット フィルタ セットの 2 種類のパケット フィルタ セットがあります。


5.7.6.2 IP パケット フィルタ セット


IP PDU セッション タイプの場合、パケット フィルタ セットは、少なくとも以下の任意の組み合わせに基づいてパケットフィルタをサポートする必要があります。
- 送信元/宛先 IP アドレスまたは IPv6 プレフィックス
- 送信元/宛先ポート番号
- IP/Next ヘッダー タイプの上のプロトコルのプロトコル ID。
-  TOS (IPv4) / Traffic class and mask (IPv6) 
- フロー ラベル (IPv6)。
- セキュリティ パラメータ インデックス
- パケット フィルター方向

 

第1級陸上無線技術士（1陸技） 取得に向けたおすすめ戦略

この記事は筆者が第1級陸上無線技術士（1陸技）を過去に取得した際の

取得に向けた戦略を紹介していきます。

はじめに

結論からいうと、下記がおすすめです。

①電気通信主任技術者を取得して、2科目（基礎・無線工学A）免除にする

②下記過去問を中古で2セット（a.新しめの10回分 b. aより古めの10回分）買って繰り返す

一陸技 無線従事者国家試験問題解答集(平成29年7月期~令和3年1月期) | |本 | 通販 | Amazon

③最後に直近の試験問題で効果測定する
（6割取れなければ、②の過去問繰り返しをさらに実施する）

試験問題と解答 | 公益財団法人 日本無線協会

 

参考書が色々とありますが、この試験は過去問の類似問題出題率が非常に高いので、

合格するだけであれば、過去問の出題頻度の高い問題をひたすらパターン的に解けるようになるだけで合格点である6割は取ることができます。

 

以下、①②③について解説していきます。

 

①電気通信主任技術者を取得して、2科目（基礎・無線工学A）免除にする

そんなの無理、と言った意見もあるかもしれませんが、IPAの基本情報技術者レベルの知識があれば、そう難しくないと思われます。

それよりも、無線工学の基礎と無線工学Aの方がよほど範囲が広く、出題傾向も異なるので難しいです。

 

ちなみに、1陸技取得に向けた王道コースとしては、下記がよく言われています。

①1陸特→②工事担任者 総合種→③電気通信主任技術者（伝送交換）→④1陸技

#わたしもこのコースで取得して資格報奨金の恩恵に預かりました

②を取得していると、③電気通信主任技術者の基礎科目が免除になりますが、こちらは1陸技の無線工学の基礎に比べると非常に簡単なので、特に必須ではありません。

③→④のみでも特に難しさは変わらないと思われます。

 

また、電気通信主任技術者・1陸技ともに毎年7月・1月の年2回試験が行われます。

したがって、１陸技の受験を思い立った時期に一番近い試験日にまずは、電気通信主任技術者を受験→合格後に資格者証交付→1陸技受験時に、資格者証番号を用いて科目免除申請　といった流れが通常かと思います。

 

ただし、1陸技の試験については科目合格証というものが発行され（科目合格が3年間有効）、こちらと科目免除資格による合格認定は随時可能となっています。

したがって、同時期に電気通信主任技術者と1陸技を同時受験し、

・1陸技の方は無線工学Bと法規のみを受験し、科目合格を得る

・電気通信主任技術者に合格し、資格者証が届き次第、1陸技の合格証明申請をする

といった形で、同時期に2試験を受験したとしても、科目免除を活用した取得が可能になっています。何が言いたいかというと、頑張りたい人は下記のように科目免除も適用しつつ、最速で1陸技が取得可能です、というお話になります。

取得の流れ（7月→1月は1月→7月と読み替えても一緒です）


②過去問を中古で2セット（a.新しめの10回分 b. aより古めの10回分）を繰り返す

一陸技 無線従事者国家試験問題解答集(平成29年7月期~令和3年1月期) | |本 | 通販 | Amazon

上記シリーズが定番と思います。過去のものはお安く手に入るので、まずは重複しないように20回分の問題と解答・解説を集めます。

届いたら、無線工学Aと無線工学の基礎は要らないので、破り捨ててOKです。

 

下記の受験支援ブログにもあるように、1陸技の出題は概ね過去の類似問題（中には問題・解答も同じものもある）で構成されています。

一陸技 工学B 頻出問題 令和4年7月向け | ﾑｾﾝﾎﾞｰﾔ!!のブログ

 

したがって、まずはa.新しめの10回分を用いて、問題文や解答が類似している問題をチェックしていきます（記号やアルファベットを振る等していくと良いかと思います）

2回以上登場している問題については、今後も出題可能性が高いので重点的に繰り返します。逆に1回しか出てこない問題は、受験前日に軽く見る程度で問題ありません。

 

このように、出題頻度の高い問題を重点的に繰り返し、ある程度できるようになったら、次はb. aより古い10回分の方で同じく、問題文や解答が類似している問題をチェックしていきます。これにより、20回分の出題頻度表が完成しているかと思います。

あとは、出題頻度が高い順に繰り返し読み込んで、反射的に解答ができるようにしていきます。（出題回数が1～2回の確認は優先度低で良いと思います）

 

③直近の試験問題で効果測定する

その後、過去問集には載っていない直近の問題を使って効果測定をしていきます。

基本的には、②で調べた出題頻度３回以上の問題に対して解答ができれば、概ね8割程度の得点を容易に取得できるようになっているはずです。

 

おわりに

1陸技の試験は、教科書で一から学んでいると非常に幅広い範囲を深く学ぶ必要があり、一朝一夕にはいきません。ただし、資格取得といった点に絞れば、2科目免除により試験範囲を大幅に狭められるのと、概ね過去の頻出問題で構成されているので、

パターン的に解答できるようになれば、容易に取得が可能と考えられます。ぜひ、挑戦してみてください。

 

 

TR38.821 Solutions for NR to support NTNを読む (8.1章～8.2章)

 

この記事は、TR38.821 Solutions for NR to support NTNの「8.1 Tracking area management」及び「8.2 Registration Update and Paging Handling」を読んだ際のメモです。主に、TA(TrackingArea)とRA(RegistrationArea)のNTNにおける考え方が検討されています。

 

本章で登場する各シナリオは下記の6つである。

検討シナリオ

8.1 Tracking area management

Registration、TrackingAreaのコンセプトは、地上ネットワークに関連するものであり、以下の点でNRのセルラーシステムと同様である。


● トラッキングエリア(TA)は、一定の地理的な範囲に対応する。
● TAは、UEアクセス制御、位置登録、ページング、モビリティ管理などに利用され
る。
● RegistrationArea(RA)は、1つまたは複数のTAを包含する。目的は、ページングに使用する無線リソースを最小化するために、UEを追跡することである。

8.1.1 NTN cells are fixed w.r.t the ground（地面に対してNTNセル固定）

シナリオ A、B、C1、D1 では、NTN セルは地表に固定されている。

従って、TAは1つまたは複数のNTNセルに対応することができる。3GPPで定義されたTA管理とページング手順がそのまま適用される。C1およびD1の場合、LEO衛星は一時的に地上に固定されたフットプリントを持つビームを生成する。言い換えれば、ビームフットプリントは、ある時間、地上の所定のNTNセル上に固定され、その後、別のNTNセ
ル上にフォーカスエリアを変更し、各NTNセルをTAに割り当てることが可能である。

この場合衛星は、2つの連続したNTNセルがカバーされる間に報知されるTACを変更する必要がある。


注1：シナリオCの場合、TAリストおよびページングメッセージは、同じgNBによって、このNTNセルをカバーするすべての衛星を介してNTNセルに送信される可能性がある

注2：シナリオD1の場合、TAリストとページングメッセージは、このNTNセルをカバーするすべての衛星に搭載されたgNBによって送信される可能性がある

 

8.1.2 NTN cells are moving w.r.t the ground（地面に対してNTNセルが移動）

シナリオC2とD2では、衛星が軌道面上を移動するのに合わせてNTNセルも地上を移動する。このため、TA管理およびページング手順にいくつかの適応が必要である。


IDLE/INACTIVE モビリティのシナリオC2、D2に着目すると、TAが常に関連するセルと一意に組み合わさっている限り、移動するTAであっても、従来のコアネットワーク手
順（例えば、ページング）を適用することが可能である。

しかし、そのような場合、TAを固定及び非NTNと区別することが有益である。

これはNTN移動セルに関連するTAのための識別子範囲を、予め確保することによって行うことができる。しかし、これは可能なTAアドレス空間を制限するかもしれず、オペレータの観点からは好ましくないかもしれない。

別の代替案としては、NGAPおよびXnAP上でシグナリングされたTAC IEを、例えばENUMERATED（NTN、NTN with moving cells、...）として定義されたTAタイプIEで拡張し、受信ノードがこのTAに関連するセルがNTNに関連しており、地面に対して静止していないことを識別できるようにすることが考えられる。あるいは、セルレベルまたはgNBレベルであってもよい。

 

地上波と非地上波のネットワークには、同じまたは異なる PLMN を割り当てることができる。


● 地上系と非地上系が 異なる PLMN の場合、両方のTAのレイアウトを独立して定義し、あるレイアウトのTA間での重複を防ぐことが可能である。これは、現在の TA の定義と一致する。

● 共有 PLMN の場合、オペレータはTAを定義し、地上ネットワークが使用するTAI と非 地上ネットワークが使用する TAI を割り当てる。これらのTA間のオーバーラップは可能である。

主なアイデアは、TA管理をNTNセルパターンから切り離すことである。その場合、RAおよびTAは、オペレータによって定義された任意の地理的領域となる。
また、すべてのUEが測位可能なわけではないことを想定している。

 

以下は、シナリオ C2 および D2 に適用される。 

8.1.2.1 Tracking Area defined on satellite

このオプションでは、NTNセルはPLMN IDごとに1つのTAIのみを持ち、地上セルと同じである。これはまた、gNBが現行のNGAPのinitial UEメッセージにサービングセルの1つのTAIを含まれていることが利用可能である、


シナリオC2およびD2では、LEO衛星が移動すると、TAIのカバー範囲も変化する。静止しているUEは、TAIが変化し続けるのを観測する。これに関するいくつかの解決策は8.3章Mobilityで検討する。

8.1.2.2 Tracking Area defined on earth

このオプションでは、TAIが特定の地理的地域に関連するという原則は維持されるが、NTNセルはPLMNごとに複数のTAIをブロードキャストしなければならない場合があり、セルがPLMN IDごとに1つのTAIのみを持つという原則と一致しない場合がある。
NTNセルが複数のTAをカバーする場合、NTNセルは関連する全てのTAIをブロードキャストする。
UEの観点では、UEは報知されたTAIによってTAを認識する。UEによって観測されるTAは常に変化するため、以下の点をさらに考慮する必要がある。


●NGインタフェースでCNに提供されるのはどのTAIか？
InitialUEメッセージの手順中に、UE の位置、すなわち TAI+CGI が CN に提供される。NTNセルが複数のTAIをブロードキャストする場合、1つのオプションは、AMFにすべて
のTAIを提供することである。AMFは、UEに有効なRAを提供することが困難な場合がある。

もう1つのオプションは、AMFに1つのTAIのみを提供することである。NTNセルが複数のTAIをブロードキャストした場合、gNBは、AMFに提供するTAIを決定する必要がある。


●地域/国のポリシーを実施するには？
Registration手順の間（またはその前）に UE の位置が特定できる場合、NG-RAN ノードはregistration中に UE の位置をネットワークに提供し、地域/国別ポリシーが適用される。そうでない場合は、UE がCONNECTEDモードに入るとすぐに、ネットワークが UE の位置を特定できるようになり、地域 / 国別ポリシーが適用される。

8.2 Registration Update and Paging Handling

非地上系かつ非GEOネットワークでは、衛星は対象地域を移動し、そのアンテナビームは対象地域のさまざまな部分をカバーする。
地球上を移動するフットプリントを持つNTNビームでは、非GEO NTNビームとTAIとの固定的な関連付けは、地上で移動するTAIにつながる。地上系ネットワークでは、UEを追跡するための地理的な領域は、TAとも呼ばれ、RANからブロードキャストされるTAIに関連付けられる。

地上系ネットワークと同様に、移動するNTNビームと地球上のジオエリアとの間に一対一の対応ははない。
すなわち、非GEO衛星によって報知されるTAIは地球上を掃引します。静止しているUEは、時間経過とともに異なるNTNビーム/TAIを見ることになる。現在のRegistrationUpdate手順では、静止するUEはNTNビームが変わるとRegistrationUpdateを実行し続けなければならない。これは、現在のRegistrationUpdateとページングに課題をもたらす。

以下では、UEが自分の位置を決定できるかどうかに基づいて、可能な解決策を検討する。

8.2.1 Option 1: UE is capable to determine its location 

以下では、UEがGNSSなどによってその位置を決定する能力を有していることを前提としている。この場合、衛星はUEの位置情報に基づいてUEをページングすることができる。
地上系ネットワークでは、AMFはUEが位置するTAをマッピングして、UEをページングするgNBのリストを決定する役割を担う。NTNでは、UEの位置を使用して同等のマッピングを行い、UEをページングするgNBのリストを決定することができる。
マッピングは、AMFで行うことができ、AMFは、UEタイプやUE速度情報などのいくつかのアシスト情報とともに、UEの位置を認識する。AMFは、衛星エフェメリスも認識する必要がある。あるいは、このマッピングはRAN内で行うこともできる。

UEにページングする必要がある場合、AMFは、通常通りTAIからページングメッセージを送信するRANアクセスノードを決定する。NTNベースのNG-RANは、UEの最後の位置情報と衛星のエフェメリスから、ページングをブロードキャストする衛星ビームを選択することができる。

しかし、これはRANとCN間のページング失敗時やとUEがIDLE時のコンテクスト管理などいくつかの検討しなければならない課題を有する。

 

8.2.1.1 Mapping of UE location to gNB list in the AMF

UEロケーションベースのページング手順例は、以下の図の通りである。

UEロケーションベースのpaging例

● ステップ1：
UEはgNB1に位置情報を通知する。この報告には、UEのタイプ、速度情報などのアシスタンス情報も含まれることがあるが、詳細はさらに検討する必要がある。
● ステップ2：

UEロケーション・レポートを受信すると、gNB1はロケーション情報およびアシスタンス情報（必要な場合）をAMFに転送する
● ステップ 3:

AMF は UE の位置情報、アシスタンス情報および対応するタイムスタンプを保存する。この情報は、UE がIDLE状態になったときに AMF に保存される。
● ステップ 4: 
AMFがUEをページングする場合、保存されている情報とエフェメリスに基づいて、UEの位置をカバーできるgNBを選択する。
● ステップ5：

AMFは、位置情報およびアシスタンス情報を含むPagingメッセージを、選択されたgNBに送信する。gNBは、Pagingメッセージを受信すると、ページングする衛星またはビームを決定し、それに応じてUEをページングする。

 

注：ロケーションベースのページングが失敗した場合、AMFはページングエリアを拡張し、ページングポリシーに従ってUEへ再送信することができる

（例：UEの登録エリア全体でページングを再送信する）

8.2.2 Option 2: UE is not capable to determine its location

以下では、UEがその位置を決定する能力を持たないことを想定する。

8.2.2.1 Solution 1: Timing window based Registration update and paging

この解決策では、地上の識別子が移動することを前提としている。

衛星は RA に基づいて UE をページング可能である。
このオプションでは、TAはジオエリアに関連する有効時間のタイミング情報と関連付けられている。

例えば、あるジオエリアに対して、NTNビーム#1とTAC#1が10:01～10:10の間、NTNビーム#2とTAC#2が10:11～10:20の間、サービスを提供することになる。

UE Registration手順の例

● ステップ 1:

10:05 に、UE は登録手順を開始。REGISTRATION REQUESTメッセージがAMFに送信される。通常のinitial accessと同様に、CU は TAC#1 を現在の NGAP 手順で AMF に提供する。
● ステップ 2:

AMF は REGISTRATION ACCEPT メッセージで返信する。AMF は、UE のロケーションが 10:01 ～ 10:10 の間は TAC#1、10:11 ～ 10:20 の間は TAC#2 によってカバーされる、と判断する。この決定は、以下に基づいて行われる。

- 衛星のエフェメリス情報、つまりどのNTNビームが特定の場所をカバーしているかという情報
- UE の現在または最後の 3GPP アクセスの TAC/NTN ビーム ID に基づく UE の位置情報。UE は、NAS REGISTRATION REQUEST メッセージまたはその他の NAS メッセージに位置情報を含めることができる。

判定は、データベースへの問い合わせにより行うことができる。
REGISTRATION ACCEPTメッセージには、タイミング情報（この例では、AMFはUEが10分後にRegistrationUpdateを開始することを希望している）とTAIのリストで構成される拡張登録エリア情報が含まれている。
+ TAC#1 with (10:05 - 10:10)
+ TAC#2 with (10:11 - 10:15)
その後、UE は RRC_IDLE に入る。

 

ケース0：10:05～10:11にUEが移動しなかった場合
● 10:11、NTNビーム#1がUEのエリアから外れる。UEのエリアは、NTNビーム#2がTAC#2を用いてカバーするようになった。UEは、サービングセルのTACがTAC#2に変更されたことを検出。UE は TAC#2 をステップ 2 で受信した拡張RAと照合する。

TAC#2 はAMF が REGISTRATION ACCEPT メッセージ（ステップ 2）で割り当てた RA内にあり、タイミング情報も一致しているため（つまり、TAC#2 は 10:11-10:15 のみ）、UE はまだRA 内にある。したがって Registration Update を実行する必要はないことを意味する

ケース1：10時12分に、UEがページングされる。
● ステップ 3：10:12 に、UE の DL データを受信する。AMFは、UEの最後の位置（すなわち、10時05分のTAC#1）と、このエリアのTA情報（すなわち、10時01分から10時10分のTAC#1、および10時11分から10時20分のTAC#2）に基づいて、ターゲットTAを決定する。この例では、AMFはUEの最後の位置を知っており、10時11分から10時20分の間、TAC#2でNTN beam#2によってサービスを受けることになる。AMFはTAC#2付きのPagingメッセージをNG-RANに送信し、通常のサービスリクエストの手順が実行される。


ケース2：10時13分、UEがRA外に移動した場合
● ステップ 4（図 8.2.2-1 参照）：10:13 に、UE は現在の NTN ビーム放送 TAC#1 
を検出する。TAC#1 は AMF が REGISTRATION ACCEPT メッセージ（ステップ
2）で割り当てたRA内にあるが、タイミング情報が一致しない（つまり、TAC#1 は 10:01 ～ 10:10 のみで 10:13 はない）ため、これは UE が現在のRAから移動していることを意味する。そのため、UE は Registration Update 手続きを開始する。

このオプションの利点は、下記である。
● 現在のRegistrationUpdateトリガー、すなわちTS23.501の"サービングセルの現在のTAIがUEがネットワークから受け取ったTAIのリストにない場合はMobilityRegistrationUpdate手順を実施する"を再利用可能
● NTNビームが常に同じTACをブロードキャストする、現在のTACブロードキャスト機構を再利用する。
● RANとCNへの変更が少ない。

 

8.2.2.2 Solution 2: UE assisted TA list report/registration and paging

この解決策は、地上の静止した識別子を想定していえう。衛星は、RAすなわちTAIリストに基づいてUEをページングする。
このオプションでは、TAIは地上の固定されたTA計画エリアに基づいて、NTNセルのSIBでブロードキャストされる。

ステップ1：地表に固定されたTAマップをセットアップする。
ステップ2：衛星の位置に応じてブロードキャストTAIを動的に更新する。
ステップ 3: UE は、RegistrationUpdateのために受信したブロードキャスト TAI のリストをモニタし、通知する。
ステップ4：RegistrationUpdate中に、AMFはUEにTAIリストを提供し、これはページングに使用されるUE固有のRAを定義する。
ステップ5：UEは、観測された最良のセルTAIリストを記録する。
ステップ6：UEは、AMFから割り当てられたTAIリストとステップ5からの観測TAIを比較し、まだRA内かどうかを判断する
ステップ7：UEがRAを離れたと判断した場合、UEはRegistrationUpdateを開始し、観測されたTAIリストをAMFに報告し、AMFが新しいUE固有のTAIリストを割り当てることができる。

 

8.2.2.3 Solution 3: Multi-Tracking Area ID based Registration update and paging

衛星は、単一のTAIをブロードキャストする代わりに、TAを衛星ビームカバレッジエリアのサブセットとすることを可能にするために、カバーされたTAのTAIリストをブロードキャストすることができる。そして、衛星は、そのビームカバレッジエリアに関して、TAIのリストを採用することができる。

透過型衛星の場合、地上のgNBは、使用されるべきTAIのリストを予め設定することができる。

再生衛星の場合、衛星上のネットワークノードは、例えば、8.3.2.1で説明したのと同様の方法で、各TAIリストのエントリに対して有効な時間枠を使用することによって、使用するTAIのリストを事前に設定することができる。
この方法の利点は、地上の非重複領域としてのTAの定義が有効であり、現在のページング機構を再利用できることである。


下図 にTAに相当する国での例を示す。4つのTAが定義されている。

TA1: ドイツ

TA2: オーストリア

TA3: スイス

TA4 リヒテンシュタイン

（国ごとに複数の TA を定義することも可能であることに注意）。

赤、緑、青の3つの衛星が、赤ビーム、緑ビーム、青ビームで示されたエリアの一部をカバーしている。上図では、赤の衛星はビームフットプリントがTA2、TA3、TA4をカバーしているため、TAI2、TAI3、TAI4の3つのTAIをブロードキャストしていることになる。
同様に、緑の衛星はTAI1とTAI3を、青の衛星はTAI1、TAI2、TAI3、TAI4をブロードキャストしている。図の下部は、同じTAでも、衛星とそれぞれのカバーエリアが移動したものである。

したがって、赤と緑の衛星がブロードキャストするTAIのリストは変わったが、青の衛星は同じままである。
この例では、オーストリアに位置するUE（TAI2）は、図の上部では、青と赤の両方の衛星ビーム内でページングされることになる。図の下部では、青と緑の両方の衛星ビーム内でページングされる。

国土をTA単位とする例
8.2.2.4 Solution 4: UE location determined by NTN based NG-RAN

衛星ビームのアースフットプリントは、衛星高度と仰角に依存するが、通常の地上セルサイズと比較するとかなり大きくなる可能性がある。したがって、TAサイズとRegistrationUpdateのトレードオフは、地上系ネットワークと比較してNTNでは異なる。

UEがInitialRegistration、RegistrationUpdate、またはCONNCTEDモードに切り替わったとき、NTNベースのNG-RANは、例えば、ビーム識別子からUEロケーション情報を取得する。IDLEモードの UEを追跡するには、RAの定期的な更新で十分であり、RA の更新周期は UE のタイプまたは観測されたモビリティ動作に従って調整される。
さらに、RAN は UE の位置を特定するための他の手段を持つことができる。
したがって、UEが自分で位置を決定する能力がない場合でも、RANがUEの位置に関する情報を有すると仮定することができる。そして、UEロケーションに基づくページング方法を適用することができる。

TR38.832 Study on enhancement of RAN slicing を読む [後編]

この記事は

TR38.832 Study on enhancement of RAN slicing を読む [前編] - omusubi techblog

に続く後編として、TR38.832の6章 Study necessity and mechanisms to support service continuityを読んでいきます。こちらは、Rel17で仕様化されておらず、
Rel18ではWI/SI項目にもなっていません。

（CMCC,ZTEらが提案するも扱われておらず）

 

かなり分量が多いので、要約をお伝えすると下記となります。

気になる方は原文や以降をお読みください。

  • 基地局間を移動して、HOする際にもスライスに基づくサービス品質を継続させたい
  • このSIでは、HO時の課題として、「①HO先の基地局にスライスに基づくリソースが不足している場合」「②HO先の基地局が、HO前に用いていたスライスをサポートしていない場合」の2つを大枠として考える
  • ①については、複数の周波数で同じスライスをサポートし、カバレッジを重ねて、DC等を活用することで不足に陥らないようにするなどの解決策が考えられる
  • ②については、HO先の基地局がサポートするスライスへ、HO前に使用していたスライスを再マッピングするといった解決策が考えられる
  • ちなみに、HOを考慮しない、スライスに基づくRANのリソース分割は、6.2.3.2 Slice resource re-partitioning で少し触れられています。コアやUEへ影響ないし、RANの実装で好きにやれば？とも読み取れます。

 

6 Study necessity and mechanisms to support service continuity 

6.1 Scenario and issue description 

サービス継続性について、下記の2つのシナリオを考える。

 

シナリオ1:RA内モビリティとRA間モビリティの場合のスライスリソース不足

リソース不足が起こる場合

進行中のUEのスライスは、ソースおよびターゲットの NG-RAN ノード
の両方によってサポートされている。ハンドオーバー時に、ターゲット・ノードが、例
えばターゲット・ノードにおけるスライスが高負荷といった理由により、S-NSSAI の少なくとも 1 つを持つ UE を受け入れることができない場合、ターゲット・ノードは、UE を受け入れられない。
このような状況では、障害が発生した進行中のUEのスライスにおけるサービスは、中断される。


他のスライスが使用するリソースプールへのトラフィックの再マッピングは、予め設定されたポリシーを必要とすることに注意が必要であり、再マッピングは、ターゲットスライスのリソースプールに過負荷をかけることを避けるべきである。
※ハンドオーバー先でもスライスをサポートしてるものの、高負荷のために同じスライスを使えない場合にどうするか（他のスライスへ置き換えるかなど）。割りとありそう。

 

シナリオ2:RA間モビリティにおいて、スライス未サポートの場合

HO先が所望のスライスを未サポートだったら

上図で、UEは進行中のスライスの少なくとも 1 つをサポートしないエリアに向かって移動している。ターゲット・ノードは、進行中の S-NSSAI の少なくとも 1 つを持つ UE 
の受け入れに失敗している。このような状況では、失敗した進行中のUEのスライスサービスは中断されることになる。


このシナリオは、元のスライスが特定の地理的領域（TA／RA）において利用可能であることが要求され、元のスライス上で使用されるサービスが移動しても継続性を有することが要求される、特定のSLAが存在する場合にのみ有効である。また、同じスライスの新しいPDUセッションが移動先で開始されないこと、すなわち、SLAがCONNECTEDのモビリティにのみ適用されることが想定されている。

※移動先の基地局が、移動元のスライスをサポートしていない場合。これも割りとありそう。特に車の移動中とか？

 

シナリオ3：RA内モビリティとRA間モビリティでスライスリソースが不足した場合の切り戻し

移動先がリソース不足なのでやっぱりもとの基地局に戻る

これは、シナリオ 1 の継続シナリオである。上図に示すように、UE の進行中のスライスはソースとターゲットの NG-RAN ノードの両方でサポートされる。ハンドオーバー時、ソースノードでは、スライスに関連する負荷が高いことなどが原因で、パフォーマンスが低下した状態となるか、またはすでに S-NSSAI を拒否することがある。

※移動先のリソースが不足してるので、スライスのSLAが保てない、もしくはハンドオーバーを拒否してしまう場合

 

シナリオ4：RA間モビリティでの、スライス非対応時に対応セルへ戻る場合

スライス非対応時に対応セルへ戻る場合

これは、シナリオ 2 の継続シナリオである。上図に示すように、ハンドオーバー時、ソース・ノードはターゲット・ノードがサポートしていない S-NSSAI の場合がある。

 

シナリオ5：MR-DCのスライスリソース不足

MR-DC時のリソース不足

上図に示すように、UE の進行中のスライスは、MN および SNの両方によってサポートされている／されている。しかし、SNの追加または変更手順の場合、SNにおけ
るスライス関連の負荷が高いことなどが原因で、SNのスライスへのリソースが不足している場合、サービス提供は中断してしまう。

※DCのように複数周波数を用いる場合、ひとつでもスライスのリソース不足だと、うまくいかないかも

 

シナリオ6：モビリティがない場合のRANノードのスライス過負荷 

シナリオ1のように、スライス1に対してリソース不足が発生する可能性がある。この場合、このスライス1に関連するいくつかの進行中のPDUセッションは、モビリティがない場合であっても、サービスが劣化する可能性がある。
また、スライス1においてリソース不足を回避するための行動をとった後、UEがまだセル内にいる間にリソース不足が解消されることもあり得る。

※単にトラフィックが増えて、スライスの帯域を確保できなくなった場合？

 

6.2 Solutions

6.2.1 Re-mapping decision in NG-RAN node

ターゲットードがハンドオーバーを受けいれる際に、再マッピングを実施する解決策では、ターゲッノードは、関係するPDUセッションの再マッピングポリシーを認識する必要があり、以下のオプションが利用可能である。

6.2.1.1.1 Slice Re-mapping policy configured by OAM

ターゲットNG-RANノードでの設定

このオプションでは、再マッピングのポリシーの粒度はスライスごと、すなわちサポートされる各 S-NSSAI に対して、ターゲット NG-RAN ノードは以下のように再マッピング可能な S-NSSAI のリストを構成する。
- S-NSSAI 1 <> 再マッピングリスト（S-NSSAI 10, S-NSSAI 11）。
- S-NSSAI 2 <> 再マッピングリスト（S-NSSAI 12, S-NSSAI 13）。 

※対象のS-NSSAIがリソース不足やサポートしていない場合、他のS-NSSAIと読み替えて処理しましょうといった感じ。リストはOAMで事前に設定。

6.2.1.1.2 Slice Re-mapping policy configured by CN (during NG setup)

NGSetup responseにおけるシグナリング
NG-RANノードは、CNからNG Setup Responseメッセージ（またはAMF configuration 
Updateメッセージに）において再マッピングポリシーを事前に受信している。
このオプションでは、リマップポリシーの粒度はスライスである。すなわち、ターゲットノードがサポートする各S-NSSAIについて、CNはNGSetupResponseメッセージに、再マッピング可能なS-NSSAI（複数）のリストを含める。

※NGSetup手順時に再マッピングリストを受信しておくパターン

 

6.2.1.1.3 Slice Re-mapping policy configured by CN (during PDU session setup)

NG(N2)ハンドオーバー時におけるシグナリング
CN は NG ハンドオーバー要求メッセージに現在の PDU セッション、関連する S-NSSAI 及びこの PDU セッションを再マッピングすることができる S-NSSAI のリストを含める。
このオプションでは、再マッピングポリシーの粒度は次のいずれかとなる。
- PDU セッションごと。
- UEごと

※UE,PDUSession,S-NSSAI毎に再マッピングリストを定義する

 

ソースノードおけるシグナリング

PDUセッションがソースNG-RANノードで作成されるとき、CNは、NGAP 
PDUSesionn Resource Setup Request messageに、PDUセッションに関連付けられたS-NSSAIと、このPDUセッションを再マッピング可能なS-NSSAI（複数）のリストとを含める。
その後の Xn ハンドオーバー時に、ソース NG-RAN ノードは Xn ハンドオーバー要求メッセージに現在のPDU セッション、関連する S-NSSAI 及びこの PDU セッションをマッピングすることができる S-NSSAIのリストを含める。
このオプションでは、再マッピングポリシーの粒度は次のいずれかになる。
- PDUセッションごと
- UEごと

※PDUセッション要求時に、再マッピング可能なリストを渡してHO時に使う

 

6.2.1.2 Slice Re-mapping Message Sequence Charts

6.2.1.2.1.1 Slice Remapping decision in target gNB at Xn based handover

Xnハンドオーバー時の再マッピングのシーケンス

1. S-gNBは、T-gNBにHANDOVER REQUESTメッセージを送信する。

2. UEの進行中のスライスがターゲットgNBで拒否された場合、再マッピングポリシーに基づき、T-gNBはスライス再マッピング／フォールバック判定を行う。T-gNBは、HANDOVER REQUEST ACKNOWLEDGEメッセージでスライスの再マッピング／フォールバック決定をS-gNBに送信することができる。

3. T-gNBは、PATH SWITCH REQUESTを通じて、スライスの再マッピング／フォールバック決定をAMFに送信する。

4.AMF は PATH SWITCH REQUEST ACKNOWLEDGE メッセージを応答する。AMF は、PDU セッションリソース解放リスト IE で、PDU セッションを拒否することができる。

 

6.2.1.2.1.2 Slice Remapping decision in target gNB at NG based handover

NG(N2)ハンドオーパー時のターゲットgNBでの再マッピングシーケンス

1. S-gNBは、HANDOVER REQUIREDメッセージをAMFに送信する。
2. AMFは、HANDOVER REQUESTメッセージをT-gNBに送信する。
3. UE の進行中のスライスがターゲット gNB で拒否された場合、再マッピング・ポリシーに基づいて、T-gNB は AMF への HANDOVER REQUEST ACKNOWLEDGE 
メッセージに再マッピング/フォールバック決定を含める。

4. AMFは、HANDOVER COMMANDを通じて、スライスの再マッピング／フォールバック決定をS-gNBに送信する。

 

6.2.1.2.1.3 Slice Remapping decision in 5GC and target gNB at NG based handover

NG(N2)ハンドオーパー時のAMFとターゲットgNBでの再マッピングシーケンス


1. S-gNBは、HANDOVER REQUIREDメッセージをAMFに送信する。
2. UE の進行中のスライスが T-gNB でサポートされていない場合、AMF 
は最初のスライスの再マッピング／フォールバックの決定を行い、その決定を T-gNB へのHANDOVER REQUEST メッセージに含める。
3. UE の進行中または再マッピング/フォールバックスライスがターゲット gNB で拒否された場合、再マッピングポリシーに基づいて、T-gNB は AMF への HANDOVER REQUEST ACKNOWLEDGE メッセージにさらなる再マッピング／フォールバック決定を含める。

4.AMFは、HANDOVER COMMANDメッセージを通じて、スライスの再マッピング／フォールバック決定をS-gNBに送信することができる。 

 

6.2.1.2.1.4 5GC Solution based on SSC-mode 3

以下のコールフローでは、サービス継続実現方法として5GCのSSCモード3が使用されている。

SSC-mode 3ベースの再マッピング

ステップ0：NG-RANノードに、スライス10→11の再マッピングを設定


ステップ1：5GCは、既存の手順に従って、サービングNG-RANノードとUEに

UE Allowed NSSAIを送信する。

 

ステップ2：UEは、スライス10のPDUセッション1を継続している

 

ステップ3：ソースNG-RANはターゲットNG-RANへのハンドオーバーを要求する。

ターゲットNG-RANノードは、HO手順中に、スライス再マッピング動作のためにスライス10のPDUセッション1を一時的に受け入れることをソースNG-RANノードに通知する。


ステップ4：ハンドオーバー完了時に、ターゲットNG-RANは、スライス10のPDUセッション1を終了させる必要があり、スライス11と新しいPDUセッションを設定することをパス切り替え要求で5GCに指示する。


ステップ5：UEは、ハンドオーバー後の登録を実行する（ソースおよびターゲットNG 
RANノードは異なるスライスサポートを有するため、UEにとって同じRAに属さない）。ステップ4で5GCがスライス10を受信したため、5GCはこのステップでUEに向けたAllowed NSSAIにスライス10を含む（スライスは、ステップ9としてスライス10のPDUセッション1の最終解放の通知を5GCから受信するまで実際には、一時的にまだ利用可能である）


ステップ6：ステップ4に対して、5GCは、SSCモード3を起動するために、UEに向けてNAS PDU Session modification commandを実施する。UEのURSPがスライス10をより高い優先度として示す場合でも、スライス11との新しいPDUセッション2をセットアップするようUEに促すために、（end slice 10, new 11）がUEに向けて含まれる。

ステップ 7：UE は、TS 23.502 [3]の 4.3.2.2.1 項に記載されている既存の手順に従い、SSC モード 3 手順でスライス 11 との PDU セッション 2 のセットアップをトリガします。

ステップ8：SSCモード3タイマーの満了時に、5GCは、SSCモード3手順に従ってスライス10のPDUセッション1の解放を実施する。5GCは、NG-RANおよびUEに向けてAllowed NSSAIを更新するために、UCU（UE Configuration Update）メッセージを最終的に送信する。この例では、新しいAllowed NSSAIはスライス11である。

 

6.2.1.2.2 Slice Remapping for non-mobility case
6.2.1.2.2.1 Slice Remapping decision in SN for MR-DC case

MR-DCでの再マッピング（SNでの決定）

このフローチャートは、リソース不足のシナリオにのみ適用される。

1. MNは、SN Addition RequestをSNに送信する。

2. UE の進行中のスライスが SN によって拒否された場合、スライスの再マッピングポリシーに基づいて、SN はスライスの再マッピング/フォールバックの決定を行う。

SN は、MN に対する SN Addition Request Acknowledge メッセージに、スライスの再マッピング／フォールバックの決定を含めるものとする。

3. MNは、PDU Session Modification Indicationメッセージを通じて、スライスの再マッピング／フォールバック決定をAMFに送ることができる。

4. AMFは、PDUセッション変更確認メッセージを応答する。

 

6.2.1.2.2.2 Slice Remapping decision in MN for MR-DC case

MR-DCでの再マッピング（MNでの決定）

1. MNはスライスの再マッピング／フォールバックの決定を行い、SN Addition Requestにその決定を含め、SNに送信する。

2. SNは、SN Addition Request Acknowledgeメッセージにおいて、MNが行ったスライス再マッピング/フォールバックの決定を確認する。

3. MNは、PDU Session Modification Indicationメッセージを通じて、スライスの再マッピング／フォールバック決定をAMFに送ることができる。

4. AMFは、PDU Session Modification Confirmationメッセージを応答する。

 

6.2.1.2.2.3 Slice Remapping Solution for Scenario 6 (モビリティがない場合)

NG-RANノードは、過負荷でない別のスライス2がリソースを利用でき、スライス1のSLAとの比較を行える。つまり、RAN内の負荷がかかっていないが、十分またはそれ以上の代替スライスが使用される可能性がある。

 

6.2.2 Partially slice re-mapping in NG-RAN

6.2.2.1 Candidate solutions with/without CN involvement

CN影響あり/なしの解決策

この解決策は、シナリオ 2 （スライスが未サポートの場合）に適用され、CN の関与の有無によって 2 つの可能なスライス再マッピングの解決策がある。
上図の左(a) は、RAN と CN の両方が関与する。この場合、CN手順が関与している。


上図の右(b) は、スライスの CN 側は変更せず、スライスの RAN 側を再マッピングするソリューションである。UL/DLトラフィックは、Xnトンネルを介してS-gNBとT-gNB間で中継される。

 

6.2.3 Resource management in NG-RAN node

6.2.3.1 Configuration Based Solution

このソリューションは、TS 28.541 に記載されているリソースモデリングに基づいている。以下の分析は、シナリオ1とシナリオ2それぞれについて提供される。


シナリオ1：RA内モビリティとRA間モビリティがある場合のスライスリソース不足

TS 28.541 に規定されているように、異なるS-NSSAI間のスライスの再マッピングは、優先リソースのモデル化によって実現することができる。例えば、UEの進行中のスライスがrRMPolicyMaxRatioポリシーで設定された"S-NSSAI 1"であるとすると、UEは共有リソース、優先リソースおよび専用リソースのうち少なくとも1つを使用することができる。

専用リソースが使用できない場合、他の未使用の優先順位付きリソースおよび共有リソースを使用することができる。
しかし、S-NSSAI1について、以下についてはさらに検討が必要である。

  • 複数のS-NSSAI に属するリソースを明示的に使用すること
  •  他の複数S-NSSAIの専用で使用されていないリソースを使用すること
  • 他の 複数S-NSSAI から優先的に使用される、または共有されるリソースを先行して使用すること

 

シナリオ2：RA間モビリティにおいて、非対応スライスの場合

この場合、T-gNBが特定のS-NSSAIをサポートしていない場合、これらのS-NSSAIは
RRMPolicyMemberListを使用するため、TS 28.541 に規定されているように、T-gNBによってリソースが確保されることはない。
例えば、UE の進行中のスライスが S-NSSAI 1 であったとすると、T-gNB の RRMPolicyMemberList に含まれないため、S-NSSAI 1 を T-gNB のサポートする S-NSSAI に再マッピングすることはできない。したがって、S-NSSAI 1 を T-gNB のサポートする S-NSSAI（複数可）に再マッピングすることはサポートされない。

6.2.3.2 Slice resource re-partitioning

この解決策は、シナリオ 1 （リソース不足）に適用されます。この解決策では、RAN内の特定のスライスのリソース制限が緩和される（場合によっては、限られた期間のみ）。

これは、スライス間でハードパーティションされたリソースタイプ、またはスライスごとの制限がSLAに従って定義されている場合に適用可能である。

例えば、このようなアプローチは、以下に対して適用することができる。
- スペクトル資源（スロット、ビーム、キャリアなど）。
- トランスポートリソース（バックホール容量など）。
- ハードウェアリソース（特定のプロセッサ、処理負荷、gNB-CU-UPなどのRAN内論理ノード）


この問題を解決するために、システムは、スライスが別のスライスのリソースを一時的に使用すること、すなわちパーティションをソフト化可能である。

RANは、既存のSLAを変更したり、レポートを提供したりするために使用される使用リソース管理を何らかの形で維持しながら、このような一時的なオーバーフローを可能とする。再分割ポリシーは、RANで設定することができる。

この解決策は、メトリックの収集とOAM要件に影響を与える可能性があるものの、コアネットワークやUEに影響を与えるものではない。

※gNB内でのスライスをもとにしたリソースの分割は、実装マターで勝手にやればいいじゃんといった感じ

 

6.2.3.3 Multi-carrier radio resource sharing

この解決策は、シナリオ 1 （リソース不足）に適用される。

この解決策では、無線リソースは主に周波数、またはセルベースでスライス（またはスライスセット）に割り当てられると想定している。例えば、RANノードは、以下に示すように2つのレイヤーを受け持つことができる。

複数の周波数を用いたリソース不足対策

 

このソリューションは、シナリオ 1 のように 1 つのセルでの一時的なリソース不足に対応し、RAN ノードが同じスライスが利用可能な異なる周波数と重複するカバレッジの別のセルを受け持つ場合である。
上記では、スライス1とセル1/周波数2（またはスライス1とセル2/周波数1）の場合が考えられる。解決策は、slice1 PDUセッションを持つ一部またはすべてのUEに対して、周波数1（または周波数2）のユーザープレーンリソースを使用してDCまたはCAをすることから構成されます。この動作は、CNまたは他のノードに影響することなく、RANノードが完全に決定することができる。

この解決策は、RANにおけるフォールバックプランと見なすことができる。

※カバレッジの重複する複数周波数で同じスライスをサポートしておけば、リソース不足になりづらいでしょといった感じ

 

6.2.4 Slice Remapping decision in 5GC

この解決策は、シナリオ 2 （未対応スライス）に適用される。このシナリオは、所定のスライス（S-NSSAI1 など）に関連付けられたベアラを持つ UE が、ターゲット・セルへのハンドオーバーを希望し、ターゲット・セルで S-NSSAI1 がサポートされていない場合に適用される。

これは、UEが後にスライスをサポートするセルに戻る場合のシナリオ4にも適用される。NG（N2）ベースのHOでは、AMFは、ターゲットセルがS-NSSAI1をサポートしていないこと、またはUEのターゲットセルにおけるAllowedNSSAIがS-NSSAI1を含んでいないことを検出する。その後、5GCは、S-NSSAI1に関連するPDUセッションを別のスライスへの再マッピング可否を決定する。新しいS-NSSAIは、HO要求で通知され、ターゲットgNBへの影響はない。

Xn HOを使用できるが、ターゲットgNBがUEのすべてのスライスをサポートしない場合、ソースgNBは代わりにNGベースのHOを使用し、5GCがスライスを再マッピングできるようにする。


HO の終了時に、UE はNAS の手順により、新しい Allowed NSSAI で更新される。元のスライスは拒否されたNSSAIに含まれ、UEは現在のRAに留まる限り、これにアクセ
スすることができない。。UEがもとのRAに戻ると、元のスライスをAllowed 
NSSAIに追加するよう要求することができ、PDUセッションは元のS-NSSAI1に再割り当てされ得る。
この解決策におけるスライスの再マッピングの粒度は、PDU セッションごとである。

再マッピングの決定は、登録エリアにおけるスライスの可用性、スライスの再マッピングに関する事業者のポリシー、および UE の加入者情報に基づいて行える。

 

6.2.4.1 Slice Remapping decision in 5GC at NG based handover

NG(N2) HOにおける5GCによる再マッピングの決定

1. S-gNBは、HANDOVER REQUIREDメッセージをAMFに送信する。
2. UEが現在使用しているスライスがT-gNBでサポートされていない場合、AMFはスライスの再マッピング／フォールバックの決定を行い、その決定をT-gNBへのHANDOVER REQUESTメッセージに含める。
3. T-gNBは、HANDOVER REQUEST ACKNOWLEDGEメッセージを通じてAMFに応答する。
4. AMFは、HANDOVER COMMANDを通じて、スライスの再マッピング／フォールバック決定をS-gNBに送信することができる。 

TR38.832 Study on enhancement of RAN slicing を読む [前編]

この記事はTR38.832 Study on enhancement of RAN slicing (v17.0.0)に記載されている、RANスライシングの検討に関するメモです。NetworkSlicingとはなんぞやについてはこの記事では触れません。

また、前編では最終的にRel-17で仕様化された、

  • スライスに基づくセル（再）選択
  • スライスに基づくRACH

を見ていきます。後編では、Rel-17では仕様化されなかった

Service Continuity（ハンドオーバー等を伴う場合）についても見ていきます。

 

5.1 Slice based cell (re)selection under network control 

5.1.1 Scenario and issue description 

下記のシナリオに基づいて検討を進める。

  • 異なる周波数を用いて、複数のスライスをサポート可能
  • 地域が異なれば、同一周波数で複数の異なるスライスをサポート可能

各シナリオについて、IDLEとINACTIVE状態の両方の課題・解決策を検討する。

CONNECTED状態についても、検討するが優先度は低い。

※cell reselectionに着目しているので、CONNECTED状態では起こりえず、その場合はハンドオーバーとなるので、今回は深く扱わない、ということか。

 

RANスライシングの展開シナリオ

上図において、例えばSlice1=eMBB,Slice2=URLLCを指すものとする。CellXはセルの集合を表す。F1,F2はそれぞれ異なる周波数を表す。

 

Geographical Location(以降GLと呼ぶ) 1は、工場や病院に展開される。

この場所では、F1がSlice1をサポート、F2がSlice1とSlice2の両方をサポートする

 

GL2は、パブリックな地域を表し、F1とF2はいずれもSlice1をサポートし、

この場所ではSlice2はサポートされない。また、F2は広帯域を提供するためのホットスポットとして配置されている。

※容量対策のアドオンセル的な

 

GL3は、異なるスライスが異なる周波数でサポートされている地域を表す。

それぞれの周波数は単一のSliceをサポートしている。

 

GL4は、スライスが複数の周波数でサポートされているシナリオを示す。

Slice1にはF2が、Slice2にはF1が推奨されている。

 

Cell reselectionの場合、意図したスライスとは、allowed S-NSSAIもしくはrequested S-NSSAIを意味する。

 

 initial registrationの場合、 意図したスライスとは Requested S-NSSAIを指し、IDLE時の移動の場合に意図したスライスとは、allowed S-NSSAIを指す。

 

MOトラフィック（UE→DN）の場合、UEは意図したスライスを認識しているが、MTトラフィック（DN→UE）の場合、UEは現行のNR仕様においてページングに使われるスライスを認識していない。

 

上記の前提のもと、下記の課題について検討する。
cell (re)selectionのPriorityについては下記参照。
LTE Cell Camping and Selection Procedure - Techplayon

  1. UEが異なるセルまたは周波数でサポートされるスライスを認識しないと、UEが意図するスライスをサポートするセルまたは周波数を選択できない。 
    ※どうやって基地局がサポートするスライスをUEに通知するか的な

  2. Dedicated Priorityは、最初のRRC接続確立前にはUEが利用できず、IDLEモードに移行する際にT320タイマーが失効する前にのみ有効である。
    さらに、Dedicated Priorityは、UEがCONNECTEDモードに入るたびに破棄され、UEがCONNECTEDモードでなくなる際に、再度設定する必要がある
    ※一回RRC確立しないと通知できないとか、毎回設定し直しイケてないよね的な？
  3. オペレータは、異なる地域の特定のスライスに異なる周波数優先順位を設定するかもしれないが、Dedicated Priorityが設定されている場合は、常にブロードキャスト優先順位より優先してしまう。
    ※SIBで報知されるCommon priorityより、RRCReleaseに含まれてる方を優先しちゃうけどいいのか的な

  4. サービングセルが要求されたスライスをサポートできない場合、サービングセルは、要求されたスライスをサポートするセルへのハンドオーバーを実行するか、RRC 接続を解放する必要がある場合がある。
    その場合、制御プレーンの信号オーバーヘッドが増加し、UEがネットワークにアクセスするための制御プレーンの待ち時間が長くなる可能性がある。
    ※UEがつなぎたいスライスが基地局側にない場合どうするか的な
5.1.2 Solutions

Solution1:Legacy dedicated priority via RRCRelease message

RRCReleaseメッセージによるレガシーなDedicated Priority設定は、課題2および課題3に対処することはできない。

※そもそも、課題2,3はRRCReleaseによるDedicated Priority設定の課題なので

 

Solution 2: Rel-15 mechanisms such as HO, CA, DC and redirection can be used to access the intended slice in different cell

解決策2もレガシーである。UEは、異なるセルまたは周波数でサポートされるスライスをまだ認識していないため、HO、CA、DC、およびリダイレクションを使用して、このような損失を補えるものの、遅延やシグナリングのオーバヘッドは増加する。
HO、CA、DC、リダイレクションは、CONNECTED状態の UE にのみ適用される。
※複数セルとつながっておけば、どれかが意図したスライスだろう的な？


Solution 3: Slice related information for cell selection, e.g., the supported slice info of serving cell and neighboring cells, is provided in the system information.

解決策3は、課題1、2、4に対処することが可能、SIBでスライス関連のセル選択情報（サービングセルや隣接セルのスライスサポート情報）をブロードキャストすることに利点がある。

ただし、スライス関連のセル選択情報をSIBで報知する際のセキュリティやペイロードサイズに関する懸念はWI中に議論する必要がある。

→こちらは最終的にNSAGというS-NSSAIの集合として最終的にSIB16で報知されることになった(TS38.831参照)

SIB16

※SIBでサポートするスライスを報知しようという、割りと普通な発想な気がするものの、最終的にNSAGという形でS-NSSAIが包まれてしまった

 

Solution 4: Slice related information for cell reselection is provided in the system information or RRCRelease message

解決策4は、Solution3に加えて、従来のRRCReleaseにもセル再選択のためのスライス関連情報を含める方法で、課題1、2、3、4全てに対処することが可能である。

RRC Releaseに追加されたスライス関連IE


※従来方法のRRCReleaseにIE追加＋SIBで報知するという方法

 

5.2 Slice based RACH configuration

5.2.1 Scenario and issue description

スライスベースの RACH の意図は以下の通りである。


意図1：RACHリソースの分離

マーケティングの観点から、一部の産業分野のユーザは、スライスで保証された無線リソースを得るため、アクセスリソースの分離を要求しています。


意図2：スライスのアクセス優先順位付与
Rel-15 ,16 では、すべてのスライスが同じ 無線リソースを共有しており、ネットワーク側で区別することはできない。しかし、一部のスライスはRACH手順中に優先順位付けが必要な場合がある。

 

※スライスをもとに、①RACHのリソースそのものを分けちゃう②RACHの優先順位をつける　の２つ

5.2.2 Solutions

Solution 1: Slice-specific separate RACH resources pool can be configured per slice or per slice group, in addition to the existing common RACH resources.

（既存の共通 RACH リソースに加え、スライスごと、またはスライスグループごとにスライス固有の独立した RACH リソースプールを設定可能とする）

スライスとスライス固有のRACHリソースとの関連付けは、SIBおよび特定のシグナリングにおいて設定され、UEに提供可能とする。分離されたPRACH構成（例えば、時間-周波数領域とプリアンブルの送信機会）は、スライスまたはスライス・グループに対して構成することができる。スライスに対する分離された PRACH 設定は、PHY レイヤーには影響を及ぼさない。

 

Solution 2: Slice-specific RACH parameters prioritization can be configured per slice or per slice group.
（スライスごとの RACH パラメータの優先順位をスライス毎もしくはスライスグループごとに設定可能とする）

 

既存の RACH パラメータの優先順位付け（すなわち、scalingFactorBI および
powerRampingStepHighPriority）は、スライス固有の RACH パラメータ優先順位付けのベースラインとしてサポートできる。

スライスベースの RACH 構成は、IDLEおよびINACTIVE状態のUE に適用することができる。

 

最終的にTS38.300にどう反映されたか

現時点ではまだ更新されてないので、RAN#97-eで承認されたCRを見ていきます。

[RP-222525][R2-2209224]

Slice-based cell reselection

仕様化されたスライスに基づくセル再選択

　スライスベースのセル再選択情報は、SIB16およびRRCReleaseメッセージに含まれ得る。スライスベースのセル再選択情報は、NSAGごと（周波数ごと）の再選択優先順位と、NSAGのスライスがサポートされるかサポートされないセルの対応するリスト（複数可）とを含むことができる。

　UEでは、NASがセル再選択時に考慮すべきNSAGとその優先順位を提供する。
UE がスライスベースのセル再選択をサポートし、スライスベースのセル再選択情報が UE に提供された場合、UE はスライスベースのセル再選択情報を使用する。

RRCRelease で提供される有効なセル再選択情報は、常に SIB メッセージで提供されるセル再選択情報よりも優先される。UE AS が NAS から受信した NSAG のうち、セル再選択時に考慮すべきスライスベースの再選択情報が提供されない場合、UE は NSAG およびその優先順位を考慮せずに、一般的なセル再選択情報を使用する。

※SIBとRRCRelaseの両方でセル再選択に用いるスライス情報を伝達する

Slice-based RACH configulation

仕様化されたスライスに基づくRACH

　RA分離および優先順位付けのためのスライスベースのRACH構成は、SIB1メッセージに含めることができる。スライスベースのRACH設定は、特定のNSAG（複数可）に関連付けられ、UEがRACH設定の選択のために考慮するNSAGが提供されない場合、UEはスライスベースのRACH設定の選択にそのNSAGを考慮しない。UE では、NAS が AS へ RA 中に考慮すべき NSAG を提供する。

 

 

 

 

3GPP Plenary#97-e (2022/09)寄書を読む

この記事では、2022年9月に行われた3GPP Plenaryのサマリ及び筆者の気になった寄書を紹介していきます。

3GPPとは何ぞやとか、寄書の眺め方については、過去の下記記事を参照下さい。
# ちなみに、今回の記事の内容もRANが多めです

omusubi5g.hatenablog.com

Workplan/TImeline

[RP-221900  / CP-222012  / SP-220972]

Plenaryでは毎回Releaseのスケジュールも議論の項目になります。

2022/09時点では、下記のようです。

  • Rel-17:仕様凍結は済んでいるものの、まだCorrection（修正）が必要な項目も多い
  • Rel-18:2023/12の仕様凍結を目指して進行中。RANでは、3ヶ月後の2022/12 Plenaryで改めてRel-18のTimelineについては議論される予定
  • Rel-19:SA1で検討開始。まだ大枠のTimelineは未定

2022/09時点でのスケジュール

ちなみに、Rel-18からは、5G-Advancedとしてロゴも少し変わっています。

5G-Advancedのロゴ。LTEでもこんな感じでしたね。

LTEではLTE→LTE-Advanced→LTE-Advanced Pro と少しずつパワーアップしていきましたが、5Gの場合は次は6G的な新たな世代になるのでしょうか。この辺りもRel-20あたりから議論が始まるかもしれません。

その他、本格的なRel19以降の検討に向けたPlanningの寄書も何件かありました。

新たなReleaseの検討を開始するにあたっての順序としては、おおよそ3クォーターかけて下記のように決めていくようです。

  1. Workshopで各社の展望を語りつつ、テーマを絞り込む
  2. Releaseのテーマを決定する
  3. テーマをWI/SIに落とし込んで決定する

Planning　Timeline [SP-220965]

New WorkItem/StudyItem

今回の会合で承認されたWorkItem/StudyItemの中で、個人的に気になったものを

紹介していきます。

#Enhancement～や、～Phase2 等は基本的に過去の検討の続き感が強いので、ここでは#あまり取り上げていません

 

NR Network-controlled Repeaters (RAN Rel-18)

[RP-222673]

TR 38.867 Study on NR network-controlled repeatersでの検討をもとにしたWorkItemで、従来から検討されているカバレッジ拡張方式のひとつ、RFリピータをさらに拡張し、Network-controlled repeaterとして定義し、その方式を検討しています。

 

 似たようなカバレッジ拡張技術としてIAB(Integrated Access and Backhaul)も議論されていますが、RFリピータは簡単に言うと、電波を増幅して中継するアンプであるのに対し、IABは基地局-基地局間を基地局-UEと同じように結び、その回線をバックホール回線として用いる規格です。

 

Network-controlled repeater のコンセプト図を下記に示します。

NCR (Network-controlled repeater)のコンセプト

Control link (C-link)は、NR-Uu上で伝送され、NCR-MTによってNCRを制御します。

NCR-FwdはBackhaul linkとAccess linkを介して、RFの増幅アンプとして機能します。

NCRは、例えばC-linkを介して電源ON/OFFや送信電力制御を行うことで、状況に応じた
SINRの改善（干渉影響の軽減）やカバレッジ拡張を柔軟に行えようになる、としています。

※特に、FR2のミリ波のような基地局に対して有効な気がします

 

 

High power for FR1 for FDD single band(s) with power class 2 (RAN Rel-18)

[RP-222083]

現状のUEの最大送信電力はグローバルで見ても、23dBmが標準となっていますが、

過去、アップリンクのカバレッジ向上を目的に、LTE-TDD B41(2.5GHz)での高出力UE(HPUE)等が検討されてきました。

HPUEって何ぞ
https://www.kiai.gr.jp/jigyou/h30/PDF/0606p1.pdf


TR 38.861 Study on high power UE (power class 2) for one NR FDD bandでは、低い周波数の NR FDDバンドn1,n3へのHPUE適用に向けた検討を行ってきましが、このWorkItemではさらにn8,n28等のNR FDDバンドへのPower class 2 (26dBm)適用に向けた下記のような検討も行っていきます。

  • 帯域固有のRF要件
  • UE最大出力電力とTx電力許容値
  • A-MPR（AdditionalMaximumPowerReduction）要件
  • Power class 2の感度劣化要件

※HPUEは、UE~衛星までの距離が課題であるNTNへの適用も十分あり得そう

 

5G System with Satellite Backhaul (SA Rel-18)

[SP-220808]

TR23.700-27 Study on 5G System with Satellite BackhaulをもとにしたWorkItemです。

NTNと少し違った観点で、gNBのバックホール回線として衛星が用いられる場合の様々な検討が行われています。例えば、複数の衛星をバックホール回線として用いる場合のPCC/QoSに基づく経路選択や、UPFが衛星に搭載された場合のEdgeComputing、UE間の折り返し通信の実現に向けた方式検討が行われています。

バックホールに色んな衛星を選べるとしたらどう選択する？

衛星にUPFを搭載して、EdgeComputingしちゃおう

UE間通信は衛星のUPFで折り返しちゃおう

※NTNの方でもUPF搭載シナリオを検討しても良い気がしますね

Timing Resiliency and URLLC enhancements (SA Rel-18)

[SP-220814]

TR 23.700-25 Study on timing resiliency and TSC and URLLC enhancements をもとにした

WorkItemです。こちらは、以前にも少し触れたIIoT(Indsutrial IoT)関連の検討となります。

omusubi5g.hatenablog.com

この分野ではRel-15の頃から、産業用イーサネットやOTと呼ばれるネットワークと、5Gシステム統合を目指しています。具体的には、TSN (Time-Sensitive Networking)と5Gシステムとの統合に向けた検討を以前から実施していて、Rel-17の頃からは関連の深いURLLCも含めた検討となっています。

Rel-18の今回では、主に下記の議論が中心となるようです。

  • GNSS障害時に5Gシステムが自走し、5Gシステムがバックアップとして機能し、他のアプリケーション向けに無線および屋内対応の時間同期サービスを提供するための要件を規定する
  • 低遅延と低ジッターをサポートするために、TSNトランスポートネットワークと相互運用するための拡張
  • アプリケーションからのバースト送信を調整するための フィードバック対応（例：RANでのバッファリングを避けるためにアプリケーションがDLパケット送信タイムスロットを検討するなど）
  • 5GSが低遅延（例：2ms）要件を満たすために、アプリケーションがダウンストリームスケジューリングを適応させるメカニズムをサポートする

※5G-TSN統合はRel16で基本的な機能が標準化されましたが、まだまだ本格的な実装・運用に向けては検討課題が多そうな印象です

今回取り扱われなかったWI提案(RAN Slicing)

[RP-222444][RP-222355]

further enhancement of RAN Slicing for NR

個人的に追いかけているRAN slicingの項目です。RANにおけるSlicing検討は

Rel-17にてStudyItemが検討され、TR38.832にてまとめられています。

#こちらは別途解説記事を執筆予定です。

Rel-17において、上記はWIとしても検討され、

  • スライスベースのセル再選択
  • スライス毎のRACH優先付け

がサポートされます。ただし、サービス継続性（ハンドオーバなど）の実現ついては、UEとコアの両方にも影響があり、さらなる調査・検討が必要とされました。

そこで、Rel-18ではさらなる拡張として下記を検討すべきとしています。

  • 端末トリガーによるスライス認識セル再選択をサポートするためのメカニズムおよびシグナリングを規定する
  • サービングセルがサポートしないスライスについて、DCまたはCAを設定することにより、UEが意図するスライスにアクセスすることをサポートするメカニズムを規定する
  • 基地局間移動シナリオの場合、ターゲット 基地局がサポートしないスライスについて、TR 38.832 のセクション 6.2.1 に記載されているように、ターゲット基地局側で再マッピングするため方式検討

と言った具合に、いわゆるE2Eスライシングを実現するために必要と思われる、

基地局間を移動した場合でもRAN含めたスライスベースの制御を実施する、という部分の検討がRel-17では未検討であるため、Rel-18でも継続議論が必要、という主張のようです。

※ZTE,CMCCといった中国勢しか熱心では無いようで、今回も取り扱われず承認には至りませんでしたが...　その他ベンダは、E2Eスライシング実現でロックインするため、実装マターにしておきたいのかも？

 

Status Report

絶賛議論中の項目の各WGにおける検討状況をサマった寄書たちです。

Status report for SI: Study on enhancement for resiliency of gNB-CU-CP

[RP-222250][RP-222271]

こちらは、丁度RAN3での検討が完了し、TRのドラフトも寄書・承認されていましたので、TRの内容を見ていきます。

TR38.879 Study on enhancement for Resiliency of gNB-CU-CP

 一口にgNBといっても、5Gではfunction splitの観点から、gNB-CU/gNB-DUに分割されます。そして、gNB-CUはさらにC-plane担当のCUCPとU-plane担当のCUUPに分割されます（CUPSとも言われたりします）

標準上は、ひとつのgNB-CU-CPに対して複数のDUが接続されることも想定されており、下図のようにCU-CPは複数のDU、AMF、隣接するgNBのCU-CPと多数のノードと接続されることが想定され、かつ単一障害点にも見て取れます。

CU-CPに障害が発生すると、すべてのユーザ通信に影響が出る可能性があることから、

本項目ではCU-CPの障害シナリオを検討します（解決策は本項目では取り扱わない）

gNB-CU-CPとはなんぞや

障害シナリオとしては、大きく下記を検討しています。

  • Hardware failure
  • Software failure
  • Transport network failure
  • Power failure
  • RAN node breakdown, e.g., due to natural disaster

各シナリオについて、具体的な影響部分も含めたシナリオを議論しています。

例えば、Transport network failureによる、gNB-CU-CP～DU間のSCTP断（F1AP断）

などが挙げられています。

例: transport network failure によるSCTP断(F1AP断)

このStudyItemでは障害シナリオのみの検討でしたが、解決策についても今後議論される可能性が高いと思われます。

 

 

 

TR38.821 Solutions for NR to support NTNを読む (8.4章 Transport)

この記事は、TR38.821 Solutions for NR to support NTN(v16.1.0)の

8.4 Transport aspects について筆者なりの解釈を記載したものです。

前回の8.3章を読んでからのほうがわかりやすいかもしれません。

TR38.821 Solutions for NR to support NTNを読む (8.3章 Mobility) - omusubi techblog

※文中の赤文字は筆者コメントであり、正しい解釈とは限りません。

8.4 Transport aspects

とりあえず構成図。ISL、SRI、NTN-GWが今回の着目点

NTNに関わるトランスポートNWについて考察する。

透過型の場合：NTN-GWは一つ以上の衛星とSRIを介して接続する。

再生中継型の場合：NTN-GWは一つ以上の衛星とSRIを介して接続する、もしくは一つ以上の衛星とISLを介して間接的に接続する。したがって、NGプロトコルはSRIもしくはISLで伝送されることもある。


衛星はトランスポートNWのルーティング機能を持つこともできるが、これは3GPP RANのスコープ外となる。

 

SRIは3GPP-RANのプロコトル、すなわちNGインタフェース信号を伝送する。

※F1プロトコルも伝送できそうだけど、NGのみ言及？

ISLは下記を伝送可能。

  • Xnインタフェース信号
  • データパケット
  • NGインタフェース信号
  • F1インタフェース信号

※SRIでも上記は伝送可能と思われるのであえて分けた理由が謎

 

SRI上での転送は、以下の制約を受ける場合がある。

  1. 地球上の輸送リンクに比べて伝搬遅延が長い 。地球-衛星リンクの典型的な長さは、数千km（LEOシナリオ）から数万km（GEO シナリオ）である。したがって、SRI上の片道遅延は、6 ms（LEO、600 km、高度10°）から136 ms（GEO、35,788 km、高度10°）までとなる。
  2. SRI がミリ波で動作する場合、地上伝送リンクに比べて断となる可能性が高くなる。ミリ波は伝搬障害（例：雨による減衰）の影響を大きく受けます。しかし、これはUplinkPowerControl、適応符号化変調方式、スペース・ダイバーシティ方式によって緩和されます。通常、フィーダーリンクは、サイトダイバーシティで最大99.999%の可用性を実現するように設計されている。
  3. SRIが利用できなくなる可能性がある
    a. SRIがミリ波で動作する場合、大気による減衰のため
    b. LEO衛星の場合、衛星が地平線の下に消えたとき

したがって、シームレスなサービス継続と中断時間 0ms を確保するために、モビリティ管理が通常行われる。

 

透過型の場合

  • GEOまたはLEO衛星は、ある時点では、複数のNTN-GWに接続することができる。各NTN-GWは、衛星の異なる無線リソースに対応する。
  • フィーダリンクの切替は、2 つの異なる無線リソースを同時に使用して行うことができ、パケットロスの少ない切替を実現する。この手順はネットワーク起因のものである。

再生型の場合

  • LEO衛星は、フィーダリンクの切替時を除き、一度に1台のNTN-GWにしか接続できないため、Make Before Break方式によるシームレスなサービス継続が可能
    ※なぜLEO衛星は１台のみ？要調査
  • フィーダリンクの切替損失が少ない切り替えを実施するために、make before break 戦略に基づく。これは、レイヤー 3 以下の NG-RAN 手順では UE に対して透過的である。この手順は、ネットワーク起因のものである。 

LEO の場合、ISL の片方向伝搬遅延は、コンステレーションに依存する
※コンステレーション＝複数の衛星の配置的なイメージ

（10ms 程度の値が一般的と考えられる）
LEO衛星の衛星間通信は、一般的に99.999%の可用性を持つ。

8.4.1.3 Characteristics of NTN GW

透過型の場合

NTN-GWはNR-Uuインタフェースの信号を転送するために必要な全ての機能をサポートする。

再生型の場合

NTN-GWはトランスポートネットワ層のノードであり、例えば、NTN-GWはIPルーターとして機能するなど、必要なトランスポートプロトコルを全てサポートする。

SRIはNTN -GWと衛星の間にIPトランク接続を提供し、それぞれNGまたはF1インタフェースを伝送する

8.4.1.4 Ephemeris

衛星エフェメリス情報（軌道情報）は、NTNベースのNG-RANにおける共通の、遅延やドップラーシフトの変動に対する事前・事後補償と同様に、フィーダーリンク切替発生、モビリティ管理イベント（Idleおよびconnected）、無線リソース管理の予測に使用可能である。


衛星エフェメリス情報は、5GCのモビリティ管理などにも有用な場合がある。


RANと5GCで衛星エフェメリス情報を設定するためのOAM要件があるかもしれない。

エフェメリス情報は、デファクトスタンダードであるTLE（Two-Line 
Element）フォーマットを用いて、ASCIIファイルで表現可能。

2行軌道要素形式 - Wikipedia

 

8.4.2 Transporting F1 over the SRI 

CUが地上の図

TS38.401（NG-RAN;Architecture description)の定義によると、CUはRRC,SDAP,PDCPプロトコルを管理し、DUはRLC,MAC,PHYレイヤーを管理する、CUは1つ以上のDUを運用可能である。

F1(CU-DU間のインタフェース)がSRI上で伝送される場合、上記の機能は8.4.1.1 Characteristics of SRI on the feeder link で述べたSRIの特徴による制約を受ける可能性がある。

長い伝搬遅延は、実装次第ではあるが適切なタイマ設定を施すことで、NTNユースケースによる様々なプロトコル運用が、阻害されないようにできるかもしれない。

※伝搬遅延大きいけど、タイマのチューニングすればいけるっしょ的な

 

また、RRCをCUが終端するという事実が大きな課題になり得る。

CUが地上にある場合、UEとCU間の単一のRRCメッセージの往復時間は、地球と衛星のリンクの2倍に相当する（RRCメッセージはNR-Uuを経由し、F1上を伝送されてSRIを通過する）。現在の NR RRC がこのような制約に耐えられるかどうかに関係なく、gNB-DUが衛星に搭載されるアーキテクチャは、RRCレイテンシという観点で他より不利となる可能性がある。

※RRCの確立・開放みたいなRACH手順にすげー時間かかるよ的な

 

回線断可能性の影響は、ミリ波周波数帯の地球-衛星リンクの典型的な最大断時間と、CU が UE を見失ったと判断し、コンテキスト削除を開始するまでの時間（通常 1 分未満）を比較することで分析可能である。SRIが停止した場合、CUの運用に悪影響が生じる。

 

さらに、CU と UE の間に 2 つの地球-衛星パスが存在するため、SRIの性能にもよるが、断の確率が両方のパスのそれぞれの断確率を合わせたものとなり、gNB-DUが衛星搭載のアーキテクチャは、回線断の点でも他のアーキテクチャと比べて影響が大きい。


SCTPマルチホーミング、またはCUとDU間の複数のSCTPアソシエーションを利用して、同じF1インタフェースを伝送するために複数の地球-衛星リンクを使用すると、遅延が追加になる部分はあるものの、障害またはゲートウェイ切り替えによるSRI使用不可を軽減できる可能性がある。

※ISLで別パスを構成するとか、複数のNTN-GWと接続するとか？

 

地球局が遠くなればなるほど、リンク停止は相関を失い、リンク停止合計確率は減少するが、CUまでの総距離（F1の遅延）は増加し、遅延は増加する。

したがって、リンク停止確率とF1遅延はトレードオフになる。

※地球局から遠くなるほどリンク停止確率が減るのはなぜか・・・見通しがとれるから？GEOが一番OutageProbabilityが低くなる？


8.4.3 Applicability of Xn to NTNs

8.4.3.1 List of Current Xn Functions

TS38.420 Xn general aspects and principles内でサポートされている機能に対する、NTN適用時の制約に関する寄書は、StudyItemの時点ではなかった。

8.4.3.2 Inter-Satellite Xn

両方の衛星gNBが同じAMFに接続されていることを前提に、衛星間XnのUEモビリティ管理は有用であると考えられる。

純粋にアーキテクチャの観点から、NR-DCは（一方の衛星がMasterNode,他方がSecondaryNodeとなる）排除されるものではないが、NR-DCがサポートされると結論づけるには、さらなる分析（例えば、RAN3のスコープ外であるRRC観点）が必要である。

この場合、例えばコンスタレーション再構成の一環として、1つの
衛星が別の衛星にセルのアクティベーション／非アクティベーションを通知することで、省電力的な何らかの恩恵もアーキテクチャの観点から排除されるものではない。

※複数の衛星gNBでのCA/DC的なのも無くはないよね～的な

 

Xn-Uの機能はモビリティとDCに適用されるため、同じように考慮する必要がある

したがって、衛星間Xnは有益であると考えられるが、このようなシナリオでのNR 
DCの実現性を評価するためには、さらなる分析が必要である。
トポロジーの観点からは、衛星間 Xn は ISL 上で直接伝達されるか、SRI を介して伝達される。

8.4.3.3 On-ground NTN-terrestrial Xn 

これは、地上に設置されたgNBと地上gNB間のXnベースのUEモビリティとNR 
DC機能をサポートするもので、両方gNBが同じAMFに接続することが条件とされる。

※透過型もしくはgNB-DUだけ衛星に搭載されている場合


もう一つの特徴は、Xnを介した地球-衛星間セルのアクティブ化／非アクティブ化の通知をサポートすることである。

例えば、地上のgNBは、同じエリアをカバーする衛星に、1つ以上のセルをオフにすることを通知し、衛星は対応するカバーエリアの「引継」を行うことが可能である（その逆も然り）。しかし、これらの機能の利点は評価されていない。

※NTNセルでのカバーエリアを、地上gNBにおまかせしたり、されたりもできるらしい。何が嬉しいかわからないので使われなさそうな気もする

 

8.4.3.4 Transporting Xn over SRI

衛星搭載gNBと地上gNBの間の地球-衛星間リンクでのXn伝送はチャレンジングであるが、SRIの性能次第では可能と考えられる。

 

例えば、LEOのシナリオでは、衛星が地平線の下に移動すると、地上gNBへのXnインタフェースはすべて利用できなくなり、関連する地上gNBのアプリケーションプロトコルやSCTPレベルでもその後の処理が引き起こされる。衛星が地平線上に現れると、その逆のことが起こり、地上gNBとXnを確立し始める。

これは、LEO衛星の視認性次第で、C-plane信号の輻輳にも繋がりかねない問題を有する。

さらに、SRIの断にによって、Xnが利用不可となる時間も想定され、これはSRI断のたびに地上局とのC-plane信号が輻輳が発生する問題も有している。

したがって、このXn over SRIの構成については評価されなかった。

※Xnは影響が大きすぎるのであまりSRIというか衛星回線に載せたくない模様