结论：不是标准上"不允许"，而是工程上通常不建。 在再生式 NTN（星上 gNB）架构中，Xn 接口承载在星间链路（ISL）上，而升/降轨卫星之间的跨缝 ISL 因高相对速度、大多普勒、可视窗口极短而难以稳定维持------这与之前讨论 NG 跨缝是同一个物理约束，所以"跨缝 Xn"在主流星座设计中同样一般不被采用。
一、先对齐：Xn 在 NTN 里承载在哪
Xn 是 gNB 与 gNB 之间的接口（含 Xn-C 控制面和 Xn-U 用户面），在 NTN 中的形态取决于载荷
- 透明转发（Rel-17）：gNB 在地面，卫星只是射频转发。Xn 完全是地面接口，"升降轨卫星之间组 Xn"这个问题本身不存在。
- 再生处理（Rel-18/19）：gNB 上星，Xn 直接承载在 ISL 上，用于相邻卫星 gNB 之间的信令交互和切换（satellite-to-satellite handover）
所以"升/降轨之间组 Xn"，实质是问：能否在跨缝 ISL 上承载 Xn-C/Xn-U。
二、为什么跨缝 Xn 通常不建
跨缝 ISL 的物理约束与 NG 场景完全一致：
- 相对速度对穿：LEO 反向缝两侧卫星相对速度约 14--15 km/s，链路可视窗口极短且周期性通断；
- 多普勒频移显著 ：跨缝方向的多普勒远大于同向轨间，这是业界普遍选择不部署跨缝 ISL 的主要原因；
- 邻居关系难以维持 ：Xn 的建立需要预先配置 gNB 之间的邻区/邻居关系（Xn Setup、TNL 传输层可达）。跨缝邻居频繁变化、拓扑抖动，Xn Setup 和 SCTP/GTP-U 隧道会频繁重建，得不偿失。
主流星座（如 Starlink 类 Walker Star/Walker Delta）在反向缝处默认不建链，是公认工程实践。
三、对切换与移动性管理的具体影响
由于 Xn 主要服务切换和 gNB 间协调，跨缝不可用带来的实际问题是：
- 同平面/相邻平面切换：沿同向 ISL 建立 Xn，可以做基于 Xn 的卫星间切换（低时延、UE 上下文转发路径短）；
- 跨缝切换 ：Xn 路径不可达，只能回退到 NG-based Handover （经 5GC 中转，通过各自馈电链路落地），或沿同向 ISL 绕行到对侧卫星后再走 Xn；
- 条件切换（CHO）：LEO 场景本来就广泛依赖 CHO 来应对频繁的星下点变化，跨缝场景下由于目标 gNB 可视窗口太短，CHO 配置也难以精确下发。
四、可行的替代路径
升/降轨卫星之间的 Xn 需求（例如信令交互、用户面数据转发）通常这样解决：
- 经地面中转：两侧卫星各自通过馈电链路落地，Xn 流量经地面网中转（透明架构天然如此，再生架构下退化为 NG-based HO）；
- 同向 ISL 绕行 ：沿同向链路环绕星座到对侧，代价是多跳时延；
- 动态跨缝建链（研究方案）：通过双转盘跨缝天线 + 动态建链策略，在指定建链区内短暂建立跨缝链路------技术上可行，但需要快速跟踪天线，工程上仍非基线方案。
五、一句话总结
跨缝 ISL 难以稳定维持，因此跨缝 Xn 在工程上一般不作为基线设计；
升/降轨卫星各自的 Xn 通过同向 ISL（或地面中转）实现，跨缝的 gNB 间交互退化为 NG-based 切换或地面路径。 前提是再生式架构------如果载荷是透明转发的，gNB 本来就在地面，Xn 完全在地面侧，这个问题就不存在了。