この記事は、TR38.821 Solutions for NR to support NTN(v16.1.0)の
8.3 Connected mode mobility について筆者なりの解釈を記載したものです。
前回の、5GSAにおけるハンドオーバー調査記事を基に進めていきます。
5GSAでのハンドオーバーの種類をまとめる - モバイル関連のネタを書き綴るブログ
※文中の赤文字は筆者コメントであり、正しい解釈とは限りません。
- 8.3 Connected mode mobility
- 8.3.1 Architecture Classification
- 8.3.2 Intra-gNB Mobility ("Monolithic gNB")
- 8.3.3 Intra-DU Mobility
- 8.3.4 Intra-gNB/Inter-DU Mobility
- 8.3.5 Inter-gNB Mobility （gNB間のHO）
- 8.3.6 Mobility due to interface change（NGとかF1とか）
- 8.3.7 Summary
8.3 Connected mode mobility
NTNにおいては、下記の異なる3種類のハンドオーバーが存在する。
これらは衛星が透過型もしくは再生中継型（gNB全部もしくは一部が衛星に搭載）であるかによって、バリエーションが存在する。
透過型
透過型の場合、gNBは地上に存在し、UE~gNB間のUuインタフェースが衛星区間となる。
再生中継型（gNB全部搭載）
再生中継型（gNB全部搭載）の場合、衛星のサービスリンクがUuインタフェース区間、
フィーダーリンク（SRI）がN2（NGAP）区間となる。
再生中継型（gNB一部搭載）
再生中継型（gNB全部搭載）の場合、gNBをCU、DUに分割し、CUを地上に、DUを衛星に搭載する。したがって、衛星のサービスリンクはgNB全部搭載型と同じくUuインタフェース区間であるが、フィーダーリンク（SRI）はF1区間となる。
これらを踏まえて、改めてNTNのハンドオーバーシナリオについて、5GSAにおけるNG-RANのハンドオーバー手順と照らし合わせたのが下記表である。
※inter-gNB handover = Xn or N2 handover?
ここは想定条件が曖昧なので、とりあえずサラッと読みで良さそう
1.Intra satellite hand-over(衛星内ハンドオーバー)
- 透過型の場合（衛星に複数のアンテナが搭載されていると想定する）
- Intra-gNB HO→ひとつの基地局から衛星上の複数のアンテナ（＝セル）に接続されている場合のセル間HO
- Inter-gNB HO→複数の基地局から、衛星上の複数のアンテナ（＝セル）に接続されている場合のセル間HO - 再生中継型（gNB全部搭載）の場合
- Intra-gNB HO→衛星にはひとつのgNBしか搭載されていないと想定すれば、gNB内のHOのみ - 再生中継型（gNB一部搭載）の場合
- Intra-gNB-DU HO→衛星搭載のDU配下でのHO
- Inter-gNB-CU HO→DUが衛星に複数存在し、それぞれ異なるCUにつながっている場合。※ただし、その場合 Inter-gNB-DU HOもありそう。
2.Inter satellite hand-over(衛星間ハンドオーバー)
- 透過型の場合（衛星に複数のアンテナが搭載されていると想定する）
- Inter-gNB HO→複数の基地局から、複数の衛星上のアンテナ（＝セル）に接続されている場合のセル間HO
- Intra-gNB HO→ひとつの基地局から複数の衛星上のアンテナ（＝セル）に接続されている場合のセル間HO - 再生中継型（gNB全部搭載）の場合
- Inter-gNB HO→衛星=gNBと考えられるので、inter-gNB HOのみ
※ISLがXn? - 再生中継型（gNB一部搭載）の場合
- Inter-gNB-DU HO→衛星＝DUと考えられるので、同じCU配下のDU間HOであればこちら。
- Inter-gNB-CU HO→ 衛星＝DUと考えられるので、別CU配下のDUの場合のHOであればこちら。
3.Inter access hand-over(セルラーと衛星間ハンドオーバー)
- 透過型の場合（衛星に複数のアンテナが搭載されていると想定する）
- Inter-gNB HO→衛星向けの地上局と通常の基地局間のHO
- Intra-gNB HO→ひとつの地上局が、衛星搭載のアンテナと地上アンテナに接続されている場合のHO - 再生中継型（gNB全部搭載）の場合
- Inter-AMF/UPF,Intra-AMF/UPF→地上局とのHOのため、距離が大きいことが想定され？、AMFを跨ぐようなHOもしくは、N2 HOが想定される。 - 再生中継型（gNB一部搭載）の場合
- Intra-gNB HO→ひとつの地上局が、衛星搭載のDUと地上のDUに接続されている場合のHO
- Inter-gNB HO→衛星向けの地上局のCUと通常の基地局間のHO
いずれも、モビリティ手順に衛星回線による遅延を考慮した適応を実施する必要があると考えられる。
セルラーと衛星間のハンドオーバーについて、透過型はXnハンドオーバー、再生中継型はN2ハンドオーバーが利用されると想定される。
※透過型は地上にgNBがそれぞれあるので、Xnが適用可能であるが、再生中継型はSRIにXnが重畳されることは考え難いとしている？
すべてのUEがPositioning（位置測位）に対応しているとは限らないと想定している。
※GNSS以外の情報を用いた測位情報をこれらのHandoverに必ず使えるわけではないという想定か
8.3.1 Architecture Classification
これまでに述べたアーキテクチャを下記の5つに整理する。
- 透過型
透過型（再掲） - 再生中継型（gNB一部搭載）
再生中継型（gNB一部搭載:再掲） - 再生中継型（gNB全部搭載）
再生中継型（gNB全部搭載:再掲） - ISLを伴う再生中継型
ISLを伴う再生中継型 - リレー（≒IAB）型
IABの概要(TR38.874)
※5.リレー型は、地上のgNBがIAB-donor、衛星搭載gNBがIAB-nodeとなる想定か？
この場合、IAB-donor~IAB-node間はF1でもXnいずれも想定され得る。
8.3.2 Intra-gNB Mobility ("Monolithic gNB")
HO時にgNB内で制御信号が閉じる簡単なケース。NG、Xnインタフェースへの影響がない。1,3,4,5のアーキテクチャでサポートされる。
※2もIntra-gNBと思うが、次で更に粒度の細かいIntra-DU Mobilityとして触れられているので、ここには含まれないとしていそう。
8.3.3 Intra-DU Mobility
HO時にDU内で制御信号が閉じるケース。DU-CU間のF1インタフェースへの影響がない。2のアーキテクチャでサポートされる。
8.3.4 Intra-gNB/Inter-DU Mobility
DU間のHOとして、2のアーキテクチャでサポートされる（この場合、F1インタフェースはSRI上でやりとりされる）
単一の論理DUは、複数の衛星にまたがることはないとする。
※Intra-gNB/Inter-DUのHOを考える場合、複数DUは論理的に分かれていて、かつ一つの衛星に共存している場合を想定するとしている模様？
8.3.5 Inter-gNB Mobility （gNB間のHO）
8.3.5.1 Xn Mobility
アーキテクチャ1,2はXnが存在する場合、地上で終端され、既存の標準へ影響は無い。
※1はgNBが、2はCUが地上に存在するため
アーキテクチャ3はXnが存在しないのでXn HOはサポート不可。
※図をみるに、SRIではNGインタフェースがやりとりされ、AMF以外には繋がらないと想定している？
アーキテクチャ4は、衛星にgNBが全部搭載されている場合に限り、ISL上でXnインタフェースをやりとりして、Xn HOが可能。
現状のNG-RANにおいて、Xnは隣接セル間の水平的なインタフェースであり、コアとのやりとりを最小限に最適なHOを実現する手法であるが、NTNに適用する場合は、隣接セルについて、下記の異なる点に着目する必要がある。
1.については、アーキテクチャ4でISLにXnを設定する場合が相当する。
2.については、NTN gNBと地上系gNBの間にXnが存在すれば、Xn HOが可能となる。
※なので、アーキテクチャ1,2はサポート可能？
アーキテクチャ5も理論上は衛星gNBと地上gNB間でXn HOを実現可能であるが、
性能については疑問視されている。
※IAB-donorが地上gNB、IAB-nodeが衛星gNBとして、NR-UuにXnを重畳するということか？たしかに、IAB自体実装が難しそうなので、NTN適用はさらにハードルが高そう。
8.3.5.2 Mobility through the 5GC（5GCを介したHO）
アーキテクチャ1,2は地上局でNGが終端される（=AMFとNGAPを確立するCU-CPが地上にある）ので、標準への影響なく、5GCを介したHOが可能。
アーキテクチャ3,4,5は衛星でNGが終端されるので、SRIを介したNGの伝送が必要になる（5GCを介したHOは可能）
8.3.6 Mobility due to interface change（NGとかF1とか）
ここでのHOは、UEの移動によるHOというよりかは、衛星の移動によりgNBのインタフェースに変更が発生し、UEが地上系のgNBや別の衛星gNBへHOする場合を想定している。具体的には、下記の変更である。
これらが発生すると、接続されているすべてのUEがHOすることになるため、AMFやCUへの信号量が非常に大きくなることが想定され、さらなる検討が必要である。
※SRIが断検出した場合にも、同様に非常に大量のUEの信号が押し寄せて輻輳しそうなので、何らかの対策は必須そう
8.3.6.1 Architecture option with gNB on board satellite
NGインタフェース変更による高負荷を軽減するため、下記の様なソリューションも考えられる。
- 衛星に、論理的に分かれたgNB1,gNB2を搭載する
- gNBは、gNB1-AMF1,gNB2-AMF2とそれぞれ異なるAMFと接続している
- gNB1、gNB2はリソースを共有し、gNB間のやりとりも可能
このような実装であれば、ハンドオーバ手順の一部を省略することや、都度AMFとgNB1,gNB2がやりとりせずとも、AMF→gNB1→gNB2のようにUE Context Updateが可能になる。
※ので、HO時のC-plane信号量を軽減できるかもね、というお話か
その他、AMF reallocationを用いるという手もある。
参考：https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-502_c.html
※gNBが予めsourceAMF→targetAMFにHOするイメージ？
ただし、これらは負荷軽減策の一例過ぎないので、その他にも色んな実装が考えられる。
8.3.6.2 Architecture option with gNB-DU on board satellite
前項はgNB全体が衛星に搭載され、NGインタフェースが変更になる場合であったが、
本項はgNB-DUが搭載され、F1インタフェースが変更となる場合を考える。
こちらも同じように、F1インタフェース変更による高負荷を軽減するため、下記のようなソリューションが考えられる。
- 衛星に、論理的に分かれたDU1,DU2を搭載する
- DUは、DU1-CU1,DU2-CU2とそれぞれ異なるCUと接続している
- DU1、DU2はリソースを共有し、DU間のやりとりも可能
このような実装であれば、ハンドオーバ手順の一部を省略することや、都度CUとDU1,DU2がやりとりせずとも、CU→DU1→DU2のようにUE Context Setupが可能になる。
※前項とほぼ同じソリューション
具体的なCallFlowを見ていく。
通常のInter-gNB-CU HandoverのCallflowイメージは下記。
https://blog.3g4g.co.uk/search/label/inter-gNB-CU%20Handover
Inter-gNB-CU Handoverの具体的なCallFlowが3GPP TSに見つからなかったので、
参考までにInter-gNB-DU HandoverのCallFlowは下記。
提案では、UE Context Setup Request/Response手順ををXn HO requestに含まれる情報や、DU1-DU2間のリソース共有により、省略できるとしている模様。
※これでどれだけの削減になるのか、シミュレーションとかしないと定量的には感じ難いかも
8.3.7 Summary
8.3章の内容をまとめると、下記表となる。
- 透過型
- 再生中継型（gNB一部搭載）
- 再生中継型（gNB全部搭載）
- ISLを伴う再生中継型
- リレー（≒IAB）型
※適用可能（標準上の影響なし）か、適用できないしかないので、パラメータどう工夫するかはここでは言及なし。とりあえず、考えられるHOパターンを列挙してみた感じ。
