3gpp_pdcp中文協(xié)議36(編輯修改稿)
2025-07-03 17:23 本頁面
【文章內(nèi)容簡介】 P Data PDU，； 將Next_PDCP_RX_SN 置為接收到的PDCP SN值 + 1； 如果Next_PDCP_RX_SN Maximum_PDCP_SN：? 將Next_PDCP_RX_SN 置為0；? 將RX_HFN 增加1； 執(zhí)行已解密PDCP Data PDU的頭解壓縮（如果配置），； 將最后產(chǎn)生的PDCP SDU 遞交給上層?！?SRB過程對于SRB，在接收到低層的PDCP Data PDU以后，UE應(yīng)： 如果接收的PDCP SN Next_PDCP_RX_SN：? 使用基于RX_HFN + 1的COUNT值與接收到的PDCP SN值來解密PDU及確認PDU的完整性，； 否則：? 使用基于RX_HFN的COUNT值與接收到的PDCP SN值來解密此PDU及確認其完整性（如適用），； 如果完整性確認使用，并且成功通過；或者 如果完整性確認不適用：? 如果接收的PDCP SN Next_PDCP_RX_SN：o 將RX_HFN 增加1；? 將Next_PDCP_RX_SN 置為接收到的PDCP SN值 + 1；? 如果Next_PDCP_RX_SN Maximum_PDCP_SN：o 將Next_PDCP_RX_SN 置為0；o 將RX_HFN 增加1；? 將最后產(chǎn)生的PDCP SDU 遞交給上層； 否則，如果完整性確認適用，但是失?。? 丟棄接收到的PDCP Data PDU；? 將完整性確認失敗報告給上層?！?重建過程當上層請求一個PDCP重建時，UE應(yīng)為對應(yīng)的RLC模式額外再執(zhí)行一次本節(jié)所述的過程。在執(zhí)行完本節(jié)的過程后?！?UL數(shù)據(jù)傳輸過程 映射到RLC AM的DRB過程當上層請求一次PDCP重建時，UE應(yīng)： 重置上行鏈路的頭壓縮協(xié)議(如果已配置)； 在重建過程期間，使用加密算法及上層提供的key加密； 從第一個對應(yīng)的PDCP PDU成功傳遞但沒有被下層確認的PDCP SDU開始，在如下所述的PDCP重建之前，執(zhí)行所有從此PDCP SDU對應(yīng)的COUNT值開始，按COUNT值升序排列的PDCP SN值對應(yīng)的PDCP SDU的重傳或傳輸： 執(zhí)行PDCP SDU的頭壓縮（如果已配置），； 使用關(guān)聯(lián)于此PDCP SDU的COUNT值，加密此PDCP SDU，； 將最后產(chǎn)生的PDCP Data PDU傳遞給下層?！?映射到RLC UM的DRB過程當上層請求一次PDCP重建時，UE應(yīng)： 重置上行鏈路的頭壓縮協(xié)議（如果已配置）； 置Next_PDCP_TX_SN，及TX_HFN 為0； 在重建進程期間，使用加密算法及上層提供的key加密； 對于每一個已經(jīng)對應(yīng)于一個PDCP SN值，但相應(yīng)的PDU沒有事先傳遞給低層的PDCP SDU：? 認為此PDCP SDU是從上層接收而來；? 在PDCP重建之前，在不重啟discardTimer的情況下，按照與PDCP SDU關(guān)聯(lián)的COUNT值的升序傳輸PDCP SDU?！?SRB過程當上層請求一個PDCP重建時，UE應(yīng)： 置Next_PDCP_TX_SN和TX_HFN 為0； 丟棄所有存儲的PDCP SDU和PDCP PDU； 在重建進程期間，使用加密及完整性保護算法和上層提供的key進行加密。 DL數(shù)據(jù)傳輸過程 映射到RLC AM的DRB過程當上層請求一個PDCP重建時，UE應(yīng)： 處理由于下層重建而從下層接收來的PDCP Data PDU，； 重置下行鏈路的頭壓縮協(xié)議（如果已配置）； 在重建進程期間，使用加密算法和上層提供的key進行加密?！?映射到RLC UM的DRB過程當上層請求一個PDCP 重建時，UE應(yīng)： 處理由于下層重建而從下層接收來的PDCP Data PDU，； 重置下行鏈路的頭壓縮協(xié)議(如果已配置)； 置Next_PDCP_RX_SN和RX_HFN 為0； 在重建進程期間，使用加密算法和上層提供的key進行加密。 SRB過程當上層請求一個PDCP 重建時，UE應(yīng)： 丟棄由于下層重建而從下層接收來的PDCP Data PDU； 置Next_PDCP_RX_SN和RX_HFN 為0； 丟棄所有存儲的PDCP SDU 和PDCP PDU； 在重建進程期間，使用加密及完整性保護算法和上層提供的key進行加密?！?PDCP狀態(tài)上報 傳輸操作對于映射到RLC AM的無線承載，當上層請求一個PDCP重建時，UE應(yīng)： 如果此無線承載被上層配置用于在上行鏈路發(fā)送一個PDCP 狀態(tài)上報（statusReportRequired見[3]），在處理完由于下層重建而從下層接受來的PDCP Data PDU以后，UE按照如下的指示編譯此狀態(tài)上報，并將此狀態(tài)上報作為此傳輸?shù)牡谝粋€PDCP PDU傳遞給低層：? 將FMS域置為第一個丟失的PDCP SDU的PDCP SN值；? 如果至少有一個失序PDCP SDU被存儲，則分配一個Bitmap field，長度等于從第一個丟失的PDCP SDU（但不包括）開始直到最后一個失序的PDCP SDU（包括最后一個）的PDCP SN的個數(shù)，四舍五入到下一個8的倍數(shù)；? 將所有底層指示還未接收到的PDCP SDU以及任意解壓縮失敗的PDCP SDU在Bitmap field中對應(yīng)的區(qū)域置為“0”；? 對于其他的PDCP SDU，對應(yīng)的區(qū)域置為“1”?！?接收操作當在下行鏈路接收到一個PDCP 狀態(tài)上報時，對于映射到RLC AM的無線承載： 對于每個PDCP SDU，如果在Bitmap中對應(yīng)的bit位為“1”，或者相關(guān)聯(lián)的COUNT值小于FMS字段確定的PDCP SDU的COUNT值，則相應(yīng)PDCP SDU的成功傳輸將被確認， SDU?！?PDCP丟棄當用于PDCP SDU的discardTimer終止，或PDCP SDU的成功傳輸被PDCP狀態(tài)上報確認，UE應(yīng)丟棄此PDCP SDU連同對應(yīng)的PDCP PDU。如果對應(yīng)的PDCP PDU已經(jīng)成功傳遞給下層，則此丟棄需要指示給下層?！?頭壓縮與解壓縮 支持的頭壓縮協(xié)議與簡表（profile）頭壓縮協(xié)議基于可靠性頭壓縮（ROHC）框架[7]。存在多種頭壓縮算法，稱之為簡表，定義用于ROHC框架。每個簡表為特定的網(wǎng)絡(luò)層、傳輸層或上層集合（例如TCP/IP與RTP/UDP/IP）所專用。ROHC信道的詳細定義在[7]中規(guī)定為ROHC框架的一部分。包括在ROHC信道上不同流（頭壓縮或不壓縮）的復(fù)用，以及在流壓縮算法的初始化期間特定IP流與特定文本狀態(tài)的關(guān)聯(lián)。本部分不涉及ROHC框架功能的實現(xiàn)以及所支持的頭壓縮簡表功能的實現(xiàn)。本部分描述了如下簡表的支持：表1 支持的頭壓縮協(xié)議與簡表Profile IdentifierUsage:Reference0x0000No pressionRFC 49950x0001RTP/UDP/IPRFC 3095, RFC 48150x0002UDP/IPRFC 3095, RFC 48150x0003ESP/IPRFC 3095, RFC 48150x0004IPRFC 3843, RFC 48150x0006TCP/IPRFC 49960x0101RTP/UDP/IPRFC 52250x0102UDP/IPRFC 52250x0103ESP/IPRFC 52250x0104IPRFC 5225 頭壓縮的配置與DRB關(guān)聯(lián)的PDCP 實體可被上層配置來使用頭壓縮。 協(xié)議參數(shù)在壓縮端和解壓縮端之間，[7]定義了必須由上層配置的強制配置參數(shù)；這些參數(shù)定義ROHC信道。ROHC信道是單向信道，即一個信道用于上行
公司管理相關(guān)推薦
鄂ICP備17016276號-1