この記事は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.2 Slice based RACH configuration
- 最終的にTS38.300にどう反映されたか
5.1 Slice based cell (re)selection under network control
5.1.1 Scenario and issue description
下記のシナリオに基づいて検討を進める。
- 異なる周波数を用いて、複数のスライスをサポート可能
- 地域が異なれば、同一周波数で複数の異なるスライスをサポート可能
各シナリオについて、IDLEとINACTIVE状態の両方の課題・解決策を検討する。
CONNECTED状態についても、検討するが優先度は低い。
※cell reselectionに着目しているので、CONNECTED状態では起こりえず、その場合はハンドオーバーとなるので、今回は深く扱わない、ということか。
上図において、例えば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
- UEが異なるセルまたは周波数でサポートされるスライスを認識しないと、UEが意図するスライスをサポートするセルまたは周波数を選択できない。
※どうやって基地局がサポートするスライスをUEに通知するか的な - Dedicated Priorityは、最初のRRC接続確立前にはUEが利用できず、IDLEモードに移行する際にT320タイマーが失効する前にのみ有効である。
さらに、Dedicated Priorityは、UEがCONNECTEDモードに入るたびに破棄され、UEがCONNECTEDモードでなくなる際に、再度設定する必要がある
※一回RRC確立しないと通知できないとか、毎回設定し直しイケてないよね的な？ - オペレータは、異なる地域の特定のスライスに異なる周波数優先順位を設定するかもしれないが、Dedicated Priorityが設定されている場合は、常にブロードキャスト優先順位より優先してしまう。
※SIBで報知されるCommon priorityより、RRCReleaseに含まれてる方を優先しちゃうけどいいのか的な - サービングセルが要求されたスライスをサポートできない場合、サービングセルは、要求されたスライスをサポートするセルへのハンドオーバーを実行するか、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参照)
※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全てに対処することが可能である。
※従来方法の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
RA分離および優先順位付けのためのスライスベースのRACH構成は、SIB1メッセージに含めることができる。スライスベースのRACH設定は、特定のNSAG（複数可）に関連付けられ、UEがRACH設定の選択のために考慮するNSAGが提供されない場合、UEはスライスベースのRACH設定の選択にそのNSAGを考慮しない。UE では、NAS が AS へ RA 中に考慮すべき NSAG を提供する。
