5G系统RAN架构

- CU(集中单元)和DU(分布单元)的应用和功能切分方式 (下)

- 3GPP中CU/架构分割结论及RAN3 #95bis会议概览

2017年4月3号到7号在美国华盛顿Spokane举行的RAN3 #95bis 会议上，对CU/DU高层逻辑分离架构形成了最终决议，即R15阶段高层分割采用选项2，也就是将PDCP/RRC作为集中单元并将RLC/MAC/PHY作为分布单元。

本次会议上，实际上对选项2和选项3-1的讨论提案并不多，更多地是集中在CU与DU之间的接口和数量关系等方面。本文对会议信息进行一些摘录，供大家参阅。

1. CU/DU高层功能分割的最终决定

2017年2月份举行的RAN3 #95会议上，已经基本确定CU/DU高层分割采用选项2或者选项3-1，并提交RAN #75全会予以通过了。而RAN3 #95bis会议则明确确定了选项2的方案。结合2次会议的结论描述如下。

1.1  RAN3 #95和RAN #75会议上CU/DU分离架构的基本结论

2月份举行的RAN3 #95会议上的讨论结果如下：

• 在Stage 2/3阶段将设定一种高层分离方案。目前推荐考虑选项2(即PDCP/RLC分离模式)，最终在4月份决定。选项3-1(即RLC内部分割)比较难以实施。更底层的分离目前没有讨论完成，需要往后推延。L1分离的时间表没有达成一致意见。

  
  

• 采用PDCP与RLC分离的CU-DU方案，是考虑到LTE种双连接3C模式就是采用的PDCP与RLC分离的方式，且已经标准化了，所以便于实现。另外，LTE-NR紧密互操作模式与CU-DU分割采用相同的模式，在未来LTE向5G迁移(migration)过程中用户面有好处。(详见R3-170902)

随后在3月份举行的RAN#75全会上的结论如下(详见TR38.801 v2.0.0)。

1.1.1  高层分割

在未来的stage2和stage3阶段还将研究此项工作。但是如果没有其他决定，就将接受RAN3的建议，高层RAN架构分离就考虑选项2。应当限制4月份会议上有关选项2和选项3的提案，以集中在RLCPDU丢失时的重传分析上。如果不能达成协议，则将进行正式的举手表决(vote)，以便在2017年4月份对选项2和选项3-1达成决议。

       不过，对其他选项的标准性提案也是欢迎的)。

1.1.2  低层分割

RAN架构的低层分割的研究工作没有完成，需要延后进行。

需要进一步对低层分割方案、可行性、切分方式选择等进行评估，并且进入规范阶段之强，需要基于NR进行技术优势的对比分析。

研究阶段(SI)的讨论结果表明，选项6和7更受赞成。

1.2  RAN3 #95bis关于CU/DU高层功能分割的最终决定

对于CU/DU高层分离模式选择问题，4月份举行的RAN3 #95bis会议上并没有进行太多相关讨论，但从RAN3给RAN2和SA的通知信息可以了解RAN3对于高层功能分割的最终决定(R3-171306)。

“对于CU和DU之间的高层功能分割的决定，RAN3诚恳地告知RAN2和SA3，RAN3已经决定选择选项2作为R15的标准化工作。选项2将PDCP/RRC作为集中单元并将RLC/MAC/PHY作为分布单元。RAN3同意在R15中对选项2进行增强，以解决(DU间切换导致的)丢包的快速集中重传问题。某些增强可能对RAN2产生影响，所以需要RAN2的合作和参与。RAN3将及时将这方面的进展告知RAN2，并衷心请求RAN2和SA3考虑上述信息”。

2. RAN3 #95bis关于高层功能分割的讨论过程

本次会议上对选项2和3-1的提案并没有多家讨论，更多地是对CU和DU的从属关系、CU与DU间的数量关系、CU与DU之间的接口及功能、DU内部功能分布、CU和DU间时延等内容进行了讨论。摘录部分提案内容如下。

2.1 CU与DU之间的从属关系

R3-171003 CU-DU interface: Relation between CU and DU (NTT DOCOMO INC.)

CU和DU是类似LTE双连接中SeNB和MeNB的水平关系(“horizontal relation”) , 还是类似3G中RNC和eNB之间的垂直关系(“verticalrelation”)？

会议讨论认为，CU与DU之间应该是垂直关系，一个实体对另外一个实体有所控制。

2.2  CU与DU之间的数量关系

2.2.1 R3-171225   Further Consideration on CU-DU architecture(Huawei)

讨论CU是否被CN可见的问题。选项1是CU和DU是gNB的内部单元，NGC仅看见gNB号，gNB之间采用Xn接口，此接口上CU号的DU号也不可见。选项2是CU互相可见，NGC也能看见CU，CU之间采用Xn接口，且此接口上CU号可见。提案建议RAN3讨论CU-DU架构，并且无论在CU和DU之间接口上还是CU和NGC接口上，DU都不可见。

同时提议CU可以控制多个DU，但一个DU同时只能连接到一个CU。一个DU管理多个小区，但每个小区只能被一个DU管理。

会议讨论认为，小区管理的含义不明确，需以后研究，对于小区能否跨DU也没有决定，需与RAN1/2讨论决定。

2.2.2   R3-170990   Analysis on function split between CU and DU (CATT)

CU可以提供用户面和控制面接口，一个CU可以连接到多个DU，而每个DU只能连接到一个CU。基于此考虑，提案提供了RAN内部架构，并对集中部署下CU和DU的功能进行了描述和划分。

2.2.3   R3-171099  Discussion on principles of the Fs interface (Qualcomm)

高层CU和DU之间采用Fs-H接口。关于CU和DU的关系，认为一个gNB包含一个HL-CU和多个HL-DU，每个HL-CU可以控制多个HL-DU，每个HL-DU受一个HL-CU控制。

gNB内部结构核心网和其他gNB以及UE都看不见。一个HL-DU可支持多个小区，但每个小区只能连接到一个HL-DU。

2.3  CU与DU之间接口及功能

CMCC在R3-171086 中提到，CU和DU之间接口上需要传送控制面和用户面信息(过程)。（提案中有具体的过程和消息类型描述）。

Interdigital Asia LLC在R3-170953中提到，CU与DU之间接口之前名称为Fs，建议采用Xr或者Xg命名。建议CP采用SCTP/IP协议，其它项FFS；UP采用GTP-U/UDP/IP，其它选项FFS。

LG在R3-170954中提到，应当开放Fs接口，Fs接口应当支持信令信息交换和数据转发，Fs接口应当支持CP和UP分离，Fs接口应当区分无线网络层和传输网络层。会议讨论认为CU的polling功能和flex概念有待以后讨论(FFS)。

Nokia上海贝尔以及KT在R3-170956中提到，Fs接口所需的规范，从38.4x1到4x5，分别对应层1、信令传输、应用协议(AP)、数据传输、接口用户面协议等。Fs-C基于SCTP/IP，Fs-U基于GTP-U/UDP/IP。修订版本见R3-171362。

NTT Docomo在R3-171004中提到，在Fs接口上，控制面Fs-C允许CU和DU协商Fs接口管理、无线资源管理以及系统消息管理等，用户面Fs-U进行CU和DU之间用户信息(DTCH)的传送，以及CU和DU之间的RRC消息的传送(如PCCH、CCCH和DCCH)。会议讨论认为，RRC消息是通过CP还是UP或者二者都可以，有待进一步讨论。

NTT DOCOMO在R3-171001中提到，CU-DU接口上C平面的功能描述。包括接口管理、小区配置管理、系统消息管理、UE/承载上下文管理、无线资源管理、UE移动性管理以及测量报告等。

3.  RAN3关于高层功能分割的其它决议

1)    在RAN3第二阶段中，CU-DU架构和F1接口功能在TS 38.401中描述。

       TS 38.401   架构描述包括阶段2功能描述           R3-171362

CU与DU之间的接口命名为F1。

F1-C基于SCTP/IP协议，F1-U基于GTP-U/UDP协议。F1-C功能：F1接口管理(建立/复位/错误指示过程)、系统消息管理、F1接口上 UE上下文管理(待研究)、承载管理、RRC消息传送等。

F1-U功能：用户数据传送和流量控制等。

2)    F1接口上引入6个新规范。规范名称及相应的提案名称如下所示。

4.   RAN3关于高层功能分割的遗留问题   (R3-171362)

R3-171362中提议在新的TS38.401中增加以下有关F1接口的问题：

(FFS - for future study)

- FFS：如何对丢包进行重传。

- FFS：CU-DU分割带来的额外控制面时延及解决方案。

- FFS：gNB-CU和gNB-DU的命名和定义。

- FFS：gNB-CU的SDAP与EN-DC之间的关系。

- FFS：一个gNB-CU可以控制多少个gNB-DU。

- FFS：NR小区号的空间以及小区如何映射到gNB-CU上。

- FFS：一个gNB-DU是否可以连接到多个gNB-CU上(即pooling的概念)以及gNB-CU和gNB-DU的架构。

- FFS：一个小区是否可以由多个gNB-DU来支持。

- FFS：NG接口的终结点(gNB-CU还是gNB-DU)。

- FFS：RRC消息是通过F1-C还是F1-U传送，还是二者都可以。

- FFS：CU内部DU之间的切换和移动性功能是否由承载管理功能来支持。

- FFS：承载管理与2个DU之间同时传送的关系。

- FFS：如何在gNB-CU和gNB-DU之间进行RRM功能的分割和配置。

- FFS：gNB-DU由O&M控制还是由gNB-CU来控制，以及它们对F1接口的影响。

- FFS：如何支持系统消息管理功能。

- FFS：需要明确UE上下文管理功能中的UE context是什么。

- FFS：是否支持上行流量控制。

- FFS：每个功能单元的命名。

- FFS：F1-C和F1-U上是否还需要标准化其他协议栈。

- FFS：下列功能是否需要有待研究。

- GTP-U隧道管理功能

- gNB-DU管理功能

- gNB-DU测量报告功能

- 负荷管理功能

- 寻呼功能

5.    总结

从2016年5月底进行的RAN3 #91bis开始，历经RAN3 #92、RAN3 #93、RAN3 #93bis、RAN3 #94、RAN3 #95以及RAN3 #95bis等会议的讨论，最终确定了5G RAN逻辑架构中CU/DU高层分割的方式，即采用选项2，将PDCP/RRC作为集中单元并将RLC/MAC/PHY作为分布单元。

这种架构将对规范研究、业务性能、网络部署等方面产生很大影响。从以上遗留问题中可以看到，R15阶段将有更多内容需要讨论并标准化，希望通过前几次的总结和讨论能使大家对5G系统中新的RAN云化架构有更深入的认识，更好地学习和了解未来5G网络架构相关的知识。

欢迎关注：5G通信技术