追本溯源-RAN3 ＃91bis和 ＃92会议 关于CU/DU分离的讨论内容摘录

RAN3 #91bis和#92会议关于CU/DU分离的讨论内容摘录

1.  RAN3 #91bis会议综述

1.1.     明确了CU和DU的概念

RAN3 #91bis上明确了CU和DU的概念(Intel提案)，CU="central unit"，DU="distributed unit"。

1.2.     明确了CU和DU分离的好处

对于RAN内部分割的好处，AT&T的提议(R3-160670提议/R3-160989修改)讨论后被采纳，至今TR38.801中仍是如此描述。如下所示(参考TR38.801 V2.0.0 2017-03版本)：

中央单元和分布单元进行切分可以带来以下好处：

各种场景下都可以通过灵活的硬件部署节省成本。

CU/DU分离架构可以实现性能协调、话务管理、实时性能优化以及NFV/SDN。

可配置的功能分割可以适应于不同场景，如传输时延变化等。

1.3.     明确了CU和DU分离的7种方式

对于CU和DU分离的方式，讨论后通过了Samsung讨论提出的7种分割方式的提案，形成了38801-010的7种切分方式的基本内容。

2.  RAN3 #92会议综述

在7种分割方式的基础上进一步对优劣进行分析，并新增第八种切分方式，奠定了后续8种切分方式的雏形。

2.1. 7种方案的分析和评估

会议同意Deutsche Telekom AG, Orange, T-Mobile US, Telstra, SK Telecom等公司提出的根据传输时延和传输带宽来考虑切分方式的提议。

NTT Docomo提议从传输时延、带宽/抖动、小区间协调、接口复杂性、RAN功能分离、前向兼容性、其它产品特性以及资源池的好处等方面对各种方案进行评估，并对选项2、5和7进行了分析比较和评估。

2.2.     增加第8种分割方式(Intra-RLC)

在RAN3#91bis确定的7种提案的基础上，进一步讨论了各种方案的特点，并采纳了中国移动提出的Intra-RLC的第8种切分方式。

中国移动在R3-161269 Additional function split option for CU-DU中提到，RLC可以分为高层和低层2部分。高层可位于CU中，低层可位于DU中。比如，高层RLC包括TM RLC实体的发送、UM RLC实体的发送以及AM实体的发送等。低层RLC包括TM RLC实体的接收、UM RLC实体的接收以及AM实体的接收等。另外，AM RLC实体的路由(Routing)功能也位于DU中。

值得一提的是，LG的提案R3-161150也提出了这种切分方式，不过由于没有现场讨论，所以3GPP会议纪要中没有提及。R3-161150 Consideration on RAN internal functionssplit中，LG公司认为，功能单元位于CU还是DU中取决于它和无线环境的关系。如果和无线环境关系比较大，则应当位于DU中，反之则应当位于CU中。如Segmentation和Concatenation功能以及HARQ功能都应该放在DU中，而头压缩和加密/完整性等功能，可以放入CU中。并且基于此考虑，提出RLC内部切分的方式。

另外，本次会议上华为提出了RRM和RRC切分的第8种方案(R3-161141)，建议将RRM放在CU中，其余等协议层放在DU中，不过未加讨论。

2.3.     未处理方案关键信息摘录

RAN3 #92中部分提案没有讨论和处理。

      其中，Samsung(R3-161066)提出了根据Feature的支持性、前传上是否有大量信令、UP协议是否变化、前传带宽和时延的评估方法，并对7种选项进行了分析和比较。

Intel(R3-161072)在系统参数假设的基础上，提出了复杂的吞吐量核时延的分析模型。假设参数包括带宽、天线数、TRX数、MIMO层数等。模型中则涉及接口时延、开销和评估方法等内容。大致描述如下：

Nokia和上海贝尔公司在R3-161097和R3-161098中认为时延、带宽、可扩充性、接口复杂性等是主要考虑因素。并据此区分高层分割(MAC层之上层2内部切分，即1~4)和底层分割(MAC层之下层2和层1之间或者层1内部，即5~7)。同时，认为高层(L2内部)分割需要考虑实时(RT)和非实时(NRT)操作。对于高层分割的各种选项，需要从信令(CU-DU间信息交换频度)、UP相关概念、接口复杂性、多连接和CA特性、协议开销、处理需求、确认魔术处理、QoS、安全概念、clean协议分割、移动影响等方面进行评估和分析。

另外，NTT Docomo在R3-161192中、ZTE在R3-161220中、Fujitsu在R3-161263中、CMCC在R3-161271中也都提到了各类评估方法，详情请参考原提案。

另外，RAN功能的灵活性方面也有一些提案，比如Nokia和上海贝尔公司提出(R3-161099)，RAN功能应当考虑部署方面的灵活性和业务支持方面的灵活性。

NTT DOCOMO, INC., KT, Softbank, TIM, Ve