1 引言

3GPP中，38.821协议中，研究了如何最大限度地减少对NG-RAN中新接口和协议的需求，以支持非地面网络。
研究了包括透传星和再生星的RAN架构。

2 基于透传星的NG-RAN架构

2.1 概述：

对于透传模式，卫星有效载荷在上行链路和下行链路方向上实现频率转换和射频放大器。它对应于一个模拟射频中继器。
因此，卫星从馈线链路(在NTN网关和卫星之间)到业务链路(在卫星和终端之间)重复NR-Uu无线接口，反之亦然。
馈线链路上的卫星无线链路接口(SRI，Satellite Radio Interface)是NR-Uu口。换句话说，卫星不会终止NR-Uu接口，只是作为一个中继存在。

透传卫星模式的Networking-RAN架构

2.2 架构的详细描述

基于透明卫星的NG-RAN架构如下图所示。

基于透明卫星的NG-RAN的QoS流映射
UE通过基于3GPP NR的无线电接口接入5G系统。

用户数据像往常一样在UE和5GC之间传输，但要通过NTN网关。

来自UE的NAS (NAS- sm和NAS- mm)信令和来自gNB的NG-AP信令被传输到5GC，反之亦然。

2.3 NG-RAN影响

不需要修改NG-RAN架构来支持透明的卫星接入。
NR-Uu时延可能必须延长，以应付支线链路和业务链路的长延迟。
在具有ISL（星间链路）的LEO场景中，要考虑的延迟应至少包括馈线链路(SRI)和一个或多个ISL。
CP和UP协议都在地面终止。
关于CP，这种情况不会造成任何特别的问题，但需要适应UU更长的往返时间。这可以通过实现的方式来解决。
关于UP，除了UP报文的往返时间较长引起的问题外，UP协议本身不受影响。需要注意的是，UU接口上的较长延迟将需要更多的UP数据包缓存到gNB。

3 基于再生星的RN-RAN架构

又区分两种类型，gNB处理有效载荷和gNB-DU处理有效载荷；
gNB处理有效载荷：整个gNB在卫星上。
gNB-DU处理有效载荷：仅有gNB-DU在卫星上。

3.1 gNB处理有效载荷

3.1.1 概述

TS 38.401中描述的NG-RAN逻辑架构被用作NTN场景的基线。
卫星有效载荷实现了从地球接收到的信号的再生。
终端与卫星之间业务链路存在NR-Uu无线电接口
NTN网关和卫星之间的馈线链路通过卫星无线链路接口(SRI)实现。
SRI (Satellite Radio Interface)对于卫星和NTN GW是透传的（也就是作为一个通道）。

注意:卫星可能会搭载超出RAN范围的额外流量路由功能。
卫星有效载荷还提供卫星之间的卫星间链路(ISL)
ISL(卫星间链路)是卫星之间的传输链路。ISL可能是3GPP或非3GPP定义的无线电接口或光学接口。
NTN GW是传输网络层节点，支持所有必要的传输协议。


上图说明了卫星上的gNB服务的UE可以通过ISL访问5GCN。
不同卫星上的gNB可以连接到地面上的同一个5GCN。
如果卫星承载多个gNB，同一个SRI将传输所有相应的NG接口实例

3.1.2架构的详细描述

基于再生卫星的NG-RAN架构如下图所示

下面将介绍用于PDU会话的UE用户平面协议栈。

SRI (Satellite Radio Interface)协议栈用于在卫星和NTN-Gateway之间传输UE用户平面。
像往常一样，用户pdu通过GTP-U隧道在5GC和板载gNB之间传输，但要通过NTN网关。
下面描述用于PDU会话的UE控制平面协议栈。

像地面NR系统一样，NG-AP通过SCTP在5GC和板载gNB之间传输，但要通过NTN网关。
NAS协议也通过NG-AP协议在5GC和gNB之间通过NTN网关传输。

3.1.3 NG-RAN影响

1、NG应用协议定时器可能需要扩展以应对馈线链路的长延迟。
2、与地面网络相比，NG可能会经历更长的延迟(在GEO卫星的情况下，延迟可达数百毫秒)，这将影响CP和UP;这可以通过实现来解决。
3、在具有ISL的LEO场景中，要考虑的延迟应至少包括馈线链路(SRI)和一个或多个ISL之间的时延。

3.2 gNB-DU处理有效载荷

3.2.1 概述

TS 38.401中描述的CU/DU分离的NG-RAN逻辑架构被用作NTN场景的基线。
卫星有效载荷实现了从地球接收到的信号的再生。
在卫星和终端之间的业务链路上存在NR-Uu无线接口
卫星无线电接口(SRI)存在于NTN网关和卫星之间的馈线链路（馈电链路）上。SRI传输F1协议。
卫星有效载荷可提供卫星间的卫星间链接。
SRI(卫星无线电接口)是传输链路;它们传输的逻辑接口F1是基于3gpp协议的。
NTN GW是传输网络层节点，支持所有必要的传输协议。
不同卫星上的DU可以连接到地面上的同一个CU。
如果卫星承载多个DU，那么同一个SRI将传输所有相应的F1接口实例。

3.2.2架构详细描述：

基于再生卫星的NG-RAN架构如下图所示。
PDCP pdu(协议数据单元)通过SRI协议栈进行传输。

下面将介绍用于PDU会话的UE用户平面协议栈。

SRI (Satellite Radio Interface)协议栈用于在卫星和NTN-Gateway之间传输UE用户平面。
用户pdu通过GTP-U隧道在5GC和gNB-CU之间传输。
用户pdu通过NTN网关在gNB-CU和板载gNB-DU之间通过GTP-U隧道传输。

下面描述用于PDU会话的UE控制平面协议栈

NG-AP pdu在5GC和gNB-CU之间通过SCTP传输。
RRC pdu通过F1-C协议栈在gNB-CU和板载gNB-DU之间通过NTN网关通过PDCP传输。F1-C pdu通过IP的SCTP传输。IP数据包通过SRI协议栈、SRI和gNB-CU – NTN网关接口的任何L2/L1层传输。
NAS协议(NAS- mm, NAS- sm)也通过NG-AP协议通过NTN网关在5GC, gNB-CU和板载gNB-DU之间传输。

3.2.3 NG-RAN影响

RRC和其他Layer3处理在地面gNB-CU中终止，并且受到更严格的时间限制。
LEO(近地轨道)系统、GEO(地球静止轨道)中使用这种架构选项可能会影响当前的F1实现(例如定时器扩展)。这种影响对于LEO影响相对较小。
在这种体系结构中，所有与地面NG-RAN节点的CP接口都在地面终止。
关于CP，除了F1AP需要适应SRI更长的往返时间外，这种情况不会造成任何特殊问题。
关于UP，在Xn上运行的实例不受NTN存在的影响，而在F1上运行的实例(通过SRI传输)将需要适应更长的SRI往返时间。反过来，这将需要为进入gNB-CU的UP数据包提供更多缓冲。

3.3 gNB的处理基于类中继架构处理

3GPP描述如何应用IAB (Integrated Access and Backhaul)的架构配置有待进一步研究。

总结

以上是3GPP协议的技术报告中在基于NR协议下对于NTN架构的一些定义和讨论，并不是已有的标准，指示后续的标准大致会按照这个架构去设计。
当前国内的厂商和各种研究所都已经开始设计和开发NTN，基本上都是基于NR协议的，透传星和再生星应该都有公司投入。再生星用的应该基本都是基于gNB处理有效载荷的，gNB-DU处理有效载荷的方案，暂时未听说过有公司采用。

参考文献

3GPP TR 38.874
3GPP TR 38.821 V16.2.0