摘要：針對(duì)LTE系統(tǒng)的高數(shù)據(jù)速率和海量信息容量的特點(diǎn)，對(duì)分組數(shù)據(jù)匯聚協(xié)議(PDCP)在功能上進(jìn)行了改進(jìn)。對(duì)壓縮算法進(jìn)行了簡(jiǎn)化，支持完整性保護(hù)和加密(UMTS的加密在RLC的非TM模式和MAC的TM模式下實(shí)現(xiàn))功能，分析了新的上下行數(shù)據(jù)傳輸方式以及在切換時(shí)的PDU重排序，最后設(shè)計(jì)了在OPNET中PDCP的具體實(shí)現(xiàn)方式。
關(guān)鍵詞：LTE；分組數(shù)據(jù)匯聚協(xié)議；OPNET；UMTS

0 引言
    3GPP希望通過(guò)升級(jí)諸如HSDPA和HSUPA這樣的無(wú)線接口技術(shù)，來(lái)確保未來(lái)10年或者更長(zhǎng)的時(shí)間內(nèi)，保持競(jìng)爭(zhēng)能力。因此LTE長(zhǎng)期演進(jìn)主要是以降低時(shí)延、提高用戶數(shù)據(jù)速率、改善系統(tǒng)容量以及覆蓋，并且降低運(yùn)營(yíng)商的成本為目標(biāo)。為了實(shí)現(xiàn)這些目標(biāo)，LTE系統(tǒng)設(shè)計(jì)涵蓋了無(wú)線接口和無(wú)線網(wǎng)絡(luò)架構(gòu)兩個(gè)方面。
    本文研究的分組數(shù)據(jù)匯聚協(xié)議(Packet Data Convergence Protocol，PDCP)層屬于無(wú)線接口協(xié)議棧的第二層，處理控制平面上的無(wú)線資源管理(RRC)消息以及用戶平面上的因特網(wǎng)協(xié)議(IP)包。在用戶平面上，PDCP子層得到來(lái)自上層的IP數(shù)據(jù)分組后，可以對(duì)IP數(shù)據(jù)分組進(jìn)行頭壓縮和加密，然后遞交到RLC子層。PDCP子層還向上層提供按序提交和重復(fù)分組檢測(cè)功能。在控制平面，PDCP子層為上層RRC提供信令傳輸服務(wù)，并實(shí)現(xiàn)RRC信令的加密和一致性保護(hù)，以及在反方向上實(shí)現(xiàn)RRC信令的解密和一致性檢查。

1 PDCP子層功能
    PDCP子層的主要功能如圖1所示。

    PDCP協(xié)議包括以下具體支持的功能：
    (1)用戶平面數(shù)據(jù)的報(bào)頭壓縮和解壓縮。
    (2)安全性功能：
    ①用戶和控制平面協(xié)議的加密和解密；
    ②控制平面數(shù)據(jù)的完整性保護(hù)和驗(yàn)證。
    (3)數(shù)據(jù)的傳輸功能：
    ①下層重建時(shí)，對(duì)向上層發(fā)送的PDU順序發(fā)送和重排序；
    ②對(duì)映射到AM模式的RB的下層SDU進(jìn)行重排序。
    (4)數(shù)據(jù)包的丟棄。
1．1 報(bào)頭壓縮
    在LTE系統(tǒng)中，規(guī)定PDCP子層支持由IETF(互聯(lián)網(wǎng)工程任務(wù)組)定義的健壯性報(bào)頭壓縮協(xié)議(ROHC)來(lái)進(jìn)行報(bào)頭壓縮。在LTE中，因其不支持通過(guò)電路交換域(CS)傳輸?shù)恼Z(yǔ)音業(yè)務(wù)，為了在分組交換域(PS)提供語(yǔ)音業(yè)務(wù)且接近常規(guī)電路交換域的效率，必須對(duì)IP／UDP／RTP報(bào)頭進(jìn)行壓縮，這些報(bào)頭通常用于VoIP業(yè)務(wù)。
    典型的，對(duì)于一個(gè)含有32 B有效載荷的VoIP分組傳輸來(lái)說(shuō)，IPv6報(bào)頭增加60 B，IPv4報(bào)頭增加40 B，即188％和125％的開(kāi)銷。
    為了解決這個(gè)問(wèn)題，在LTE系統(tǒng)中，設(shè)定在激活周期內(nèi)PDCP子層采用ROHC報(bào)頭壓縮技術(shù)，在壓縮實(shí)體初始化之后，這一開(kāi)銷可被壓縮成4～6個(gè)字節(jié)，即12．5％～18．8％的相對(duì)開(kāi)銷，從而提高了信道的效率和分組數(shù)據(jù)的有效性。
    IETF在“RFC 4995”中規(guī)定了一個(gè)框架，ROHC框架中有多種頭壓縮算法，稱為Profile，每一個(gè)Profile與特定的網(wǎng)絡(luò)層、傳輸層和更上層的協(xié)議相關(guān)，如TCP／IP和RTP／UDP／IP等。具體的報(bào)頭壓縮協(xié)議及屬性如表1所示。

    報(bào)頭壓縮協(xié)議可以產(chǎn)生兩種類型的輸出包：
    (1)壓縮分組包，每一個(gè)壓縮包都是由相應(yīng)的PDCP SDU經(jīng)過(guò)報(bào)頭壓縮產(chǎn)生的；
    (2)與PDCP SDU不相關(guān)的獨(dú)立包，即ROHC的反饋包。
    壓縮包總是與相應(yīng)的PDCP SDU采用相同的PDCP SN和COUNT值；ROHC反饋包不是由PDCPSDU產(chǎn)生的，沒(méi)有與之相關(guān)的PDCP SN，也不加密。
1．2 安全性功能
    LTE的安全性是在PDCP層負(fù)責(zé)的，通過(guò)加密(控制平面RRC數(shù)據(jù)和用戶平面數(shù)據(jù))及完整性保護(hù)(僅控制平面數(shù)據(jù))實(shí)現(xiàn)。
1．2．1 加密／解密
    在LTE系統(tǒng)中，加密功能位于PDCP實(shí)體中，加密對(duì)象包括：
    (1)控制平面，被加密的數(shù)據(jù)單元是PDCP PDU的數(shù)據(jù)部分(未壓縮的用戶面或控制面的PDCP SDU或壓縮的用戶平面PDCP SDU)和MAC—I域(完整性消息鑒權(quán)碼)。
    (2)用戶平面，被加密的數(shù)據(jù)單元是PDCP PDU的數(shù)據(jù)部分。
    PDCP實(shí)體所使用的加密算法和密鑰(KEY)由高層協(xié)議配置。一旦激活安全功能，加密功能即被高層激活，該功能應(yīng)用于高層指示的所有PDCP PDU。PDCP用于加密的參數(shù)包括以下2個(gè)：COUNT；DIRECTION(傳輸?shù)姆较?。
    RRC協(xié)議提供給PDCP加密功能所需要的參數(shù)包括以下2個(gè)：BEARER；KEY(控制平面使用KRRCenc，用戶平面使用KUPenc)。
    加密是通過(guò)對(duì)消息和加密流做異或(XOR)運(yùn)算來(lái)實(shí)現(xiàn)的，這里加密流是由基于接入層(AS)導(dǎo)出密鑰、無(wú)線承載ID、傳輸方向(上行或下行)以及COUNT值的加密算法所生成的。加密僅適用于PDCP數(shù)據(jù)PDU。控制PDU(如ROHC反饋或PDCP狀態(tài)報(bào)告)既不使用加密，也不適用完整性保護(hù)。
1．2．2 完整性保護(hù)
    完整性保護(hù)功能包括完整性保護(hù)和完整性驗(yàn)證兩個(gè)過(guò)程，完整性保護(hù)功能僅應(yīng)用于SRB。用于PDCP實(shí)體的完整性保護(hù)功能的算法和KEY由上層配置。一旦激活安全功能，完整性保護(hù)功能即被高層激活，該功能應(yīng)用于高層指示的所有PDCP PDU。PDCP用于完整性保護(hù)的參數(shù)包括以下2個(gè)：COUNT；DIREC-TION(傳輸?shù)姆较?。
    RRC協(xié)議提供給PDCP完整性保護(hù)功能的參數(shù)包括以下2個(gè)：BEARER；KEY(控制平面使用KRRCint)。
    UE基于上述輸入的參數(shù)計(jì)算X-MAC，進(jìn)行PDCP PDU的完整性驗(yàn)證。如果計(jì)算出的X-MAC與MAC-I相同，則完整性保護(hù)驗(yàn)證成功。
1．3 數(shù)據(jù)的傳輸
    控制平面的PDCP PDU和用戶平面的PDCP數(shù)據(jù)PDU都擁有一個(gè)序列號(hào)SN字段，PDCP子層的發(fā)送和接收實(shí)體就是通過(guò)設(shè)置和檢查SN字段來(lái)實(shí)現(xiàn)PDCPPDU的按序發(fā)送和接收。PDCP子層在發(fā)送側(cè)和接收側(cè)分別維護(hù)一個(gè)重排序窗口的大小是SN范圍的50％。當(dāng)SN為0～4 095時(shí)，即“最大PDCP SN”的值為4 095時(shí)，重排序窗口的大小為2 048。
    在非切換狀態(tài)下，RLC子層位為PDCP子層提供按序提交和重復(fù)包丟棄服務(wù)。而在切換狀態(tài)下，由于UE與兩個(gè)eNodeB同時(shí)通信，因此其RLC子層無(wú)法保證按序提交和重復(fù)包丟棄，從而需要由PDCP子層來(lái)完成這些功能。
    下面以UE側(cè)的操作為例說(shuō)明PDCP子層的發(fā)送和接收流程。
1．3．1 上行發(fā)送
    每一個(gè)PDCP SDU對(duì)應(yīng)一個(gè)Discard Timer，一旦由高層接收到一個(gè)PDCP SDU，即啟動(dòng)該SDU對(duì)應(yīng)的Discard Timer。同時(shí)，進(jìn)行發(fā)送相關(guān)的狀態(tài)變量更新及加密、完整性保護(hù)等，具體過(guò)程如圖2所示。

1．3．2 下行接收
    在不需重建的普通工作模式下，PDCP實(shí)體在接收到RLC AM實(shí)體提交的PDCP PDU時(shí)，不需執(zhí)行重排序過(guò)程，因?yàn)镽LC AM在向PDCP實(shí)體提交PDCPPDU時(shí)，已保證順序遞交。以切換引起的PDCP重建為例，UE先從源eNodeB收到一些PDCP SDU，重建開(kāi)始后從目的eNodeB接收PDCP SDU(其中部分是源eNodeB轉(zhuǎn)給目的eNodeB的，并且有一些是源eNodeB已發(fā)給UE但尚未得到確認(rèn)的)，因此，UE的PDCP實(shí)體收到的PDCP SDU可能是亂序并且有重復(fù)的，因此對(duì)于RLC AM模式，在重建情況下，PDCP接收實(shí)體需對(duì)接收的PDCP SDU進(jìn)行重排序和重復(fù)檢測(cè)。
    綜合上述各種情況，對(duì)映射到RLC AM模式的DRB接收處理過(guò)程如下：定義接收的PDCP序列號(hào)為SN，接收端上一次提交給高層的PDCP SDU序列號(hào)為L(zhǎng)ast_Submitted_PDCP_RX_SN，Reordering_Window為序列號(hào)空間50％長(zhǎng)度的重排序窗，RX_HFN為接收端當(dāng)前HFN，Next_PDCP_RX_SN為接收端期待的下一個(gè)接收的PDCP序列號(hào)，具體流程如圖3所示。

1．4 數(shù)據(jù)包丟棄
    LTE的PDCP層的丟棄功能基于定時(shí)器，發(fā)射機(jī)從高層接收到每一個(gè)PDCP SDU時(shí)該定時(shí)器啟動(dòng)，當(dāng)定時(shí)器溢出時(shí)UE仍未發(fā)起PDCP SDU傳輸，那么丟棄該P(yáng)DCP SDU。如果定時(shí)器被設(shè)置到一個(gè)合適的值來(lái)滿足無(wú)線承載所要求的QoS，這一丟棄機(jī)制可以防止發(fā)射機(jī)的過(guò)渡延時(shí)和排隊(duì)現(xiàn)象。具體的處理過(guò)程如下：
1．4．1 上行發(fā)送
    當(dāng)高層要求PDCP重建時(shí)，映射到RLC AM模式的DRB處理過(guò)程：
    (1)重置上行頭壓縮協(xié)議。
    (2)在重建過(guò)程中，應(yīng)用高層提供的加密算法以及密鑰。
    (3)由第一個(gè)還沒(méi)有確認(rèn)成功發(fā)送的PDCP SDU開(kāi)始執(zhí)行重傳，或者按COUNT升序，優(yōu)先于重傳過(guò)程發(fā)送所有已關(guān)聯(lián)了PDCP序列號(hào)的PDCP SDU。
    ①按照第一節(jié)報(bào)頭壓縮中提及的壓縮算法，執(zhí)行PDCP SDU報(bào)頭壓縮過(guò)程。
    ②按照安全性功能介紹的加密過(guò)程，執(zhí)行PDCPSDU加密過(guò)程。
    ③將經(jīng)過(guò)上述處理的PDCP數(shù)據(jù)PDU遞交給下層。
1．4．2 下行接收
    當(dāng)高層要求PDCP重建時(shí)，映射到RLC AM模式的DRB處理過(guò)程：
    (1)處理所有由于下層重建而由下層接收的PDCP數(shù)據(jù)PDU。
    (2)重置下行頭壓縮協(xié)議。
    (3)在重建過(guò)程中，應(yīng)用高層提供的加密以及完整性保護(hù)算法。

2 PDCP在OPNET中的實(shí)現(xiàn)
2．1 PDCP傳輸?shù)膶?shí)現(xiàn)
    在OPNET中PDCP傳輸?shù)膶?shí)現(xiàn)是通過(guò)直接改變數(shù)據(jù)包的大小來(lái)仿真網(wǎng)絡(luò)流量，PDCP在OPNET中壓縮側(cè)的實(shí)現(xiàn)流程圖如圖4所示。

    PDCP的傳輸過(guò)程是在收到來(lái)自上層的數(shù)據(jù)流時(shí)調(diào)用，進(jìn)入strm==FROM_HIGHER分支之后執(zhí)行l(wèi)te_gmm_client_packet_process(pkptr)函數(shù)，在這個(gè)函數(shù)中GMM層完成對(duì)上層數(shù)據(jù)包的處理，并生成向RLC轉(zhuǎn)發(fā)的數(shù)據(jù)包rlc_pkptr以及接口控制信息ICI包pdu_iciptr，并將ICI包綁定在傳給RLC的數(shù)據(jù)包上。當(dāng)獲取ICI中斷，如果有ICI的中斷，那說(shuō)明當(dāng)前狀態(tài)為收到上層發(fā)來(lái)的IP數(shù)據(jù)包，如果沒(méi)有ICI中斷，那么需要轉(zhuǎn)發(fā)的是命令消息。但是不管是數(shù)據(jù)包還是命令包，都進(jìn)入lte_suppor_pdcp_header_comp_size_compute函數(shù)得到壓縮后的大小，公式為：
   
    這里的comp_ratio就是從GMM屬性中獲取的PDCP壓縮率，保存在pdcp_comp_info變量之中。
2．2 仿真結(jié)果
    為了驗(yàn)證頭壓縮在LTE中空口的應(yīng)用，設(shè)計(jì)了一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)模型，主要由用戶終端UE、eNodeB、核心網(wǎng)CN和外部網(wǎng)絡(luò)FTP組成。分別對(duì)UE設(shè)定在采用PDCP和沒(méi)有采用PDCP的兩種情況下，仿真eNo-deB的上下行吞吐量性能。在這個(gè)場(chǎng)景中，設(shè)置了30個(gè)移動(dòng)終端UE執(zhí)行FTP業(yè)務(wù)，并且假設(shè)已經(jīng)建立了PS信令連接，并且在仿真期間一直保持。
    這種FTP背景類業(yè)務(wù)對(duì)吞吐量要求很高，圖5表示從eNodeB采集到的上行吞吐量性能，采用了PDCP壓縮技術(shù)的曲線(虛線)，相對(duì)于沒(méi)有使用PDCP的曲線(實(shí)線)的吞吐量緩慢的提升，這是由于FTP這種業(yè)務(wù)特性決定的。當(dāng)用戶激活背景類業(yè)務(wù)時(shí)，網(wǎng)絡(luò)首先對(duì)該類用戶進(jìn)行接入控制，判斷網(wǎng)絡(luò)是否有剩余容量接入該用戶，如果有容量則允許該用戶接入，但是并不給該業(yè)務(wù)預(yù)留帶寬。當(dāng)系統(tǒng)擁塞時(shí)，允許對(duì)該類型用戶進(jìn)行丟棄操作。背景類業(yè)務(wù)對(duì)時(shí)延和時(shí)延抖動(dòng)要求較低，采用盡力而為的方式進(jìn)行轉(zhuǎn)發(fā)。圖6顯示的是下行鏈路的吞吐量情況，采用PDCP技術(shù)后吞吐量得到了明顯的提升。

3 結(jié)論
    LTE作為3GPP中GSM和UMTS家族的技術(shù)演進(jìn)，被看作完成了業(yè)務(wù)擴(kuò)展這一趨勢(shì)，即從簡(jiǎn)單的語(yǔ)音業(yè)務(wù)向建立多業(yè)務(wù)空中接口的轉(zhuǎn)變，并且所有的業(yè)務(wù)都是基于分組交換模式，這就對(duì)系統(tǒng)容量的需求非常大。諸如在實(shí)時(shí)業(yè)務(wù)VoIP中，空中接口資源有限，應(yīng)用PDCP層中優(yōu)化的頭壓縮技術(shù)，能夠有效地降低包頭的開(kāi)銷，提高空口的傳輸效率，而且PDCP層還支持加密功能，讓傳輸更具有可靠性。由此可見(jiàn)，LTE中的PDCP層的設(shè)計(jì)，在功能上體現(xiàn)了LTE系統(tǒng)的高數(shù)據(jù)速率、低時(shí)延和分組優(yōu)化的設(shè)計(jì)目標(biāo)。