隨著高速分組接入(HSPA)峰值數(shù)據(jù)速率不斷提高，目前主要依靠各種通用處理器(CPU)進(jìn)行用戶平面處理工作的無線電網(wǎng)絡(luò)控制器(RNC)平臺(tái)已無法滿足日益增加的通信有效負(fù)載要求。因此，RNC需要通過新的方法來處理PDCP、無線鏈路控制(RLC),、MAC以及FP等用戶平面無線協(xié)議。由于對(duì)峰值數(shù)據(jù)速率要求的提高，以及HSPA用戶數(shù)量和與WCDMA網(wǎng)絡(luò)相關(guān)流量的增加,，RNC需要更快速的HSPA。

　　  本文將介紹如何通過LSIAPP650 Advanced Payload Plus網(wǎng)絡(luò)處理器來加快當(dāng)前的HSPA用戶平面設(shè)計(jì),，不管目前的用戶平面運(yùn)行于何種硬件上,。通過讓APP650接管RLC分段/級(jí)聯(lián)以及重組等用戶平面處理工作，RNC可針對(duì)小型RLC服務(wù)數(shù)據(jù)單元(SDU)提供100Mb/s以上的用戶峰值數(shù)據(jù)速率,，并且可使3萬名用戶的總吞吐量達(dá)到700Mb/s以上,。通過使用APP650分擔(dān)部分處理工作的方法以及高度靈活的RLC(3GPP7版本以上)，使每用戶的峰值速率吞吐量能達(dá)到200Mb/s以上,。

　　  蜂窩系統(tǒng)的一個(gè)重要要求就是為分組數(shù)據(jù)業(yè)務(wù)提供高數(shù)據(jù)速度,。為滿足這一要求，3GPP/WCDMA標(biāo)準(zhǔn)R5版和R6版均提出了HSPA標(biāo)準(zhǔn),。盡管3GPP/WCDMA標(biāo)準(zhǔn)R1版就支持分組數(shù)據(jù)通信,，但HSPA進(jìn)一步增強(qiáng)了性能，可提供更高階調(diào)制、快速的調(diào)度以及速率控制等,，從而支持更高的每用戶峰值數(shù)據(jù)速率,。隨著HSPA的不斷發(fā)展，峰值數(shù)據(jù)速率也將不斷提高,。預(yù)計(jì)3GPP7版本以上的每用戶峰值數(shù)據(jù)速率將提升至200Mb/s以上,。

　　  在采用HSPA技術(shù)的3G網(wǎng)絡(luò)中，RNC通?？刂茢?shù)百個(gè)基站,。RNC負(fù)責(zé)其控制下各蜂窩系統(tǒng)的呼叫設(shè)置和無線電資源管理。WCDMA用戶平面協(xié)議層包括PDCP,、RLC,、MAC以及FP等，都是在下行方向上的RNC中啟動(dòng),，和在上行方向上的RNC中終止,。

　　  RLC協(xié)議層是唯一終止于3G網(wǎng)絡(luò)用戶設(shè)備(移動(dòng)設(shè)備)中的RNC用戶平面層。所有其它層均只位于RNC與基站之間,。

　　  現(xiàn)有RNC平臺(tái)通常使用多個(gè)通用CPU來處理WCDMA用戶平面協(xié)議棧,。隨著HSPA的發(fā)展以及蜂窩數(shù)據(jù)速率的提高，現(xiàn)有RNC架構(gòu)已無法滿足WCDMA網(wǎng)絡(luò)日益提高的通信有效負(fù)載要求,。

　　  根據(jù)摩爾定律,，CPU的性能每18個(gè)月應(yīng)提高1倍。根據(jù)幾份市場(chǎng)研究報(bào)告顯示,，預(yù)計(jì)對(duì)RNC用戶平面處理容量的網(wǎng)絡(luò)需求每12個(gè)月將提高約3倍,，當(dāng)前的RNC用戶平面處理技術(shù)顯然無力應(yīng)付不斷發(fā)展的需求(圖1)。LSI針對(duì)這一問題提供了短期和長(zhǎng)期解決方案,。

　　  本文建議采用的解決方案是將CPU從RLC分段/級(jí)聯(lián)工作中釋放出來,，從而顯著降低當(dāng)前CPU的工作負(fù)載。此前曾將CPU從分段工作中釋放出來用于其它協(xié)議(如TCP)中,，以縮短服務(wù)器平臺(tái)中的CPU周期,。本文將介紹類似理念的應(yīng)用，以加速WCDMA用戶平面處理(尤其是RLC協(xié)議),。LSIAPP650處理器將CPU從分段/級(jí)聯(lián)以及重組工作中釋放出來,，支持高達(dá)3萬用戶的RLC連接。圖2為幾個(gè)CPU采用單一APP650處理器作為加速引擎的情況,。

相對(duì)于通常受限于單核或單線程性能的非加速方案而言,，這種加速方案具有明顯的優(yōu)勢(shì)。以前,，提高HSPA峰值數(shù)據(jù)速率和增加用戶(使用典型的CPU和操作系統(tǒng)模型,，用CPU進(jìn)行用戶平面處理的用戶)數(shù)量要求單用戶處理軟件在多個(gè)處理器上并行或管道化操作。這種軟件工作方式不僅極其復(fù)雜、成本高昂,，而且容易出錯(cuò),。與此不同的是，我們可利用LSIAPP650處理器來負(fù)責(zé)一些CPU工作強(qiáng)度最高的處理任務(wù),，從而節(jié)約50%乃至更多的CPU處理資源,。而且在采用同一硬件時(shí)，高峰值數(shù)據(jù)速率與總體吞吐量將提高一倍以上,。

APP650在用戶平面處理方面的優(yōu)勢(shì)

APP650網(wǎng)絡(luò)處理器由幾個(gè)處理單元組成,，其中包括模式處理器、流量管理和狀態(tài)引擎等,。

模式處理器主要負(fù)責(zé)數(shù)據(jù)包分類,，其采用管線化、多線程的多處理器架構(gòu),。模式處理器的每管線級(jí)能在每個(gè)時(shí)鐘周期的不同上下文/線程下工作,，這不同于管線中的所有指令必須屬于單個(gè)上下文且只有上下文暫停(高速緩存缺失、存儲(chǔ)器訪問,、分支預(yù)測(cè)錯(cuò)誤等)時(shí)才打開管線中上下文執(zhí)行的傳統(tǒng)通用架構(gòu),。在傳統(tǒng)的單線程架構(gòu)中，讓執(zhí)行管線保持繁忙比較困難,，因?yàn)楣芫€中的所有指令都屬于單線程,。在APP650架構(gòu)中，如果上下文執(zhí)行的函數(shù)調(diào)用時(shí)延較高,，那么該函數(shù)調(diào)用在管線中的位置會(huì)被分配給其他上下文,。因此，APP650多線程架構(gòu)能支持零周期上下文切換功能,，這在單線程的多核架構(gòu)中是不能實(shí)現(xiàn)的,。模式處理引擎可提供144個(gè)不同的上下文，能全面利用硬件資源,，并避免存儲(chǔ)器出現(xiàn)時(shí)延。

與此形成對(duì)比的是,，CPU的存儲(chǔ)器瓶頸會(huì)導(dǎo)致我們難以充分利用資源,，而且會(huì)浪費(fèi)CPU的工作周期。APP650網(wǎng)絡(luò)處理器會(huì)為即將到達(dá)的數(shù)據(jù)包分配一個(gè)上下文,，這樣許多數(shù)據(jù)包能同時(shí)處理,。由于我們能同時(shí)處理許多數(shù)據(jù)包，這樣就能充分利用CPU資源,，而且還能實(shí)現(xiàn)高達(dá)5.9Gb/s的數(shù)據(jù)速率,。

在APP650架構(gòu)中，機(jī)制與策略是彼此獨(dú)立的。硬件負(fù)責(zé)提供機(jī)制,，而軟件負(fù)責(zé)提供策略,。APP650架構(gòu)是在硬件中執(zhí)行存儲(chǔ)器管理與數(shù)據(jù)移動(dòng)，因此在牽涉到存儲(chǔ)器的分配與釋放,、數(shù)據(jù)包指針的跟蹤或者數(shù)據(jù)復(fù)制到不同存儲(chǔ)器地址等方面時(shí)間,，不會(huì)出現(xiàn)軟件消耗資源的問題。APP650硬件就每個(gè)數(shù)據(jù)包調(diào)用軟件來提供決策,，避免了因中斷處理或輪詢而浪費(fèi)CPU資源,。APP650網(wǎng)絡(luò)處理器還包括了預(yù)排序修改(PQM)引擎，其不僅能在數(shù)據(jù)包的不同部分中插入或刪除數(shù)據(jù),，而且還可將數(shù)據(jù)包分段為許多子數(shù)據(jù)包。PQM引擎的上述特性可顯著加速RLC分段/排序進(jìn)程,。另外,，APP650網(wǎng)絡(luò)處理器還有一個(gè)重要特性，就是硬件輔助多字段數(shù)據(jù)包分類,。數(shù)據(jù)包分類可能占用很多CPU資源,，但在APP650網(wǎng)絡(luò)處理器上數(shù)據(jù)包分類非常高效。

APP650狀態(tài)引擎提供了跟蹤數(shù)據(jù)包相關(guān)狀態(tài)的機(jī)制,。在RLC處理中,，我們用該引擎跟蹤RLC連接狀態(tài)。舉例來說,，與每個(gè)RLC連接相關(guān)的12位序列號(hào)都是狀態(tài)引擎所跟蹤的協(xié)議狀態(tài)的一部分,。

在APP650網(wǎng)絡(luò)處理器中，硬件將軟件作為子例程調(diào)用,，就緩沖管理,、流量整形/調(diào)度和數(shù)據(jù)包修改提供決策。軟件運(yùn)行在基于超長(zhǎng)指令字(VLIW)架構(gòu)的三個(gè)計(jì)算引擎上,。緩沖管理計(jì)算引擎強(qiáng)制執(zhí)行數(shù)據(jù)包丟棄策略并保持排序統(tǒng)計(jì)數(shù)據(jù),。流量整形器引擎確定每個(gè)隊(duì)列的服務(wù)質(zhì)量(QOS)和服務(wù)等級(jí)(COS)處理。流編輯器計(jì)算引擎執(zhí)行協(xié)議數(shù)據(jù)單元(PDU)修改,。APP650網(wǎng)絡(luò)處理器的硬件輔助流量管理支持成千上萬隊(duì)列的確定性流量管理行為,，同時(shí)還提供了一個(gè)框架，通過C編程語言子集進(jìn)行流量管理算法定制,。由于流量管理功能由不同引擎執(zhí)行,，因此分類工作負(fù)載不會(huì)影響流量管理的確定性。

與此形成對(duì)比的是,，CPU架構(gòu)要在支持?jǐn)?shù)據(jù)包處理應(yīng)用的同一處理器池上或在一個(gè)單獨(dú)分配的內(nèi)核上執(zhí)行流量管理算法,。這兩種情況都會(huì)造成硬件資源在確定性方面利用不充分,。此外，軟件程序員還要負(fù)責(zé)流量管理解決方案開發(fā)的各方面工作,。APP650架構(gòu)通過硬件框架消除了上述各種復(fù)雜問題,，軟件程序員只需做出流量決策。

APP650架構(gòu)的構(gòu)建使軟件開發(fā)人員不用考慮硬件多線程和并行處理的問題,。因此,，APP650架構(gòu)所需較少的軟件編程，相對(duì)于現(xiàn)有的CPU無線用戶平面解決方案而言能大幅提高吞吐量,。

LSI提供了豐富的軟件開發(fā)環(huán)境,，包括確保周期精度的仿真器，可用作功能調(diào)試和應(yīng)用性能分析,。此外,，仿真器工具還能用來確定不同硬件資源的利用。

將CPU從RLC分段/級(jí)聯(lián)任務(wù)中釋放出來

根據(jù)所需可靠性的不同,，RLC可分為三種不同的工作模式,。我們?cè)诒疚闹兄挥懻揜LC確認(rèn)模式(AM)。RLCAM模式通過自動(dòng)重復(fù)請(qǐng)求(ARQ)協(xié)議來提供可靠的通信,。

在RNC下行方向上，發(fā)送器執(zhí)行SDU的分段和級(jí)聯(lián)任務(wù),。RLCSDUs可映射至RLCPDUs,，發(fā)送并置于重傳隊(duì)列中。在不同條件下,，發(fā)送器可生成狀態(tài)報(bào)告并反饋給對(duì)等RLC,。狀態(tài)報(bào)告可作為獨(dú)立的RLCPDU發(fā)送，如果有足夠的填充碼的話,，它也可附帶在數(shù)據(jù)PDU末端上。

在RNC上行方向上,，RLCAM實(shí)體從MAC層接收RLCPDUs,。解碼后提取RLC報(bào)頭，并用于SDUs的重組,。所有狀態(tài)和控制PDU都經(jīng)過處理,，且相關(guān)信息將被發(fā)送至RLC發(fā)送端。發(fā)送端將根據(jù)接收到的狀態(tài)PDU檢查重傳緩沖器,。此外,，RLC報(bào)頭中的信息也可用于生成狀態(tài)PDUs,。

在CPU資源庫中,，RLC層的SDU與RLCPDU分段/級(jí)聯(lián)會(huì)消耗大部分CPU資源。由于分段/級(jí)聯(lián)以及重組能以高數(shù)據(jù)速率在所有RLC通道上執(zhí)行,，因此可將CPU從上述工作中釋放出來，從而顯著節(jié)約CPU資源,。圖4顯示了RLC發(fā)送器的不同組件以及加速引擎和CPU集之間的分區(qū),。我們的目標(biāo)就是將CPU從高帶寬工作中釋放出來。

在該設(shè)計(jì)方案中,，RLC狀態(tài)管理和控制仍由CPU資源庫處理,。對(duì)狀態(tài)PDU進(jìn)行處理,，并將一系列命令重傳給減負(fù)引擎(offloadengine),。

例如，在RNC發(fā)送器中斷言RLCPDUPOLL位將導(dǎo)致RLC對(duì)等對(duì)狀態(tài)PDU進(jìn)行傳輸,。狀態(tài)PDU由RNCCPU資源庫處理,，隨后加速引擎將接到指令，將RLCPDU從重傳隊(duì)列中釋放出來,，或向?qū)Φ萊LC重傳PDU,。

如圖5所示，RLCSDU緩沖器將被保存在加速引擎中,。由于CPU資源庫不接收SDU,，因而可通過SDU的減負(fù)、分類以及緩沖節(jié)約大量CPU資源,。

流量控制是RLC協(xié)議的另一項(xiàng)功能,。該功能使RLC接收器能夠控制傳輸RLCPDU的對(duì)等的速率。流量控制邏輯在CPU資源庫中實(shí)施,，停止或恢復(fù)RLC通道的命令由該邏輯提交至加速引擎,。

RLC分段/級(jí)聯(lián)以及重組減負(fù)的性能分析

為了演示APP650網(wǎng)絡(luò)處理器作為RLC加速引擎的功能并分析其系統(tǒng)性能，我們?cè)O(shè)計(jì)并實(shí)施了概念驗(yàn)證原型,。在原型設(shè)計(jì)中,，傳輸進(jìn)來的RLCSDU可在APP650網(wǎng)絡(luò)處理器中實(shí)現(xiàn)緩沖。在每一個(gè)傳輸時(shí)間間隔(TTI),，對(duì)所有緩沖的SDU都進(jìn)行分段和級(jí)聯(lián),，并將RLCPDU傳輸至千兆以太網(wǎng)端口。隨后,，將RLCPDU回路返回至APP650網(wǎng)絡(luò)處理器,，并經(jīng)過重組進(jìn)程將SDU傳回至測(cè)試設(shè)備。圖5顯示了測(cè)試配置情況,。

最多可創(chuàng)建30,000個(gè)RLC連接,，并可針對(duì)不同的SDU大小測(cè)量可持續(xù)吞吐量,。可在在所有RLC連接上完成分段/級(jí)聯(lián)以及重組,。在所有實(shí)驗(yàn)中，均采用兩個(gè)SDU突發(fā)長(zhǎng)度進(jìn)行定期突發(fā),。突發(fā)的時(shí)間間隔與TTI一致,。在所有實(shí)驗(yàn)中，可將RLCPDU大小均設(shè)為100字節(jié),。

表1顯示了SDU大小為142至442字節(jié)情況下的30,000個(gè)RLC通道的RLCSDU總吞吐量,。請(qǐng)注意，無論SDU多大,，所有30,000個(gè)通道的吞吐量均約為700Mb/s,。這種決定性是通用處理器架構(gòu)所無法實(shí)現(xiàn)的。對(duì)于30,000個(gè)連接而言,，吞吐量受傳輸RLCPDU的千兆以太網(wǎng)接口帶寬的限制,，而與APP650的處理能力無關(guān)。預(yù)配置的RLC連接的數(shù)量不會(huì)影響吞吐量,，這是因?yàn)樗蠷LC配置數(shù)據(jù)均保存在分類樹中(查詢延遲取決于模式大小,，而非分類樹中項(xiàng)目的數(shù)量)，并且與RLC連接相關(guān)的所有狀態(tài)均保存在狀態(tài)引擎內(nèi)部存儲(chǔ)器中,。

APP650仿真器可用于提供資源利用信息(表2),。結(jié)果顯示了高RLC通道數(shù)情況下且總吞吐量達(dá)700Mb/s時(shí)的APP650上下文利用率。首處理(firstpass)和次處理(secondpass)上下文利用率分別為51%和10%,，從而表明即便在此類極高的速率情況下,，APP650網(wǎng)絡(luò)處理器仍有進(jìn)一步提高功能的足夠空間。

結(jié)論

隨著HSPA峰值數(shù)據(jù)速率不斷提高,，依靠一系列CPU內(nèi)核來進(jìn)行WCDMA用戶平面處理的現(xiàn)有RNC平臺(tái)已經(jīng)不能滿足流量工作負(fù)載提高的要求了?，F(xiàn)有RNC平臺(tái)的問題在于，用戶平面處理(大多為數(shù)據(jù)處理)的性質(zhì)不適用于通用CPU架構(gòu),。無線用戶平面處理要求對(duì)周期資源占用較高的功能進(jìn)行優(yōu)化,，如RLC分段/級(jí)聯(lián)和重組等。

本文介紹了一種可加速現(xiàn)有RNC WCDMA用戶平面協(xié)議棧的方案,，即讓APP650網(wǎng)絡(luò)處理器來完成RLC分段/級(jí)聯(lián)和重組的工作,。本文討論了APP650架構(gòu)的眾多優(yōu)勢(shì)，如高效處理數(shù)據(jù)包的確定性等,。仿真與原型設(shè)計(jì)表明,，APP650網(wǎng)絡(luò)處理器可為30KRLC通道提供高達(dá)700Mb/s的總吞吐量。對(duì)于高度靈活的RLC而言,，我們能實(shí)現(xiàn)超過200Mb/s的單RLC通道峰值速率,。

簡(jiǎn)言之,，可將APP650網(wǎng)絡(luò)處理器用作用戶平面加速器，以解決當(dāng)前RNC系統(tǒng)所面臨的用戶平面峰值和總速率等難題,。