面向超级基站的PDCP层组件式设计与实现*

田永链 ，王凤丽 ， 胡金龙 , ， 袁春经

（1.重庆邮电大学通信与信息工程学院，重庆 400065；2.中国科学院计算技术研究所无线通信技术研究中心，北京 100190；3.移动计算与新型终端北京市重点实验室，北京 100190）

0 引 言

随着移动通信技术的飞速发展，人们对移动业务的需求日益增强，数据流量呈爆发式增长[1]。运营商不得不通过增加基站数量，以满足不断增长的数据流量需求。然而，大量基站带来的能源消耗问题、无线干扰问题变得日益严重，CAPEX/OPEX（资本支出/运维支出）逐年增高。另外，传统无线接入网的“垂直式”架构，导致基站处理资源分配不均、利用率低、资源浪费严重，无法应对现代城市生活方式造成的网络负载的“潮汐效应”。为此，业界提出一种集中式接入网架构，是一种行之有效的解决办法，包括中国移动的C-RAN（Centralized，Cooperative，Cloud RAN）[2]和中科院计算所提出的超级基站[3-5]。超级基站将软硬件松耦合，将基站解耦为四层，包括射频处理、基带处理、协议处理和管理控制。将基站的软/硬件资源进行集中式部署形成大规模资源池，对基站资源进行统计复用共享，实现资源按需动态分配和部署。此外，超级基站的通信软件设计不单单支持一种制式，而是能支持多种通信模式，具有多模可重定制功能，即实现能够根据网络需求自组织、自生成相应的协议软件。为此，针对协议软件的设计，提出了一种模块化的设计方法。该方法不仅体现在协议软件各层之间的解耦合，还包括层内各功能模块之间的解耦合，以此根据不同网络需求，灵活配置和组合以兼容多种制式协议，并能够实现功能模块的替换和制式间的切换。

PDCP层位于LTE协议栈层2的最高层，在控制面和用户面都有相应的协议处理功能，是超级基站协议栈的重要组成部分。本文将以PDCP层为例，研究超级基站的模块化设计思想。传统的PDCP层设计通常采用静态架构，每一种制式对应其特有协议流程，能达到相应功能和性能的要求。但是，它的业务处理流程固定，不能兼容多种制式，对制式改变和模块替换的支持灵活度低，不能做到通过一种制式的PDCP层设计稍加变动演变成支持其他制式的PDCP层，不满足超级基站支持同一平台兼容多制式的需求。

因此，本文针对PDCP现有设计的问题，结合基站协议栈多模共平台的特点，提出了组件化的设计方案。主要贡献：使PDCP层在满足功能和性能需求的情况下，更注重灵活性，能够根据不同网络需求，自组织、自生成相应的协议流程。本文的组织结构如下：第1小节介绍PDCP层架构，第2小节介绍PDCP组件化设计方案和实现，第3小节进行仿真实验。仿真结果表明：本文提出的组件式设计方案，能支持功能组件的灵活替换、删除和扩展，自组织、自生成相应协议流程，满足超级基站多模共平台的需求。

1 PDCP层架构

PDCP位于LTE协议栈层2，其上层是RRC层和GTP-U，分别对应控制面和用户面，其下层为RLC层[6-7]。在基本操作方面，PDCP层的作用非常简单。对于下行链路，只是将PDCP报头添加到输入数据并转发到下层；对于上行链路，将PDCP报头移除并转发到相应的上层。但是，如果启用了完整性保护/验证、加密/解密、头压缩/解压缩等各种附加功能，对于其控制面，PDCP需要对信令数据进行完整性保护/验证、加/解密和PDCP序列号维护。对于用户面，PDCP需要对IP数据包进行头压缩/解压缩、加/解密和PDCP序列号维护，则PDCP可能会非常繁忙。而5G支持双链接（分离承载）增加了路由和重排序功能，PDCP层变得更加繁忙[8-9]，如图1所示。

2 PDCP层设计与实现

2.1 PDCP层设计

PDCP的组件式设计方案，使各功能组件功能独立，具有高封装、低耦合性，即替换即用的特点。需要考虑以下四个问题。

2.1.1 组件划分

组件划分的目的是将整个PDCP层解耦和，为后续的操作奠定基础。常见的划分方式包括：以使用方式为单位划分，包括静态和动态两种方式；以层次结构为单位划分，每一层划分为一个组件；以功能为单位进行划分等[10-11]。划分时，应充分分析其特点，因为如果组件划分粒度太大，组件就越少，各组件间的相关性、耦合性就会增加，不利于各组件的替换、更新。如果组件划分粒度过小，则组件会越多，组件管理也存在一定复杂性。在该部分设计中综合分析LTE与5G PDCP层多模制式的协议流程的相同点和不同点，考虑组件划分的粒度。通过分析以功能为单位进行组件划分，构成支持不同协议流程的功能库，具体内容如下。

图1 PDCP功能视图

头压缩/解压缩功能库：负责实现相应的IP头压缩和解压缩功能。

加/解密功能库：负责实现各加密和解密算法，对数据进行加解密处理。

完整性保护/验证功能库：负责实现各完整性保护和完整性验证算法，对数据进行保护和验证处理。

加/去头：负责构成LTE和5G PDCP相应PDU格式。路由：负责对双连接技术的分离承载的路由。重排序：负责对双连接技术接收路由数据后的重排序。

每个功能库里还可具体根据有无此功能，或此功能涉及的不同算法分为不同的功能组件，具体包括有无头压缩/解压缩组件、EEA0EEA1EEA2加解密组件、EIA0EIA1EIA2完整性保护/验证组件、加/去LTE 5G头组件、有无路由组件和有无重排序组件。

2.1.2 库方式

库一般分两种：静态链接库和动态链接库。两者的区别在于，静态链接库对函数的链接是在编译阶段，即编译时，编译器会把用到的函数全部链接到一起编译成可执行文件，占用内存大，且每次很小的改动都会导致整个程序全量更新，要重新编译整个工程。而动态链接库是在程序运行时才将相应的库函数链接载入。在运行时间上，动态链接库相比静态链接库慢，但随着计算机的发展，差异已经不明显。动态库方式可以支持分离编译，每次变动只重新编译其相应的功能组件，灵活性好。本文结合组件式设计的特点，选用动态库方式对各功能函数进行编译生成可执行文件，可以随时添加、删除、和扩展库文件，为支持不同制式的协议共平台奠定基础。

2.1.3 组件间通信方式

为了满足灵活性，打破了原本PDCP层内功能的耦合性，原本的通信方式不再存在，需要重新设计各组件间的通信方式。为此，通信方式变为：各功能库采用总线式的业务处理结构，独立链接到通信总线上，将整个协议流程串通；相同功能库里的各组件间定义统一的接口，以支持功能组件的替换。各功能库对外的接口是统一的，链接时只需要将该组件库替换为此统一的对外链接库，直观且操作简单。通信方式如图2所示。

假设实现某协议流程需要A、B、C、D四个功能，每个功能还存在不同方式，那么上述通信方式可将其抽象表达为：

目标：协议流程=A+B+C+D

约束条件：

（1）A、B、C、D统一连接到通信总线上。

图2 通信方式

（2）A.1，A.2…B.1，B.2…C.1，C.2…D.1，D.2…属于相同功能库的各组件库之间使用统一接口；不同功能库的组件间不统一。

根据GDT（General Design Theory）理论，将协议流程和功能进行映射。设超级基站有m个流程要求，令PR={PRa,PRb}T={PR1,PR2…,PRm}T。其中，PRa表示基本流程要求，PRb表示自定义流程要求。此m个流程需要n个功能，令FM={FMc,FMd}T={FM1,FM2…,FMn}T，记FMc为必选功能，FMd为可选功能，其数目分别有p、q个（p+q=n），从而定义本文设计的抽象数学模型如下：

其中，功能FM可以由不同算法实现，因此还可以有：

令A为协议功能配置参数。对于不同协议流程，配置其相应功能参数。

具体实例如下：

其中，完整性保护还可表示为以下三种形式之一：

加密也同理。

2.1.4 组件扩展支持多制式协议流程

要实现PDCP协议层对多制式协议流程的兼容，首先要求PDCP协议层能够支持多种制式协议流程下规定的功能。要实现组件扩展，只需要在原来组件的基础上再进行新组件的开发。组件的扩展是支持多种制式流程的基础。组件的划分、动态链接库链接方式、总线式通信方式的设计以及组件的扩展，为支持协议软件能自定义和自生成奠定了基础。通过原协议流程和新协议流程的比较，在进行协议流程自定义前需要先对涉及的功能组件进行自配置，将各个动态库在原协议流程的基础上进行选择是否链接相应扩展组件，以支持多制式协议流程。

2.2 PDCP层实现

具体按以下步骤操作，验证PDCP层具备动态添加、替换、删除相应功能组件，以支持多制式不同协议流程切换。预先将各统一功能库写入makefile；各功能库、各功能组件库路径如果处于默认库搜索路径之外，需要将当前库的路径添加到库的搜索路径之中。切记当库变动时，需要执行/sbin/ldconfig -v命令，再一次重新将库加入缓存。功能库加载流程如图3所示，具体替换某组件还需要进一步通过读取配置文件的配置。

步骤1：准备好预先生成的头压缩/解压缩功能组件库libpdcpCompress.so、libpdcpDeCompress.so和无头压缩/解压缩功能组件库libpdcpNocompre.so、libpdcp NoDecompre.so，加/解密功能组件库libeea0.so、libeea1.so、libeea2.so，完整性保护/验证功能组件库libeia0.so、libeia1.so、libeia2.so，加 /去头功能库 libaddlteheader.so、libadd5gheader.so、libcutlteheader.so、libcut5gheader.so，路由功能组件库librouter.so、libnorouter.so，重排序功能组件库libreorder.so、libnoreorder.so；

图3 功能库加载流程

步骤2：系统加载头压缩/解压缩功能库为libpdcpRohc.so、libpdcpDeRohc.so，完整性保护/验证功能库为libProtect.so、libVeriry.so，加/解密功能库为libCiper.so、libDeciper.so，加/去头功能库为libAddHeader.so、libCutHeader.so，路由功能库为libRouter.so，重排序功能库为libReordering.so；

步骤3：读取配置文件，系统会将步骤1的对应功能组件库拷贝给步骤2对应的功能库，待运行程序，查看数据打印，以验证PDCP层可支持功能组件库灵活替换。

3 实验结果

3.1 运行环境

硬件平台：Intel x86平台；

软件平台：Linux CentOS6.2；

编译环境：gcc。

为了验证本文设计方法可以实现功能库灵活替换，实验使用开源网络性能测试工具iperf，调用Linux下的虚拟网卡tun，自行封装了IP数据包，添加了20字节IP头，8字节UDP头。发送端通过iperf模拟GTP-U/RRC→PDCP→RLC，接收端再通过模拟RLC→PDCP→GTP-U/RRC进行测试。

3.2 运行结果与分析

读取配置文件一，功能库libpdcpRohc.so、libCiper.so、libAddHeader.so、libCutHeader.so、libDeciper.so、libpdcpDeRohc.so会根据配置文件加载 libpdcpCompress.so、libeea1.so、libaddlteheader.so、libcutlteheader.so、lipdcpDeCompress.so组件库。对数据包进行头压缩和加密处理，再进行解密和头解压缩处理，完成DRB数据处理流程。如图4所示，其中⑤解密后数据与③头压缩后数据一致，⑥头解压缩后数据与②收到的数据包一致。

读取配置文件二，功能库libpdcpRohc.so、libCiper.so、libDeciper.so、libpdcpDeRohc.so会 根 据配置文件将原本的组件库libpdcpCompress.so、libeea1.so、lipdcpDeCompress.so替 换 为 libpdcpNocompre.so、libeea2.so、libpdcpNoDecompre.so。增加libProtect.so、libVeriry.so功能库为libeia1.so，而libaddlteheader.so、libcutlteheader.so组件库保持不变，进行加载并实现完整性保护和加密功能，完成SRB处理流程。如图5所示，其中⑤解密后数据与③完整性保护后数据部分一致，⑥完整性验证成功后数据与②收到的数据一致。

图4 DRB处理流程

图5 SRB处理流程

图4 、图5证明了组件式设计方法其处理流程功能的正确性。对于它的性能，通过iperf模拟了不同速率的数据包，对组件式设计、非组件式设计以及组件式设计替换了功能组件后的性能进行了对比，如图6所示。

图6 性能对比结果

由图6仿真结果分析可知，组件式设计相对非组件式设计额外增加了约0.2 ms的时延代价，但最大不超过总时延3%，且随着速率的增大，比值越小，实际工程中可以忽略其影响。可见，所提方法以较小的性能牺牲带来了协议流程能自组织、自生成的灵活性，且仍能满足PDCP层处理要求。

通过上述实验，证明本文组件式设计方法能在满足功能和性能的基础上，支持库灵活替换，自组织、自生成相应协议流程。

4 结 语

由于超级基站协议栈多模共平台的需求，为实现能根据不同网络需求，自组织、自生成相应的协议流程。在PDCP层设计中，除了保证基本的功能和性能要求外，更注重灵活性，提出了组件式的设计方法。通过读取配置文件，加载相应功能组件库，实现整个完整的协议流程。仿真结果表明，本文组件式设计方法能以较低的处理时延代价换来功能库的灵活替换，以支持协议流程的自组织、自生成。未来，可以考虑如何在不停止当前运行程序的情况下，在运行过程中进行相应库的替换，以实现不同协议流程。