omusubi techblog

This website is my technical memo (Mobile/Wireless)

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に送信することができる。