r15 38 323 分組數(shù)據(jù)匯聚協(xié)議pdcp規(guī)范_h

1、 3GPPTS 38.323V15.2.0(2018-6)技術(shù)規(guī)范3rd Generation Partnership Project;無線接入網(wǎng)技術(shù)規(guī)范組; NR;分組數(shù)據(jù)匯聚協(xié)議（PDCP）規(guī)范(Release15)關(guān)鍵字：3GPP，新空口，NG-RAN版權(quán)聲明本文檔英文原版出自3GPP官方，由5G哥 原創(chuàng)翻譯。 只能在公眾號 5G通信 發(fā)布，除非5G哥 授權(quán)，否則不得在任何公開媒體傳播，分享到朋友圈不需要授權(quán)。 2018,翻譯：5G哥（微信私號：iam5gge 獲取授權(quán)請聯(lián)系），版權(quán)所有。 23GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信內(nèi)容目錄

2、5范圍6參考6定義和縮寫6定義6縮略語7一般性描述7介紹7構(gòu)架7PDCP結(jié)構(gòu)7PDCP實體8服務(wù)9向上層提供的服務(wù)9來自較低層的服務(wù)9功能10流程10PDCP實體處理10PDCP實體建立10PDCP實體重建10PDCP實體發(fā)布11數(shù)據(jù)傳輸12傳輸操作12接收操作13從較低層接收PDCP數(shù)據(jù)PDU時的操作13t-Reordering到期時的操作14重新配置t-Reordering的值時的操作14SDU丟棄14狀態(tài)報告15傳輸操作15接收操作15數(shù)據(jù)恢復15數(shù)據(jù)量計算15標頭壓縮和解壓縮16支持的頭壓縮協(xié)議和配置文件16頭壓縮的配置17協(xié)議參數(shù)17標頭壓縮17標頭解壓18PDCP控制PDU用于散布

3、ROHC反饋18傳輸操作18接收操作18加密和18完整性保護和驗證18處理未知，無法預料和錯誤的協(xié)議數(shù)據(jù)19PDCP重復19激活/停用PDCP重復19前言1233.13.244.14.24.2.14.2.24.34.3.14.3.24.455.15.1.15.1.25.1.35.25.2.15.2.25.2.2.15.2.2.25.2.2.35.35.45.4.15.4.25.55.65.75.7.15.7.25.7.35.7.45.7.55.7.65.7.6.15.7.6.25.85.95.105.115.11.15.11.23GPP 33GPP TS 38.323V15.2.0(2018-

4、6)版本：R15中文翻譯：5G通信66.16.1.16.1.26.26.2.16.2.26.2.2.16.2.2.26.2.2.36.2.36.2.3.16.2.3.26.36.3.16.3.26.3.36.3.46.3.56.3.66.3.76.3.86.3.96.3.106.3.1177.17.27.3協(xié)議數(shù)據(jù)單元，格式和參數(shù)20協(xié)議數(shù)據(jù)單元20數(shù)據(jù)PDU20控制PDU20格式20一般性描述20數(shù)據(jù)PDU20SRB的數(shù)據(jù)PDU20具有12位PDCP SN的DRB的數(shù)據(jù)PDU21具有18位PDCP SN的DRB的數(shù)據(jù)PDU21控制PDU22用于PDCP狀態(tài)報告的控制PDU22用于散布ROHC

5、反饋的控制PDU22參數(shù)23一般性描述23PDCP SN23DATA23MAC-I23COUNT23R24D/C24PDU type24FMC24Bitmap24Interspersed ROHC feedback25狀態(tài)變量，常量和定時器25狀態(tài)變量25常量25計時器25附件A（資料性附錄）：更新記錄263GPP 43GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信前言 該技術(shù)規(guī)范由 3rd Generation Partnership Project (3GPP) 制作.本文的內(nèi)容需要在TSG范圍內(nèi)開展工作，并且可能在TSG正式批準后發(fā)生變化。如果TS

6、G修改了本文的內(nèi)容， TSG將重新發(fā)布新的版本，其中發(fā)布日期的標識和版本號的增加規(guī)則如下： 版本號x.y.z代表意義:x第一個是數(shù)字:1提交給TSG 的討論內(nèi)容;2提交給TSG 批準的內(nèi)容;3或更大的數(shù)字，代表TSG 已批準的內(nèi)容，但保留修改權(quán)限.y它如果改變，表示有實質(zhì)性的技術(shù)改進、更正或更新, 例如有重要更新時，本數(shù)字會增加.z如果只是文檔編輯性、描述性內(nèi)容的更新，則只有這個數(shù)字會更新。 3GPP 53GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信1范圍本文檔提供了分組數(shù)據(jù)匯聚協(xié)議（PDCP）的描述。2參考以下文件載有通過本文中的參考構(gòu)成本文件條款的

7、規(guī)定。-參考文獻是特定的（由出版日期，版本號，版本號等標識）或非參考文獻- 具體。-具體參考，后續(xù)修訂不適用。-對于非特定參考，最新版本適用。 在參考3GPP文檔（包括GSM文檔）的情況下，非特定參考隱含地指代與本文檔相同的版本中的該文檔的最新版本。 13GPP TR 21.905：“3GPP規(guī)范的詞匯表”。23GPP TS 38.300：“NG 無線 接入網(wǎng)絡(luò);總體描述”。33GPP TS 38.331：“NR 無線資源控制（RRC）;協(xié)議規(guī)范”。 43GPP TS 38.321：“NR Medium 接入 Control（MAC）protocol specification”。 53GPP

8、 TS 38.322：“NR 無線 鏈路控制（RLC）協(xié)議規(guī)范”。63GPP TS 33.501：“5G系統(tǒng)的安全架構(gòu)和流程”。7IETF RFC 5795：“RObust Header Compression（ROHC）框架”。 8IETF RFC 3095：“RObust Header Compression（ROHC）：框架和四個配置文件：RTP， UDP，ESP和未壓縮”。 9IETF RFC 4815：“RObust Header Compression（ROHC）：對RFC 3095的更正和澄清”。 10IETF RFC 6846：“RObust Header Compressio

9、n（ROHC）：TCP / IP配置文件（ROHC- TCP）”。 11IETF RFC 5225：“RObust Header Compression（ROHC）版本2：RTP，UDP，IP，ESP和UDP Lite的配置文件”。 123GPP TS 36.321：“Evolved Universal Terrestrial 無線 接入（E-UTRA）Medium 接入Control（MAC）protocol protocol” 。 3定義和縮寫3.1定義出于本文件的目的，3GPP TR 21.905 1中給出的術(shù)語和定義適用。 在3GPP TR 21.905 1中，本文件中定義的術(shù)語優(yōu)先于

10、相同術(shù)語的定義（如果有的話）。 AM DRB：利用RLC AM的數(shù)據(jù)無線承載。支承載：無線協(xié)議位于MgNB或SgNB中的承載，分別使用MgNB或SgNB資源。 3GPP 63GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信PDCP數(shù)據(jù)量：PDCP實體中可用于傳輸?shù)臄?shù)據(jù)量。分離承載：在雙連接中，承載，其無線協(xié)議位于MgNB和SgNB中，以使用MgNB和SgNB資源。 UM DRB：利用RLC UM的數(shù)據(jù)無線承載。3.2縮略語出于本文件的目的，3GPP TR 21.905 1中給出的縮寫適用以下內(nèi)容。定義的縮寫優(yōu)先于相同縮寫的定義（如果有的話）。 在3GPP

11、TR 21.905 1中，本文檔中AM CID DRBgNB HFN IETF IP MAC MAC-I PDCP PDU RB RFC RLC ROHC RRC RTP SAP SDUSN SRB TCP UDP UEUM X-MAC已確認模式 上下文標識符 承載用戶平面數(shù)據(jù)的數(shù)據(jù)無線承載NR nodeB. 超幀號 國際互聯(lián)網(wǎng)工程任務(wù)組互聯(lián)網(wǎng)協(xié)議 媒體接入控制 完整性的消息驗證代碼分組數(shù)據(jù)匯聚協(xié)議 協(xié)議數(shù)據(jù)單位無線承載 請求反饋 無線 鏈路控制RObust標頭壓縮無線資源控制實時協(xié)議 服務(wù)接入點服務(wù)數(shù)據(jù)單位序列號 信令無線承載攜帶控制平面數(shù)據(jù)傳輸控制協(xié)議 用戶數(shù)據(jù)報協(xié)議用戶設(shè)備 未確認模式

12、計算過的MAC-I 4一般性描述4.1介紹本文檔描述了PDCP的功能。4.2構(gòu)架4.2.1PDCP結(jié)構(gòu)圖4.2.1.1表示PDCP子層的一種可能結(jié)構(gòu); 它不應(yīng)該限制實施。議架構(gòu)。 該圖基于TS 38.300 2中定義的無線接口協(xié)3GPP 73GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信圖4.2.1-1：PDCP層，結(jié)構(gòu)視圖 PDCP子層用于映射在DCCH和DTCH類型的邏輯信道上的RB。 PDCP子層 PDCP子層由上層TS 38.331 3配置。不用于任何其他類型的邏輯信道。 每個RB（SRB0除外）與一個PDCP實體相關(guān)聯(lián)。 每個PDCP實體根據(jù)R

13、B特性（例如，單向/雙向或分離/離） 或RLC模式與一個，兩個或四個RLC實體相關(guān)聯(lián)。 對于非拆分承載，每個PDCP實體與一個UM RLC實體，兩個UM RLC實體（每個方向一個）或一個AM RLC實體相關(guān)聯(lián)。 對于分離承載，每個PDCP實體與兩個UM RLC實體（針對相同方向），四個UM RLC實體（針對每個方向兩個）或兩個AM RLC實體（針對相同方向）相關(guān)聯(lián)。 4.2.2PDCP實PDCP實體于PDCP子層中。 可以為UE定義幾個PDCP實體。 每個PDCP實體攜帶一個無線承載的數(shù)據(jù)。 PDCP實體與控制平面或用戶平面相關(guān)聯(lián)，這取決于它攜帶數(shù)據(jù)的無線承載。 圖4.2.2.1表示PDCP子

14、層的PDCP實體的功能視圖; 它不應(yīng)該限制實施。 該圖基于TS 38.300 2中定義的無線接口協(xié)議架構(gòu)。 對于分離承載，在發(fā)送PDCP實體中執(zhí)行路由。3GPP 83GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信圖4.2.2-1：PDCP層，功能視圖 4.3服務(wù)4.3.1向上層提供的服務(wù)PDCP層向RRC或SDAP層提供其服務(wù)。 PDCP向上層提供以下服務(wù)： -用戶平面數(shù)據(jù)的傳輸;-控制平面數(shù)據(jù)的傳輸;-標頭壓縮;-加密;-完整性保護。支持的最大PDCP SDU大小為9000字節(jié)。 支持的最大PDCP控制PDU大小為9000字節(jié)。 4.3.2預期來自較低

15、層的服務(wù)PDCP實體期望來自每個RLC實體的較低層的以下服務(wù)（詳細描述見5）： -公認的數(shù)據(jù)傳輸服務(wù)，包括成功交付PDCP PDU的指示; 3GPP 93GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信-未經(jīng)確認的數(shù)據(jù)傳輸服務(wù)。4.4功能PDCP層支持以下功能：-數(shù)據(jù)傳輸（用戶平面或控制平面）;-維護PDCP SN;-使用ROHC協(xié)議進行報頭壓縮和解壓縮;-加密和;-完整性保護和完整性驗證;-基于定時器的SDU丟棄;-分裂承載，路由;-復制;-Reordering和有序交付;-無序傳遞;-重復丟棄。5流程5.1PDCP實體處理5.1.1PDCP實體建立當上

16、層請求為無線承載建立PDCP實體時，UE應(yīng)：-為無線承載建立PDCP實體;-將PDCP實體的狀態(tài)變量設(shè)置為初始值;-按照5.2中的流程進行操作。5.1.2PDCP實體重建當上層請求重新建立PDCP實體時，UE應(yīng)另外執(zhí)行本節(jié)中描述的過程。 流程。 執(zhí)行本節(jié)中的步驟后，UE應(yīng)遵循5.2中的當上層請求重建PDCP實體時，發(fā)送PDCP實體應(yīng)：-對于UM DRB和AM DRB，重置上行鏈路的報頭壓縮協(xié)議，如果未在TS 38.331 3中配置drb- ContinueROHC，則以Umode中的IR狀態(tài)（如RFC 3095 8和RFC 4815 9中所定義）啟動） 。 -對于UM DRB和SRB，將TX_

17、NEXT設(shè)置為初始值;-對于SRB，丟棄所有存儲的PDCP SDU和PDCP PDU;3GPP 103GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信-在PDCP實體重建過程中應(yīng)用上層提供的加密算法和密鑰;-在PDCP實體重建過程中應(yīng)用上層提供的完整性保護算法和密鑰; -對于UM DRB，對于已經(jīng)與PDCP SN關(guān)聯(lián)但相應(yīng)PDU先前未提交給較低層的每個PDCP SDU： -考慮從上層接收的PDCP SDU;-在子條款5.2.1中的數(shù)據(jù)提交過程之后，在PDCP重建之前按照與PDCP SDU相關(guān)聯(lián)的COUNT值的升序執(zhí)行PDCP SDU的傳輸，而不重新啟動di

18、scardTimer; -對于AM DRB，來自第一PDCP SDU的相應(yīng)PDCP數(shù)據(jù)PDU的成功傳送尚未被較低層確認，按照COUNT值的升序執(zhí)行已經(jīng)與PDCP SN相關(guān)聯(lián)的所有PDCP SDU的重傳或傳輸在PDCP實體重建之前到PDCP SDU，如下所述： -按照子條款5.7.4的規(guī)定執(zhí)行PDCP SDU的報頭壓縮;-根據(jù)子條款5.9和5.8中規(guī)定的與該PDCP SDU相關(guān)的COUNT值執(zhí)行PDCP SDU的完整性保護和加密; -按照子條款5.2.1中的數(shù)據(jù)提交流程，將生成的PDCP數(shù)據(jù)PDU提交給下層。 當上層請求重建PDCP實體時，接收PDCP實體應(yīng)：-根據(jù)子條款5.2.2.1的規(guī)定，處

19、理由于重建較低層而從較低層接收的PDCP數(shù)據(jù)PDU; -對于SRB，丟棄所有存儲的PDCP SDU和PDCP PDU;-對于SRB和UM DRB，如果正在運行t-Reordering：-停止并重置t-Reordering;-對于UM DRB，在執(zhí)行報頭解壓縮后，按照相關(guān)COUNT值的升序?qū)⑺写鎯Φ腜DCP SDU傳送到上層; -對于AM DRB，如果未在TS 38.331 3中配置drb-ContinueROHC，則對所有存儲的PDCP SDU執(zhí)行報頭解壓縮; -對于UM DRB和AM DRB，如果未在TS 38.331 3中配置drb-ContinueROHC，則重置下行鏈路的報頭壓縮協(xié)議

20、并以Umode中的NC狀態(tài)（如RFC 3095 8和RFC 4815 9中的定義）開始） ; -對于UM DRB和SRB，將RX_NEXT和RX_DELIV設(shè)置為初始值;-在PDCP實體重建過程中應(yīng)用上層提供的加密算法和密鑰;-在PDCP實體重建過程中應(yīng)用上層提供的完整性保護算法和密鑰。 5.1.3PDCP實體發(fā)布當上層請求為無線承載發(fā)布PDCP實體時，UE應(yīng)：-丟棄發(fā)送PDCP實體中所有存儲的PDCP SDU和PDCP PDU;-對于UM DRB和AM DRB，如果之前沒有解壓縮，則在執(zhí)行報頭解壓縮之后，以相關(guān)COUNT值的升序?qū)⒋鎯υ诮邮誔DCP實體中的PDCP SDU遞送到上層; -釋放

21、無線承載的PDCP實體。5.2數(shù)據(jù)傳輸5.2.1傳輸操作在從上層接收PDCP SDU時，發(fā)送PDCP實體應(yīng)：3GPP 113GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信-啟動與此PDCP SDU關(guān)聯(lián)的discardTimer（如果已配置）。 對于從上層接收的PDCP SDU，發(fā)送PDCP實體應(yīng)：-將對應(yīng)于TX_NEXT的COUNT值與該PDCP SDU相關(guān)聯(lián);注1：將超過一半的連續(xù)PDCP SDU的PDCP SN空間與PDCP SN相關(guān)聯(lián)，例如，在沒有確認的情況下丟棄或發(fā)送PDCP SDU，可能導致HFN去同步問題。 如何防止HFN失步問題由UE實現(xiàn)。

22、 -按照子條款5.7.4的規(guī)定執(zhí)行PDCP SDU的報頭壓縮;-執(zhí)行完整性保護，并分別使用子條款5.9和5.8中規(guī)定的TX_NEXT進行加密; -將PDCP數(shù)據(jù)PDU的PDCP SN設(shè)置為TX_NEXT模2PDCP-SN-尺寸; -將TX_NEXT遞增1;-將生成的PDCP數(shù)據(jù)PDU提交到下層，如下所示。當向下層提交PDCP PDU時，發(fā)送PDCP實體應(yīng)：-如果發(fā)送PDCP實體與一個RLC實體相關(guān)聯(lián)：-將PDCP PDU提交給關(guān)聯(lián)的RLC實體;-否則，如果發(fā)送的PDCP實體與兩個RLC實體相關(guān)聯(lián)：-如果PDCP重復被激活：-如果PDCP PDU是PDCP數(shù)據(jù)PDU：-復制PDCP數(shù)據(jù)PDU并將

23、PDCP數(shù)據(jù)PDU提交給兩個相關(guān)的RLC實體; -其他：-將PDCP控制PDU提交給主RLC實體;-其他：-如果兩個相關(guān)的RLC實體屬于不同的小區(qū)組; 和-如果兩個相關(guān)RLC實體中初始傳輸?shù)拇幚鞵DCP數(shù)據(jù)量和RLC數(shù)據(jù)量的總量（如TS 38.322 5中所述）等于或大于ul-DataSplitThreshold： -將PDCP PDU提交給主RLC實體或輔助 RLC實體;-其他：-將PDCP PDU提交給主RLC實體。注2：如果發(fā)送PDCP實體與兩個RLC實體相關(guān)聯(lián)，則UE應(yīng)當在接收來自較低層的請求之前最小化提交給較 低層的PDCP PDU的量，并最小化提交給兩個相關(guān)RLC實體的PDCP

24、PDU之間的PDCP SN間隙以最小化PDCPReordering。延遲接收PDCP實體。 5.2.2接收操作5.2.2.1從較低層接收PDCP數(shù)據(jù)PDU時的操作在本節(jié)中，使用以下定義：-HFN（狀態(tài)變量）：狀態(tài)變量的HFN部分（即，最高有效位的數(shù)量等于HFN長度）; 3GPP 123GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信-SN（狀態(tài)變量）：狀態(tài)變量的SN部分（即，等于PDCP SN長度的最低有效位數(shù)）; -RCVD_SN：接收的PDCP數(shù)據(jù)PDU的PDCP SN，包括在PDU頭中;-RCVD_HFN：接收到的PDCP數(shù)據(jù)PDU的HFN，由接收P

25、DCP實體計算; -RCVD_COUNT：接收到的PDCP數(shù)據(jù)PDU的COUNT = RCVD_HFN，RCVD_SN。 在從較低層接收PDCP數(shù)據(jù)PDU時，接收PDCP實體應(yīng)確定所接收的PDCP數(shù)據(jù)PDU的COUNT值，即RCVD_COUNT，如 下： -如果RCVD_SN = SN（RX_DELIV）+ Window_Size：-RCVD_HFN = HFN（RX_DELIV） - 1。-其他：-RCVD_HFN = HFN（RX_DELIV）;-RCVD_COUNT = RCVD_HFN，RCVD_SN。在確定所接收的PDCP數(shù)據(jù)PDU = RCVD_COUNT的COUNT值之后，接收P

26、DCP實體應(yīng)： -使用COUNT = RCVD_COUNT執(zhí)行PDCP數(shù)據(jù)PDU的和完整性驗證; -如果完整性驗證失敗：-表示上層的完整性驗證失敗;-丟棄PDCP數(shù)據(jù)PDU;-如果RCVD_COUNT = RX_NEXT：-將RX_NEXT更新為RCVD_COUNT + 1。-如果配置了outOfOrderDelivery： -將生成的PDCP SDU傳遞給上層。-如果RCVD_COUNT = RX_DELIV：-如果之前沒有解壓縮，則在執(zhí)行報頭解壓縮之后以相關(guān)COUNT值的升序遞送到上層; -所有存儲的PDCP SDU具有從COUNT = RX_DELIV開始的連續(xù)關(guān)聯(lián)的COUNT值; -將

27、RX_DELIV更新為尚未傳送到上層的第一個PDCP SDU的COUNT值，COUNT值 RX_DELIV; -如果t-Reordering正在運行，并且如果RX_DELIV = RX_REORD： -停止并重置tReordering。3GPP 133GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信-如果t-Reordering沒有運行（包括因上述動作而停止t-Reordering的情況），以及RX_DELIV RX_NEXT： -將RX_REORD更新為RX_NEXT;-開始Reordering。5.2.2.2t-Reordering到期時的操作當t-R

28、eordering到期時，接收PDCP實體應(yīng)：-在執(zhí)行標頭解壓縮后，如果在以下情況下未解壓縮，則按相關(guān)COUNT值的升序遞送到上層： -所有存儲的PDCP SDU具有相關(guān)的COUNT值 = RX_REORD; -如果RX_DELIV RX_NEXT：-將RX_REORD更新為RX_NEXT;-開始Reordering。5.2.2.3重新配置t-Reordering的值時的操作當t-Reordering正在運行時，上層重新配置t-Reordering的值時，接收PDCP實體應(yīng)： -將RX_REORD更新為RX_NEXT;-停止并重新啟動t-Reordering。5.3SDU丟棄當discardT

29、imer到期為PDCP SDU，或者PDCP狀態(tài)報告確認PDCP SDU的成功傳送時，發(fā)送PDCP實體應(yīng)丟棄PDCP SDU以及相應(yīng)的PDCP數(shù)據(jù)PDU。 如果相應(yīng)的PDCP數(shù)據(jù)PDU已經(jīng)提交給較低層，則丟棄被指示給較低層。 對于SRB，當上層請求丟棄PDCP SDU時，PDCP實體應(yīng)丟棄所有存儲的PDCP SDU和PDCP PDU。 注意：丟棄已經(jīng)與PDCP SN相關(guān)聯(lián)的PDCP SDU導致所發(fā)送的PDCP數(shù)據(jù)PDU中的SN間隙，這增加了接收PDCP 實體中的PDCPReordering延遲。 UE實現(xiàn)如何在SDU丟棄后最小化SN間隙。 5.4狀態(tài)報告5.4.1傳輸操作對于上層配置的AM D

30、RB在上行鏈路中發(fā)送PDCP狀態(tài)報告（TS 38.331 3中的statusReportRequired），接收PDCP實體應(yīng)在以下情況下觸發(fā)PDCP狀態(tài)報告： -上層請求重建PDCP實體;-上層請求PDCP數(shù)據(jù)恢復。如果觸發(fā)了PDCP狀態(tài)報告，則接收PDCP實體應(yīng)：-編制PDCP狀態(tài)報告，如下所示：3GPP 143GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信-將FMC字段設(shè)置為RX_DELIV;-如果RX_DELIV 15則LARGE_CIDS = TRUE，否則LARGE_CIDS = FALSE; -PROFILES（M）：配置文件用于定義UE允

31、許使用的配置文件。 支持的配置文件列表在5.7.1節(jié)中描述。參數(shù)PROFILES由上層配置（TS 38.331 3中的上行鏈路和下行鏈路的配置文件）; -FEEDBACK_FOR（N / A）：這是對兩個壓縮端點之間相反方向的信道的引用，并指示發(fā)送的任何反饋所引用的信道。 在該PDCP實體的一個ROHC信道上收到的反饋應(yīng)始終指向該相同PDCP實體的相反方向的ROHC信道; -MRRU（N / A）：不使用ROHC分割。5.7.4標頭壓縮如果配置了頭壓縮，則頭壓縮協(xié)議會生成兩種類型的輸出包： -壓縮包，每個包與一個PDCP SDU相關(guān)聯(lián);-與PDCP SDU無關(guān)的獨立分組，即散布的ROHC反饋。

32、壓縮分組與相關(guān)PDCP SDU相同的PDCP SN和COUNT值相關(guān)聯(lián)。 如果包括在PDCP SDU中，則報頭壓縮不適用于SDAP報頭和SDAP控制PDU。 散布的ROHC反饋與PDCP SDU無關(guān)。 它們與PDCP SN無關(guān)，也未加密。 注意：如果已經(jīng)為壓縮流建立了MAX_CID個ROHC上下文，并且新的IP流與任何已建立的ROHC上下文不匹配，則壓縮器應(yīng)該將新的IP流與為現(xiàn)有壓縮流分配的ROHC CID之一相關(guān)聯(lián)或發(fā)送PDCP。屬于IP的SDU作為未壓縮分組流動。 5.7.5標頭解壓如果上層為與用戶平面數(shù)據(jù)相關(guān)聯(lián)的PDCP實體配置報頭壓縮，則在執(zhí)行之后，通過報頭壓縮協(xié)議對PDCP數(shù)據(jù)PDU

33、進行解壓縮，如子條款5.8中所述。 如果包括在PDCP數(shù)據(jù)PDU中，則報頭解壓縮不適用于SDAP報頭和SDAP 控制PDU。 5.7.6PDCP控制PDU用于散布ROHC反饋5.7.6.1傳輸操作當報頭壓縮協(xié)議產(chǎn)生散布的ROHC反饋時，發(fā)送PDCP實體應(yīng)： -向子層提交子條款6.2.3.2中規(guī)定的相應(yīng)PDCP控制PDU，即不關(guān)聯(lián)PDCP SN，也不執(zhí)行加密。 5.7.6.2接收操作在接收到來自較低層的散布ROHC反饋的PDCP控制PDU時，接收PDCP實體應(yīng)： -將相應(yīng)的散布ROHC反饋傳遞給頭壓縮協(xié)議而不執(zhí)行。3GPP 173GPP TS 38.323V15.2.0(2018-6)版本：R1

34、5中文翻譯：5G通信5.8加密和加密功能包括加密和，并且如果配置，則在PDCP中執(zhí)行。 加密的數(shù)據(jù)單元是PDCP數(shù)據(jù)PDU的數(shù)據(jù)部分（參見子條款6.3.3），除了SDAP報頭和SDAP控制PDU（如果包含在PDCP SDU中）和MAC-I（參見子條款6.3.4） 。加密不適用于PDCP控制PDU。 PDCP實體使用的加密算法和密鑰由上層TS 38.331 3配置，加密方法應(yīng)按TS 33.501 6的規(guī)定應(yīng)用。 加密功能由上層TS 38.331 3激活。 當安全性被激活時，加密功能應(yīng)分別應(yīng)用于上層TS 38.331 3為下行鏈路和上行鏈路指示的所有PDCP數(shù)據(jù)PDU。 對于下行鏈路和上行鏈路加密

35、和，PDCP用于加密所需的參數(shù)在TS 33.501 6中定義并輸入到加密算法。 加密功能所需的輸入包括COUNT值和DIRECTION（傳輸方向：根據(jù)TS 33.501 6的規(guī)定設(shè)置）。上層TS 38.331 3提供的PDCP所需的參數(shù)如下所示： -BEARER（定義為TS 33.501 6中的無線承載標識符。它將使用RB身份-1，如TS 38.331 3中所述）; -KEY（控制平面和用戶平面的加密密鑰分別為Krrcenc和Kupenc）。 5.9完整性保護和驗證 完整性保護功能包括完整性保護和完整性驗證，并在PDCP中執(zhí)行（如果已配置）。 完整性保護的數(shù)據(jù)單元是加密前的PDU報頭和PDU的

36、數(shù)據(jù)部分。 完整性保護始終應(yīng)用于SRB的PDCP數(shù)據(jù)PDU。 完整性保護應(yīng)用于配置了完整性保護的DRB的PDCP數(shù)據(jù)PDU。 完整性保護不適用于PDCP控制PDU。 PDCP實體使用的完整性保護算法和密鑰由上層TS 38.331 3配置，完整性保護方法應(yīng)按TS 33.501 6的規(guī)定應(yīng)用。 完整性保護功能由上層TS 38.331 3激活。 當安全性被激活時，完整性保護功能應(yīng)分別應(yīng)用于包括上層TS 38.331 3指示的PDU的所有PDU以及下行鏈路和上行鏈路之后的所有PDU。 注意：由于激活完整性保護功能的RRC消息本身是用該RRC消息中包括的配置進行完整性保護的，因此在 可以對接收到消息的P

37、DU執(zhí)行完整性保護驗證之前，首先需要由RRC對該消息進行解碼。 對于下行鏈路和上行鏈路完整性保護和驗證，PDCP用于完整性保護所需的參數(shù)在TS 33.501 6中定義，并輸入到完整性保護算法。 完整性保護功能所需的輸入包括COUNT值和DIRECTION（傳輸方向：根據(jù)TS 33.501 6 中的規(guī)定設(shè)置）。 PDCP所需的參數(shù)由上層TS 38.331 3提供，如下所示： -BEARER（定義為TS 33.501 6中的無線承載標識符。它將使用RB身份-1，如TS 38.331 3中所述）; -KEY（控制平面和用戶平面的完整性保護關(guān)鍵字分別為Krrcint和Kupint）。 在傳輸時，UE計

38、算MAC-I字段的值，并且在接收時，它通過基于如上所述的輸入?yún)?shù)計算X-MAC來驗證PDCP數(shù)據(jù)PDU的完整性。 如果計算出的X-MAC對應(yīng)于收到的MAC-I，則成功驗證完整性保護。 5.10處理未知，無法預料和錯誤的協(xié)議數(shù)據(jù) 當接收到包含保留值或無效值的PDCP PDU時，接收PDCP實體應(yīng)： -丟棄收到的PDU。5.11PDCP重復5.11.1激活/停用PDCP重復對于配置了pdcp-Duplication的PDCP實體，發(fā)送PDCP實體應(yīng)： 3GPP 183GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信-對于SRB：-激活PDCP復制;-對于DRB

39、：-如果指示激活PDCP重復：-激活PDCP復制;-如果指示停用PDCP重復：-停用PDCP重復。5.11.2重復PDU丟棄對于配置了pdcp-Duplication的PDCP實體，發(fā)送PDCP實體應(yīng)： -如果兩個相關(guān)的AM RLC實體之一確認成功傳送PDCP數(shù)據(jù)PDU： -指示另一個AM RLC實體丟棄重復的PDCP數(shù)據(jù)PDU;-如果指示停用PDCP重復：-指示輔助 RLC實體丟棄所有重復的PDCP數(shù)據(jù)PDU。6協(xié)議數(shù)據(jù)單元，格式和參數(shù)6.1協(xié)議數(shù)據(jù)單元 6.1.1數(shù)據(jù)PDU除PDU頭之外，PDCP數(shù)據(jù)PDU還用于傳達以下一個或多個：-用戶平面數(shù)據(jù);-控制平面數(shù)據(jù);-一個MAC-I。6.1.

40、2控制PDU除PDU標頭外，PDCP控制PDU還用于傳達以下之一：-PDCP狀態(tài)報告;-穿插的ROHC反饋。6.2格式6.2.1一般性描述PDCP PDU是長度為字節(jié)對齊（即8位的倍數(shù)）的位串。 在子條款6.2的圖中，位串由表表示，其中最高有效位是表的第一行的最左位，最低有效位是表的最后一行的最右位，更一般性描述地說要從左到右讀取位串，然后 3GPP 193GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信按行的讀取順序讀取。 PDCP PDU內(nèi)的每個參數(shù)字段的比特順序用最左邊的比特中的第一個和最高有效比特以及最右邊比特中的最后和最低有效比特表示。 PDCP

41、 SDU是長度為字節(jié)對齊（即8位的倍數(shù)）的位串。 從第一位開始，壓縮或未壓縮的SDU被包括在PDCP數(shù)據(jù)PDU中。 6.2.2數(shù)據(jù)PDU6.2.2.1SRB的數(shù)據(jù)PDU圖6.2.2.1-1顯示了具有12位PDCP SN的PDCP數(shù)據(jù)PDU的格式。 此格式適用于SRB。 圖6.2.2.1-1：SRB的PDCP數(shù)據(jù)PDU格式 6.2.2.2具有12位PDCP SN的DRB的數(shù)據(jù)PDU圖6.2.2.2-1顯示了具有12位PDCP SN的PDCP數(shù)據(jù)PDU的格式。 此格式適用于UM DRB和AM DRB。3GPP 203GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G

42、通信圖6.2.2.2-1：具有12位PDCP SN的PDCP數(shù)據(jù)PDU格式 6.2.2.3具有18位PDCP SN的DRB的數(shù)據(jù)PDU圖6.2.2.3-1顯示了具有18位PDCP SN的PDCP數(shù)據(jù)PDU的格式。 此格式適用于UM DRB和AM DRB。圖6.2.2.3-1：具有18位PDCP SN的DRB的PDCP數(shù)據(jù)PDU格式 6.2.3控制PDU6.2.3.1用于PDCP狀態(tài)報告的控制PDU圖6.2.3.1-1顯示了攜帶一個PDCP狀態(tài)報告的PDCP控制PDU的格式。 此格式適用于AM DRB。 3GPP 213GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯

43、：5G通信圖6.2.3.1-1：PDCP狀態(tài)報告的PDCP控制PDU格式 6.2.3.2用于散布ROHC反饋的控制PDU圖6.2.3.2-1顯示了攜帶一個散布的ROHC反饋的PDCP控制PDU的格式。 此格式適用于UM DRB和AM DRB。 圖6.2.3.2-1：PDCP控制PDU用于散布ROHC反饋格式 6.3參數(shù)6.3.1一般性描述如果在每個字段的定義中沒有另外提及，則參數(shù)中的位應(yīng)解釋如下：最左邊的位串是第一個和最重要的，最右 邊的位是最后和最低有效位。 除非另有說明，否則整數(shù)用無符號整數(shù)的標準二進制編碼進行編碼。 在所有情況下，當在PDU中讀取時，位從MSB到LSB排序。 6.3.2PDCP SN長度：12或18位，如表6.3.2.1所示。 PDCP SN的長度由上層配置（TS 38.331 3中的pdcp-SN-Size）。 3GPP 223GPP TS 38.323V15.2.0(2018-6)版本：R15中文翻譯：5G通信 表6.3.2-1：PDCP SN長度6.3.3長度：可變DATA該字段包括以下之一：-未壓縮的PDCP SDU（用戶平面數(shù)據(jù)或控制平面數(shù)據(jù)）;-壓縮的PDCP SDU（僅限用戶平面數(shù)據(jù)）。6.3.4長度：32位MAC-