lte空中接口技術(shù)與性能4

1、LTE空中接口技術(shù)與性能 (4)主講:教授2012.10.23第四章 空中接口和RRC技術(shù)在LTE網(wǎng)絡(luò)結(jié)構(gòu)中，由于不存在RNC，所以整個(gè)空中接口協(xié)議結(jié)構(gòu)和原來(lái)的UTRAN相比有較大不同，尤其是不同功能實(shí)體的位置出現(xiàn)了很多變化。原來(lái)由RNC承擔(dān)的功能被分散到了eNode B和服務(wù)網(wǎng)關(guān)（SGW）上。概述LTE空中接口的用戶平面和控制平面（如圖所示）功能由eNode B統(tǒng)一進(jìn)行管理和控制，包括完成基站之間的切換等。由于減少了一層節(jié)點(diǎn)，用戶平面的數(shù)據(jù)傳送和控制平面的無(wú)線資源控制變得更加方便、靈活。2用戶平面和控制平面3物理層技術(shù)演進(jìn)數(shù)據(jù)鏈路層協(xié)議棧 4（1）不再使用專(zhuān)用傳輸信道，通過(guò)在上下行鏈路使用共

2、享信道，使多個(gè)用戶共享空中接口的無(wú)線資源。（2）和UTRAN相比，空中接口的媒體接入控制（MAC）子層的實(shí)體類(lèi)型得以簡(jiǎn)化，不再保留用于專(zhuān)用傳輸信道的MAC-d實(shí)體。（3）廣播媒體控制層和UTRAN的公共業(yè)務(wù)信道不再保留。（4）對(duì)于點(diǎn)對(duì)點(diǎn)業(yè)務(wù)，不再使用宏分集合并，但并不排除對(duì)于廣播多播業(yè)務(wù)（MBMS）或同一基站下不同小區(qū)之間進(jìn)行下行鏈路的軟合并。（5）不再支持用于異頻或異系統(tǒng)測(cè)量的壓縮模式。（6）減少RRC狀態(tài)數(shù)，只保留RRC_IDLE和RRC_CONNECT兩種狀態(tài)，最大程度地簡(jiǎn)化RRC層處理。LTE空中接口協(xié)議與UTRAN相比的主要改進(jìn)體現(xiàn)在以下幾個(gè)方面54.2 PDCP子層PDCP子層的主

3、要作用是將網(wǎng)絡(luò)層的傳輸技術(shù)與E-UTRAN的空中接口處理技術(shù)剝離開(kāi)，使其上的各協(xié)議層無(wú)需考慮與空中接口相關(guān)的問(wèn)題。PDCP子層向上層提供用戶平面和控制平面的數(shù)據(jù)傳輸功能。在用戶平面上，PDCP子層得到來(lái)自上層的IP數(shù)據(jù)分組后，可以對(duì)IP數(shù)據(jù)分組進(jìn)行頭壓縮和加密，然后遞交到RLC子層。最新的3GPP LTE協(xié)議TS 36.323 V8.4.0中規(guī)定，目前PDCP子層僅支持ROHC頭壓縮協(xié)議（IETF RFC 3095）。PDCP子層還向上層提供按序提交和重復(fù)分組檢測(cè)功能。在控制平面，PDCP子層為上層RRC子層提供信令傳輸服務(wù)，并實(shí)現(xiàn)RRC信令的加密和一致性保護(hù)，以及在反方向上實(shí)現(xiàn)RRC信令的解

4、密和一致性檢查。PDCP子層的主要功能如圖4-3所示。6圖4-3 PDCP子層功能74.2.1 PDCP PDU網(wǎng)絡(luò)結(jié)構(gòu)PDCP 子層傳輸?shù)腜DCP PDU總體上可分為兩類(lèi)：控制平面的PDCP PDU和用戶平面的PDCP PDU。用戶平面的PDCP PDU又可分為用戶平面PDCP數(shù)據(jù)PDU和用戶平面PDCU控制PDU?？刂破矫娴腜DCP PDU格式如圖4-4所示。圖4-4 控制平面PDCP PDU8控制平面PDCP PDU的SN字段長(zhǎng)度為5bit，表示PDCP PDU的序號(hào)。MAC-I字段用于控制信息的一致性保護(hù)和檢查。PDCP子層的一致性保護(hù)和檢查功能僅應(yīng)用于控制平面的PDCP PDU。受到

5、一致性保護(hù)的內(nèi)容是加密前的PDU頭和數(shù)據(jù)凈荷。用戶平面PDCP數(shù)據(jù)PDU格式如圖4-5所示。圖4-5 用戶平面PDCP數(shù)據(jù)PDU9用戶平面PDCP PDU通過(guò)D/C字段的一個(gè)比特來(lái)區(qū)分?jǐn)?shù)據(jù)PDU和控制PDU。D/C字段為0表示數(shù)據(jù)PDU，D/C字段為1表示控制PDU。數(shù)據(jù)PDU中包含SN字段，長(zhǎng)度可以配置為7bit或12bit。用戶平面控制PDU包括頭壓縮反饋信息和PDCP狀態(tài)報(bào)告兩種。PDCP狀態(tài)報(bào)告用于向發(fā)送方反饋PDCP數(shù)據(jù)PDU的接收情況，格式如圖4-6所示。圖4-6 PDCP狀態(tài)報(bào)告PDCP狀態(tài)報(bào)告中的FMS字段表示尚未收到的PDU中SN的最小值，PDU接收位圖中的每一比特表示FMS

6、對(duì)應(yīng)的PDU之后的每一個(gè)PDU的接收情況，比特值為0表示其對(duì)應(yīng)的PDU尚未接收到，比特值為1表示其對(duì)應(yīng)的PDU已經(jīng)接收到。10使用頭壓縮的目的是減少傳輸應(yīng)用層的冗余數(shù)據(jù)，以節(jié)省寶貴的空中接口資源。頭壓縮僅應(yīng)用于數(shù)據(jù)平面的PDCP PDU。PDCP子層是否使用頭壓縮由高層負(fù)責(zé)配置。目前LTE的PDCP子層僅支持ROHC頭壓縮協(xié)議。ROHC協(xié)議框架中對(duì)應(yīng)于多種高層協(xié)議分別定義了所使用的頭壓縮算法，其參考協(xié)議號(hào)見(jiàn)表4-1。4.2.2 頭壓縮11表4-1 頭壓縮協(xié)議 算 法 標(biāo) 識(shí) 用 途 協(xié) 議 號(hào) 0 x0000 無(wú)壓縮 RFC 4995 0 x0001 RTP/UDP/IP RFC 3095，R

7、FC 4815 0 x0002 UDP/IP RFC 3095，RFC 4815 0 x0003 ESP/IP RFC 3095，RFC 4815 0 x0004 IP RFC 3843，RFC 4815 0 x0006 TCP/IP RFC 4996 0 x0101 RTP/UDP/IP RFC 5225 0 x0102 UDP/IP RFC 5225 0 x0103 ESP/IP RFC 5225 0 x0104 IP RFC 5225 12控制平面的PDCU PDU和用戶平面的PDCP數(shù)據(jù)PDU都擁有一個(gè)SN字段，PDCP子層的發(fā)送和接收實(shí)體就是通過(guò)設(shè)置和檢查SN字段來(lái)實(shí)現(xiàn)PDCP PD

8、U的按序發(fā)送和接收。PDCP子層在發(fā)送側(cè)和接收側(cè)分別維護(hù)一個(gè)重排序窗口，重排序窗口的大小是SN范圍的一半。當(dāng)SN為04095時(shí)，即“最大_PDCP_SN”的值為4095時(shí)，重排序窗口的大小為2048。 在非切換狀態(tài)下，RLC子層為PDCP子層提供按序提交和重復(fù)包丟棄服務(wù)。而在切換狀態(tài)下，由于UE與兩個(gè)eNode B同時(shí)通信，因此其RLC子層無(wú)法保證按序提交和重復(fù)包丟棄，從而需要由PDCP子層來(lái)完成這些功能。 下面以UE側(cè)的操作為例說(shuō)明PDCP子層的發(fā)送和接收流程。 4.2.3 數(shù)據(jù)傳輸流程 131發(fā)送流程 UE側(cè)PDCP PDU的發(fā)送流程如圖4-7所示。 14PDCP PDU的接收流程根據(jù)數(shù)據(jù)

9、映射到數(shù)據(jù)無(wú)線承載（DRB）還是信令無(wú)線承載（SRB），以及使用RLC確認(rèn)模式還是非確認(rèn)模式而有所不同。PDCP子層接收側(cè)的加密/解密和一致性檢查功能都使用由RX_HFN和PDCP SN組成的32bit COUNT值實(shí)現(xiàn)，因此在接收存在亂第 4 章 空中接口和 RRC 技術(shù) 211 序的情況下，接收方需要根據(jù)接收到的PDCP PDU的SN與接收窗口的關(guān)系得到正確的RX_HFN，從而生成正確的COUNT值進(jìn)行解密和一致性檢查。 在數(shù)據(jù)無(wú)線承載上采用RLC確認(rèn)模式時(shí)，由于存在RLC PDU重傳，因此需要由PDCP子層保證PDCP SDU的按序提交和重復(fù)丟棄。數(shù)據(jù)無(wú)線承載上采用RLC確認(rèn)模式的數(shù)據(jù)接

10、收流程如圖4-8所示。 數(shù)據(jù)無(wú)線承載上采用RLC非確認(rèn)模式的接收流程如圖4-9所示。 信令無(wú)線承載上的數(shù)據(jù)接收流程如圖4-10所示。 2接收流程 15圖4-8 數(shù)據(jù)無(wú)線承載RLC確認(rèn)模式接收流程圖16圖 4-9 數(shù)據(jù)無(wú)線承載RLC非確認(rèn)模式接收流程圖17圖 4-10 信令無(wú)線承載接收流程圖18RLC子層為來(lái)自上層的用戶數(shù)據(jù)和控制數(shù)據(jù)提供可靠的傳輸服務(wù)。RLC子層的功能由第 4 章 空中接口和 RRC 技術(shù)213RLC實(shí)體實(shí)現(xiàn)。RLC實(shí)體可以被配置為3種模式：透明模式（TM）、非確認(rèn)模式（UM）和確認(rèn)模式（AM），即RLC子層能夠提供3種模式的數(shù)據(jù)傳輸服務(wù)。確認(rèn)模式可以對(duì)未正確接收的RLC PDU通過(guò)ARQ機(jī)制進(jìn)行重傳，從而實(shí)現(xiàn)數(shù)據(jù)的無(wú)差錯(cuò)按序傳輸，可滿足基于TCP的FTP等高層協(xié)議對(duì)無(wú)差錯(cuò)傳輸?shù)男枨?。非確認(rèn)模式可以向上層提供按序傳輸服務(wù)，對(duì)丟失的PDU不進(jìn)行重傳。非確認(rèn)模式適用于VoIP等可容忍一些差錯(cuò)但對(duì)時(shí)延要求很高的應(yīng)用。