基于APP650网络处理器加速RNC WCDMA用户平面的解决方案

随着高速分组接入（HSPA）峰值数据速率不断提高，目前主要依靠各种通用处理器（CPU）进行用户平面处理工作的无线电网络控制器（RNC）平台已无法满足日益增加的通信有效负载要求。因此，RNC需要通过新的方法来处理PDCP、无线链路控制（RLC）、MAC以及FP等用户平面无线协议。由于对峰值数据速率要求的提高，以及HSPA用户数量和与WCDMA网络相关流量的增加，RNC需要更快速的HSPA。

本文将介绍如何通过LSIAPP650 Advanced Payload Plus网络处理器来加快当前的HSPA用户平面设计，不管目前的用户平面运行于何种硬件上。通过让APP650接管RLC分段/级联以及重组等用户平面处理工作，RNC可针对小型RLC服务数据单元（SDU）提供100Mb/s以上的用户峰值数据速率，并且可使3万名用户的总吞吐量达到700Mb/s以上。通过使用APP650分担部分处理工作的方法以及高度灵活的RLC（3GPP7版本以上），使每用户的峰值速率吞吐量能达到200Mb/s以上。

蜂窝系统的一个重要要求就是为分组数据业务提供高数据速度。为满足这一要求，3GPP/WCDMA标准R5版和R6版均提出了HSPA标准。尽管3GPP/WCDMA标准R1版就支持分组数据通信，但HSPA进一步增强了性能，可提供更高阶调制、快速的调度以及速率控制等，从而支持更高的每用户峰值数据速率。随着HSPA的不断发展，峰值数据速率也将不断提高。预计3GPP7版本以上的每用户峰值数据速率将提升至200Mb/s以上。

在采用HSPA技术的3G网络中，RNC通常控制数百个基站。RNC负责其控制下各蜂窝系统的呼叫设置和无线电资源管理。WCDMA用户平面协议层包括PDCP、RLC、MAC以及FP等，都是在下行方向上的RNC中启动，和在上行方向上的RNC中终止。

RLC协议层是唯一终止于3G网络用户设备（移动设备）中的RNC用户平面层。所有其它层均只位于RNC与基站之间。

现有RNC平台通常使用多个通用CPU来处理WCDMA用户平面协议栈。随着HSPA的发展以及蜂窝数据速率的提高，现有RNC架构已无法满足WCDMA网络日益提高的通信有效负载要求。

根据摩尔定律，CPU的性能每18个月应提高1倍。根据几份市场研究报告显示，预计对RNC用户平面处理容量的网络需求每12个月将提高约3倍，当前的RNC用户平面处理技术显然无力应付不断发展的需求（图1）。LSI针对这一问题提供了短期和长期解决方案。

本文建议采用的解决方案是将CPU从RLC分段/级联工作中释放出来，从而显著降低当前CPU的工作负载。此前曾将CPU从分段工作中释放出来用于其它协议（如TCP）中，以缩短服务器平台中的CPU周期。本文将介绍类似理念的应用，以加速WCDMA用户平面处理（尤其是RLC协议）。LSIAPP650处理器将CPU从分段/级联以及重组工作中释放出来，支持高达3万用户的RLC连接。图2为几个CPU采用单一APP650处理器作为加速引擎的情况。

相对于通常受限于单核或单线程性能的非加速方案而言，这种加速方案具有明显的优势。以前，提高HSPA峰值数据速率和增加用户（使用典型的CPU和操作系统模型，用CPU进行用户平面处理的用户）数量要求单用户处理软件在多个处理器上并行或管道化操作。这种软件工作方式不仅极其复杂、成本高昂，而且容易出错。与此不同的是，我们可利用LSIAPP650处理器来负责一些CPU工作强度最高的处理任务，从而节约50%乃至更多的CPU处理资源。而且在采用同一硬件时，高峰值数据速率与总体吞吐量将提高一倍以上。

APP650在用户平面处理方面的优势

APP650网络处理器由几个处理单元组成，其中包括模式处理器、流量管理和状态引擎等。

模式处理器主要负责数据包分类，其采用管线化、多线程的多处理器架构。模式处理器的每管线级能在每个时钟周期的不同上下文/线程下工作，这不同于管线中的所有指令必须属于单个上下文且只有上下文暂停（高速缓存缺失、存储器访问、分支预测错误等）时才打开管线中上下文执行的传统通用架构。在传统的单线程架构中，让执行管线保持繁忙比较困难，因为管线中的所有指令都属于单线程。在APP650架构中，如果上下文执行的函数调用时延较高，那么该函数调用在管线中的位置会被分配给其他上下文。因此，APP650多线程架构能支持零周期上下文切换功能，这在单线程的多核架构中是不能实现的。模式处理引擎可提供144个不同的上下文，能全面利用硬件资源，并避免存储器出现时延。

与此形成对比的是，CPU的存储器瓶颈会导致我们难以充分利用资源，而且会浪费CPU的工作周期。APP650网络处理器会为即将到达的数据包分配一个上下文，这样许多数据包能同时处理。由于我们能同时处理许多数据包，这样就能充分利用CPU资源，而且还能实现高达5.9Gb/s的数据速率。

在APP650架构中，机制与策略是彼此独立的。硬件负责提供机制，而软件负责提供策略。APP650架构是在硬件中执行存储器管理与数据移动，因此在牵涉到存储器的分配与释放、数据包指针的跟踪或者数据复制到不同存储器地址等方面时间，不会出现软件消耗资源的问题。APP650硬件就每个数据包调用软件来提供决策，避免了因中断处理或轮询而浪费CPU资源。APP650网络处理器还包括了预排序修改（PQM）引擎，其不仅能在数据包的不同部分中插入或删除数据，而且还可将数据包分段为许多子数据包。PQM引擎的上述特性可显著加速RLC分段/排序进程。另外，APP650网络处理器还有一个重要特性，就是硬件辅助多字段数据包分类。数据包分类可能占用很多CPU资源，但在APP650网络处理器上数据包分类非常高效。

APP650状态引擎提供了跟踪数据包相关状态的机制。在RLC处理中，我们用该引擎跟踪RLC连接状态。举例来说，与每个RLC连接相关的12位序列号都是状态引擎所跟踪的协议状态的一部分。

在APP650网络处理器中，硬件将软件作为子例程调用，就缓冲管理、流量整形/调度和数据包修改提供决策。软件运行在基于超长指令字（VLIW）架构的三个计算引擎上。缓冲管理计算引擎强制执行数据包丢弃策略并保持排序统计数据。流量整形器引擎确定每个队列的服务质量（QOS）和服务等级（COS）处理。流编辑器计算引擎执行协议数据单元（PDU）修改。APP650网络处理器的硬件辅助流量管理支持成千上万队列的确定性流量管理行为，同时还提供了一个框架，通过C编程语言子集进行流量管理算法定制。由于流量管理功能由不同引擎执行，因此分类工作负载不会影响流量管理的确定性。

与此形成对比的是，CPU架构要在支持数据包处理应用的同一处理器池上或在一个单独分配的内核上执行流量管理算法。这两种情况都会造成硬件资源在确定性方面利用不充分。此外，软件程序员还要负责流量管理解决方案开发的各方面工作。APP650架构通过硬件框架消除了上述各种复杂问题，软件程序员只需做出流量决策。

APP650架构的构建使软件开发人员不用考虑硬件多线程和并行处理的问题。因此，APP650架构所需较少的软件编程，相对于现有的CPU无线用户平面解决方案而言能大幅提高吞吐量。

LSI提供了丰富的软件开发环境，包括确保周期精度的仿真器，可用作功能调试和应用性能分析。此外，仿真器工具还能用来确定不同硬件资源的利用。

将CPU从RLC分段/级联任务中释放出来

根据所需可靠性的不同，RLC可分为三种不同的工作模式。我们在本文中只讨论RLC确认模式（AM）。RLCAM模式通过自动重复请求（ARQ）协议来提供可靠的通信。

在RNC下行方向上，发送器执行SDU的分段和级联任务。RLCSDUs可映射至RLCPDUs，发送并置于重传队列中。在不同条件下，发送器可生成状态报告并反馈给对等RLC。状态报告可作为独立的RLCPDU发送，如果有足够的填充码的话，它也可附带在数据PDU末端上。

在RNC上行方向上，RLCAM实体从MAC层接收RLCPDUs。解码后提取RLC报头，并用于SDUs的重组。所有状态和控制PDU都经过处理，且相关信息将被发送至RLC发送端。发送端将根据接收到的状态PDU检查重传缓冲器。此外，RLC报头中的信息也可用于生成状态PDUs。

在CPU资源库中，RLC层的SDU与RLCPDU分段/级联会消耗大部分CPU资源。由于分段/级联以及重组能以高数据速率在所有RLC通道上执行，因此可将CPU从上述工作中释放出来，从而显著节约CPU资源。图4显示了RLC发送器的不同组件以及加速引擎和CPU集之间的分区。我们的目标就是将CPU从高带宽工作中释放出来。

在该设计方案中，RLC状态管理和控制仍由CPU资源库处理。对状态PDU进行处理，并将一系列命令重传给减负引擎（offloadengine）。

例如，在RNC发送器中断言RLCPDUPOLL位将导致RLC对等对状态PDU进行传输。状态PDU由RNCCPU资源库处理，随后加速引擎将接到指令，将RLCPDU从重传队列中释放出来，或向对等RLC重传PDU。

如图5所示，RLCSDU缓冲器将被保存在加速引擎中。由于CPU资源库不接收SDU，因而可通过SDU的减负、分类以及缓冲节约大量CPU资源。

流量控制是RLC协议的另一项功能。该功能使RLC接收器能够控制传输RLCPDU的对等的速率。流量控制逻辑在CPU资源库中实施，停止或恢复RLC通道的命令由该逻辑提交至加速引擎。

RLC分段/级联以及重组减负的性能分析

为了演示APP650网络处理器作为RLC加速引擎的功能并分析其系统性能，我们设计并实施了概念验证原型。在原型设计中，传输进来的RLCSDU可在APP650网络处理器中实现缓冲。在每一个传输时间间隔（TTI），对所有缓冲的SDU都进行分段和级联，并将RLCPDU传输至千兆以太网端口。随后，将RLCPDU回路返回至APP650网络处理器，并经过重组进程将SDU传回至测试设备。图5显示了测试配置情况。

最多可创建30，000个RLC连接，并可针对不同的SDU大小测量可持续吞吐量。可在在所有RLC连接上完成分段/级联以及重组。在所有实验中，均采用两个SDU突发长度进行定期突发。突发的时间间隔与TTI一致。在所有实验中，可将RLCPDU大小均设为100字节。

表1显示了SDU大小为142至442字节情况下的30，000个RLC通道的RLCSDU总吞吐量。请注意，无论SDU多大，所有30，000个通道的吞吐量均约为700Mb/s。这种决定性是通用处理器架构所无法实现的。对于30，000个连接而言，吞吐量受传输RLCPDU的千兆以太网接口带宽的限制，而与APP650的处理能力无关。预配置的RLC连接的数量不会影响吞吐量，这是因为所有RLC配置数据均保存在分类树中（查询延迟取决于模式大小，而非分类树中项目的数量），并且与RLC连接相关的所有状态均保存在状态引擎内部存储器中。

APP650仿真器可用于提供资源利用信息（表2）。结果显示了高RLC通道数情况下且总吞吐量达700Mb/s时的APP650上下文利用率。首处理（firstpass）和次处理（secondpass）上下文利用率分别为51%和10%，从而表明即便在此类极高的速率情况下，APP650网络处理器仍有进一步提高功能的足够空间。

结论

随着HSPA峰值数据速率不断提高，依靠一系列CPU内核来进行WCDMA用户平面处理的现有RNC平台已经不能满足流量工作负载提高的要求了。现有RNC平台的问题在于，用户平面处理（大多为数据处理）的性质不适用于通用CPU架构。无线用户平面处理要求对周期资源占用较高的功能进行优化，如RLC分段/级联和重组等。

本文介绍了一种可加速现有RNC WCDMA用户平面协议栈的方案，即让APP650网络处理器来完成RLC分段/级联和重组的工作。本文讨论了APP650架构的众多优势，如高效处理数据包的确定性等。仿真与原型设计表明，APP650网络处理器可为30KRLC通道提供高达700Mb/s的总吞吐量。对于高度灵活的RLC而言，我们能实现超过200Mb/s的单RLC通道峰值速率。

简言之，可将APP650网络处理器用作用户平面加速器，以解决当前RNC系统所面临的用户平面峰值和总速率等难题。

责任编辑：gt