基于数据面加速器的工业5G协议处理架构研究①

2023-11-20 08:36杨喜宁周一青
高技术通讯 2023年10期
关键词:加速器解密数据包

杨喜宁 周一青 陈 洋

(中国科学院计算技术研究所处理器芯片全国重点实验室 北京 100190)

(中国科学院大学 北京 100049)

(移动计算与新型终端北京市重点实验室 北京 100190)

0 引言

为了应对未来爆炸性的移动数据流量增长、海量的设备连接和不断涌现的各类新业务和应用场景,第5 代移动通信技术(5G)应运而生[1-2]。不同于之前的移动通信技术,5G 网络的服务对象从传统的人与人通信拓展到人与物、物与物通信,5G 将开启一个万物互联的新时代,渗透到工业、交通、农业等各个行业,成为各行各业创新发展的助推器[3-4]。支撑如此广泛应用的基础是5G 的几项核心指标,如1 Gbps的用户体验速率、面向小包通信时毫秒级的端到端时延以及99.999%的传输可靠性[5]。不断增长的信道带宽、算法复杂度和更低处理时延对于成本、计算资源和功耗体积等受到严格限制的终端设备来说是一个巨大挑战[6]。

基带芯片(又称Modem)作为5G 终端设备的核心器件,对终端设备的通信功能和性能起着决定性的作用。因其复杂的数字信号处理算法和强实时的处理时延需求,通常基于软硬协同的异构SoC(systems-on-chip)来实现[7-8]。基带芯片包括基带信号处理和协议处理两大部分。基带信号处理广泛采用基于ASIC(application specific integrated circuit)的硬件加速器来实现,并且学术界已有大量针对性的研究[9-11]。文献[12]提出一种数据流驱动的可编程软核处理器,可以满足5G 对FFT(fast Fourier transform)/IFFT 在灵活性和实时性方面的需求。文献[13]设计一种动态可伸缩的多核SoC(MPSoC)来满足5G 信号处理在吞吐率和时延指标方面跨越几个数量级的动态范围,以提升芯片资源利用率。文献[14,15]分别对5G 下行同步算法和LDPC(lowdensity parity-check)译码算法展开了基于硬件加速器实现方案的研究。

但是对于协议处理,如高层用户面层2(L2,layer 2),主流的基带芯片[16-17]仅提供加解密和完整性保护校验的硬件加速功能,对协议处理的硬件加速和软硬协同设计的研究较少。文献[6]提出一种基于加速器处理架构,主要是针对LTE(long term evolution)协议的软硬件联合处理,取得了一定的性能增益。然而,随着5G 的广泛应用,尤其是在工业领域,除了高带宽外,时延、可靠性和低抖动等方面的要求也在不断提高,用户面协议处理逐渐成为了制约基带芯片总体性能的新瓶颈[18]。协议处理主要面临以下挑战:首先,5G 协议支持多种调度时隙间隔,最小可到0.125 ms,在如此小的时间约束内要进行大量包的实时处理,基于多任务的纯软件协议处理架构难以保证时延稳定,而这恰是工业5G 应用的一个重要需求;其次,为了提升有限的无线空口资源的利用率5G 协议中所有层的协议头字段大多以比特为单位定义,CPU 软件访问这种非字长对齐的数据时效率比较低;此外,5G 协议中承载业务数据的逻辑信道配置参数及各层的头格式种类繁多,计算字段前后依赖,只能顺序解析动态识别后续字段的格式,这增加了解析的难度。传统以CPU 软件为主的协议处理架构无法满足高能效比和可预期的稳定性时延[19]。

在此背景下,本文设计了一种基于软硬件协同的协议栈处理器架构,利用硬件加速器卸载耗时处理减轻CPU 压力,在提升5G 协议栈用户面吞吐率的同时降低处理时延和抖动。本文的主要贡献如下。

(1)提出一种软硬协同的5G 协议处理架构,充分利用异构芯片资源,对软硬件功能进行了合理划分,减少软硬件之间的通信开销,提升系统的执行效率。

(2)设计针对5G 协议的数据面加速器(data path accelerator,DPA),将用户面协议中频繁执行且比较耗时的协议数据解析功能从传统的软件处理中独立出来,在降低CPU 负载的基础上,提升用户面的包处理速率。

(3)采用DPA 与安全加速器(security,SEC)联动设计,在极少CPU 干预的前提下实现协议数据解析和解密操作的无缝衔接,保证了数据包处理时延的稳定性。

论文的其余部分组织如下:第1 节介绍了本文提出的软硬件协同的协议栈处理架构;第2 节详细描述了软硬件协同的协议处理架构中的核心器件数据面加速器(DPA)的设计细节和并行化策略;第3节为实验设计与性能验证分析;第4 节对论文进行总结。

1 软硬件协同的协议栈处理器架构

协议处理子系统作为基带芯片中的核心组件之一,主要负责5G 标准高层数据面和控制面协议处理。其系统架构如图1 所示,包括硬件平台和协议软件系统(protocol stack,PS)两大部分。

1.1 硬件平台

硬件平台的核心是一个4 核的CPU,可提供128 Bit 的AXI 总线连接高速DDR 控制器,并通过一个转换桥连接到各个加速器和外设。硬件平台还包括以下部分:

• 数据面加速器(DPA),负责协议栈层2(layer 2)协议数据解析及SEC 加速器控制。

• SEC 加速器,用于安全密钥计算、数据与信令的加密解和完整性保护。在本文提出的架构中,SEC 加速器即可以通过CPU 启动,也可以不经过CPU 直接由DPA 进行启动,以避免频繁中断造成的额外开销。

• 中断控制器和各种外部接口,如PLIC、UART 和PCIe 等。

• UGDMA(uplink gather DMA),控制DMA 执行上行数据的复用与级联操作的专用加速器。

其中DPA 的设计以及DPA 与SEC 加速器的并行化控制是本文研究的重点。

1.2 数据面加速器

为提升工业5G 协议栈处理的吞吐率和硬件效率,本文基于软硬协同设计思想,在对协议栈各层执行时间进行测量和时序分析的基础上(分析结果详见第3 节),对协议栈的软硬件功能进行了合理的划分。具体来讲,本文设计一款专用的协议栈数据面加速器(DPA),把用户面中重复执行、逻辑相对简单且比较耗时的传输块(transport block,TB)各层协议数据单元(protocol data unit,PDU)解析功能从协议栈软件中独立出来。如图2所示,DPA负责用户面下行链路的协议处理,包含2 方面的功能:一是对从物理层收到的传输块执行快速解析和协议字段提取,并将结果中的有效协议字段按照一定的格式(定义为HFD,header field descriptor)按序存入片内高速共享,存储后中断通知CPU 执行用户面L2(Layer 2)各层协议功能;二是在TB 块解析过程,若解析出来的PDU 所属的PDCP(packet data convergence protocol)实体打开了加密完保功能,则DPA为该PDU 配置好相应的算法和解密数据地址等参数,直接启动SEC 加速器执行完整性保护和解密操作。

图2 用户面加速器处理流程

1.3 软硬协同及并行化设计

为提升用户面协议处理性能降低时延,基于DPA 的软硬协同协议处理架构进行了并行化的创新设计。该架构充分利用CPU +AISC 异构资源对协议处理进行了并行化分解,即DPA 进行数据包的解析后将处理结果分发给CPU 和SEC 加速器分别执行协议处理和解密完保操作。传统的协议栈架构通常是以串行的方式对单个PDU 交替执行各层头解析和协议处理、解密等操作。这种处理方式虽然可以借助多核分担各个执行环节形成流水以提升总体吞吐量,但各环节之间交互和衔接也有非常大的开销,而且会增加每个包的处理时延。本文设计的基于DPA 软硬协同架构,则对2 个关键环节的执行时序进行了并行化分解,如图3 所示。

图3 并行化设计

(1)MAC CE(control element)处理与MAC SDU(service data unit)处理的并行化。协议栈收到MAC TB 后,会先依次从中解析出MAC CE 和MAC SDU。MAC CE 如果存在的话会被排布在TB 的最前端[20]。DPA 一旦解析完MAC CE,在立即通知协议栈执行MAC CE 的后续处理的同时可以继续执行其他MAC SDU 的解析。这样可以保证协议栈对MAC CE 的处理与DPA 对MAC SDU 的解析同时进行,因MAC CE 通常涉及底层无线资源集或配置参数的快速切换,尽可能提前处理MAC CE 可为物理层及射频控制争取更多的响应时间。

(2)协议栈RLC(radio-link control)/PDCP 的处理与用户面数据解密完保的并行化处理。当DPA完成RLC、PDCP 和SDAP(service data application protocol)的头解析后,数据流一分为二:一方面DPA通知协议栈执行RLC 分段重组、ARQ(automatic repeat request)和PDCP 丢弃、排序等协议功能[21];另一方面DPA 启动SEC 加速器执行解密和完保验证操作。待SEC 加速器处理完成后中断通知协议栈PDCP,PDCP 按序递交完保校验结果正确的数据给SDAP 进行后续处理。因2 条数据流并行执行,且解密处理耗时较长,因此协议栈完成了RLC、PDCP的相关处理之后,等解密处理一完成就可以递交数据包。通过这种并行设计,可以在解密过程中尽可能多地并行执行其他协议处理任务,进而降低协议栈的总体处理时延。

2 硬件加速器设计

2.1 总体架构

如图4 所示,DPA 主要包括控制单元、数据处理和接口3 个部分。控制单元中定义了DPA 的配置寄存器,包括逻辑信道、PDCP delivery Count 值、HFD 缓存地址信息、输入的MAC TB 数据地址和DPA的控制寄存器等。数据处理单元包括的协议栈各层PDU 解析模块、读写DMA(direct memory access)的控制以及输出FIFO(first-in first-out)操作。接口单元包括独立的时钟、复位和中断信号以及APB(advanced peripheral bus)和AXI(advanced extensible interface)总线。

图4 DPA 硬件架构

2.2 基于DPA-SEC 协同的协议数据流

DPA 与协议栈CPU、SEC 加速器和存储模块(如SRAM/DDR)紧密配合,实现用户面下行业务的高效处理。如图5 所示,以DPA 为纽带的协议数据流处理分为以下4 个阶段。

图5 DPA 数据流

阶段1输出数据准备及DPA 初始化

该阶段包括图5 中步骤1~2,协议栈收到物理层的TB 数据到达中断,对DPA 进行初始化、参数配置后启动DPA。

阶段2DPA 执行协议数据解析并输出HFD

该阶段为图中的步骤3~6,一方面DPA 控制RDMA 循环从DDR 中读取一定长度的TB 数据放入内部输入FIFO。首次读取的长度由协议栈配置,之后每次读取的长度由DPA 根据上一次数据处理的结果进行动态调整,其原则是保证DPA 每次都能从DDR 中读出一个完整MAC sub PDU 的各协议层PDU 头。另一方面,DPA 对输入FIFO 中的数据按照协议格式进行解析,包括MAC CE 和MAC sub PDU 的解析,同时按照设计的HFD 格式(见下节描述)将解析结果通过DPA 内部的输出FIFO 和WDMA(write DMA)写入共享的SRAM,交由协议栈进行后续处理。DPA 支持配置独立的MAC CE 完成中断和MAC SDU 解析完成中断。这样设计的考虑是为了及时优先将MAC CE 处理结果递交给协议栈,以提升MAC 层控制响应的时效性。

阶段3协议处理与SEC 解密并行

本阶段为步骤7~10,包含两大处理过程:一是协议栈基于DPA 的解析结果对各层PDU 进行RLC级联、重复检测和ARQ 操作,以及PDCP 的排序、去重和丢弃等操作;二是DPA 为所有打开了加密和完保功能的PDU 批量准备SEC 加速器需要的解密算法等参数后,启动SEC 加速器执行解密、完保校验操作。

阶段4协议栈按序递交

该阶段为步骤11~12,协议栈根据SEC 加速器处理结果,对完保校验失败的包进行丢弃操作,再按序将经过RLC 层处理并且完保校验成功的包递交给SDAP 执行QoS 流映射操作后转发给应用处理器(AP)。

2.3 DPA HFD 定义

HFD 是DPA 与协议栈之间进行信息交互的数据格式,关系到软硬件界面划分的合理性,对数据传递效率有较大影响。在定义HFD 格式之前,首先介绍一下TB 数据的格式。如图6 所示,每个下行TB中包含若干个MAC subPDU,共有3 种类型: MAC CE、MAC SDU 和padding。其中每个MAC SDU 包含着不同类型的RLC PDU、PDCP PDU 和SDAP PDU。DPA 需要设计合理的HFD 格式来应对标准中控制类、数据类PDU、不同的RLC 模式和SN(sequence number)长度等参数的变化。

图6 MAC TB 格式

为减少各层之间头字段的冗余信息,DPA 的HFD 采用了跨层扁平的格式定义。图7 给出了AM分段PDU、基于RLCUM(unacknowledged mode)的PDCP 控制PDU 和SDAP 数据PDU 这3 种类型的HFD 格式,此外还可以定义出MAC CE 及其他各类型的HFD 共计10 种,可以完全覆盖标准规定的所有协议头类型。以UM_SDAP_DATA 为例,其表示该HFD 是一个非分段的基于RLC UM 信道且带SDAP 头的业务数据包,它只定义了PDCP count 值、SN 等必要信息,而RLC SI(segment indication)和其他协议头中的一些保留字段则被去除,以减少内存占用。

此外,为保证CPU 对HFD 数据的读取速度,HFD 的各个字段长度均按CPU 字长设定,并且将HFD 的输出格式定义为基于静态内存的序列化存储结构,并在HFD 缓冲区的开头指示DPA 从TB 解析出的MAC sub PDU 的总数量,方便CPU 直接快速遍历每一个PDU 的HFD。

2.4 业务数据内存分配讨论

DPA 完成协议字段解析后,最终可以得到MAC TB 中所包含的业务数据(即IP 包)信息。每个TB中包含大量IP 包,并且这些IP 包并非总是按序达到,而PDCP 要保证按序递交,因此协议栈不得不先缓存这些IP 包,这就涉及到内存分配的问题。最直接的做法是为每一个IP 包单独分配内存,这要求DPA 加速器实现一个内存管理功能,这不仅增加了设计复杂度也会导致加速器与CPU 之间共享内存竞争访问的问题。本文采用一种改进的方法,在DPA 启动之前就由CPU 预先分配好足以容纳MAC TB 中所有业务数据包的大块内存空间(称其为业务缓存),DPA 只要计算每个IP 包的内存偏移并将其存入HFD 中,CPU 中的PDCP 任务按序递交一个IP包后标记其释放状态,待所有业务数据包均被递交后,回收业务缓存。该方案大幅减少了内存分配的次数,可以提升协议数据处理速率。

3 仿真结果分析

3.1 工业5G 业务模型分析

为验证工业5G 不同业务模型下协议栈对处理资源的占用情况,本文基于课题组研发的5G 协议栈搭建了软件验证环境。如图1 所示,traffic config模块可以根据需求配置不同的业务参数,本文中定义了高频次小包和大带宽2 种典型的工业5G 业务场景,并利用物理层模拟器(PHY emulator)生成不同业务场景的MACTB 包并发送给协议栈(L2)进行处理,同时对协议栈处理时间进行测量统计。如图8所示,在每个调度间隔内数据包数量不变(如108包/TTI)的情况下,随着数据包增大,层2的总处理时间(L2 time)及各部分的处理时间增长平缓,带宽增加40 多倍的前提下,协议栈用户面的处理cycle数仅增加不到2 倍。而如图9 所示,对于高频次小数据业务(如500 包/TTI),在业务带宽仅增加10 倍的情况下,协议栈层2 的处理cycle 数增加了约10 倍。这说明协议栈用户面对数据包的数量比较敏感,工业5G 高频次小包的业务特点严重制约协议包处理吞量。

图9 不同小包数量处理性能

3.2 软硬协同协议处理架构性能分析

为验证本文设计的基于软硬件协同的协议处理架构,开发了5G 用户面协议处理加速器DPA 和SEC 加速器,并基于EDA 搭建了软硬协同验证环境,其功能组成如图1 所示。本节将从时延、时序、包处理通量等方面对DPA 及本文提出的协同架构进行性能分析。验证环境中CPU 的时钟频率为1.2 GHz,SEC 加速器、DPA 加速器的时钟频率为500 MHz。

3.2.1 时延和时序分析

首先基于软硬协同的验证环境,对协议栈下行业务数据处理进行时延分解和时序分析。每个调度周期,下行空口数据经过物理层的处理后生成一个MAC TB 包,经过协议栈的处理将TB 包中的业务数据解析、解密,再按序递交给AP。

如表1 所示,基于64 字节包长和每个调度间隔(TTI)500 包的业务负载对纯软件处理和软硬协同处理(下文简称协同架构)2 种方案进行了模块级的处理时延量化分析。其中Interrupt Delay 代表的是MAC/PHY 以及SEC 加速器与CPU 之间的中断开销,DPA Setup 代表CPU 软件配置并启动DPA 的处理时延,PDU Parser 代表使用软件方案实现DPA 功能的处理时间,MAC-RLC-PDCP1 代表协议栈MAC、RLC 以及PDCP 丢弃、排序功能的处理时间,PDCP2-SDAP 代表PDCP 根据完全校验结果进行数据包递交处理的处理时延,Decipher(AES)代表基于AES 解密算法的SEC 加速器对数据进行解密处理的时延。需要特别说明的是,软件方案和协同架构中的解密操作均通过硬件加速器完成。另外,由于协同架构中采用了并行化处理,因此总处理时间将以并行路径中执行时间较长的路径来计算,根据计算结果可知使用软硬件协同的方案处理时延可以降低28.3%。

表1 时延分析

如图10 所示,DPA 采用的并行化设计,使得DPA 完成协议数据解析后SEC 解密操作与协议软件处理并行进行,相对于串行处理方案,其总体执行时间可以下降48.1 μs。

图10 不同小包数量处理性能

3.2.2 包处理通量分析

本文将包处理通量定义为每个TTI 内可以处理的包数量。如图11 所示,通过对每个TTI 内不同包数量业务负载的测试,对比软件方案和协同架构的性能结果发现,业务负载越大,协同架构的性能提升增益也越高,处理性能平均提升38%。另外若将协议处理时间约束限制在200 μs 内,协同架构的包处理通量提升了约67%,高达1000 包/s。而对于工业5G 网络0.5 ms 的时隙周期配置,协同架构的包通量大于2000 包/s,可以满足工业5G 大规模现场节点集中式数据采集的需求。

图11 处理时延对比分析

3 对比分析

基于对协议栈数据流的分析和并行化处理架构研究以及DPA 硬件设计的成果,本文在SMIC 的12 nm工艺节点下实现了DPA 加速器,工作主频为500 MHz。因与CPU 及SEC 加速器共享外部SRAM存储,DPA 加速器内部不包含数据存储单元,其核心单元面积仅约为0.014 mm2,具有较好的硬件效率。另外,本文将软硬协同的架构与文献[19]中的以sDMA 加速器为核心的架构进行了性能对比。为保证对比公平,将本文协同架构中的CPU 主频与加速器主频分别归一化至sDMA 方案中的500 MHz 和200 MHz,并且采用与sDMA 中相同的SEC 加速器性能指标,业务负载统一设定为1 Gbps 吞吐率。对二者下行用户面软硬件总体处理时延进行测量后发现,本文基于DPA 的软硬协同架构总处理时延为623.3 μs,相对于sDMA 的1600 μs,性能提升大于50%。这主要得益于协同架构中SEC 解密与协议处理的并行化实现,以及软硬协同架构合理的软硬件划分和高效的时序控制流程。

4 结论

本文面向工业5G 协议处理器架构展开研究。针对工业应用在吞吐率、时延和包处理通量等性能指标方面对5G 基带芯片协议处理带来的挑战,本文提出一种软硬件协同的协议处理架构。首先,对该架构的硬件组成、数据面加速器功能进行了总体介绍,并重点分析了软硬协同的并行化设计思路。该架构对协议处理的软硬件功能进行了合理划分,将用户面协议中重复执行、逻辑相对简单且比较耗时的协议数据解析功能从软件中独立出来,使用DPA 来实现。接着,本文从硬件设计、DPA-SEC 加速器协同执行流程和HFD 定义3 个方面对DPA 加速器进行了详细的设计分析,并讨论了DPA 在内存管理方面的改进。最后通过搭建系统级的验证环境对本文提出的协议处理架构进行了性能分析。实验结果表明,软硬协同的处理架构利用硬件加速及并行化等手段,在不同业务负载下,相比纯软件的实现方案,协议总体处理时延平均下降28.3%,包处理通量平均提升38%;在0.5 ms 的时隙周期配置下,协同架构的包通量大于2000 包/s,可以满足工业5G 大规模现场节点集中式数据采集的需求。本文的研究成果对业内5G 基带芯片协议架构设计具有一定的借鉴意义。未来研究重点是进一步探索高层协议栈中排序、复用等其他功能基于硬件化实现的可行性和实现方案。

猜你喜欢
加速器解密数据包
莫比斯加速器众创办公空间
知识快餐店 科学加速器
全民小康路上的“加速器”
炫词解密
解密“一包三改”
炫词解密
SmartSniff
解密“大调解”
视觉注意的数据包优先级排序策略研究
移动IPV6在改进数据包发送路径模型下性能分析