《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 通信與網(wǎng)絡(luò) > 設(shè)計應(yīng)用 > LTE系統(tǒng)中PDCP子層功能研究
LTE系統(tǒng)中PDCP子層功能研究
現(xiàn)代電子技術(shù)
孫遠欣,,杭小飛,張雪梅
摘要: 摘要:針對LTE系統(tǒng)的高數(shù)據(jù)速率和海量信息容量的特點,,對分組數(shù)據(jù)匯聚協(xié)議(PDCP)在功能上進行了改進。對壓縮算法進行了簡化,,支持完整性保護和加密(UMTS的加密在RLC的非TM模式和MAC的TM模式下實現(xiàn))功能,,分析了新的上
Abstract:
Key words :

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

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

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

a.JPG


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

b.JPG


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

d.JPG


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

e.JPG

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

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

f.JPG

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

c.JPG

g.JPG

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

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權(quán)禁止轉(zhuǎn)載,。