第一篇：PDCP協議學習總結

PDCP協議學習總結

1、PDCP架構

UE/E-UTRANPDCP entiy Radio BearersPDCP-SAPPDCP-SAPC-SAPPDCP entityPDCP entity...PDCP sublayerPDCPSDU...RLC UM-SAPRLC AM-SAPRLC sublayer

2、PDCP實體：

UE/E-UTRANTransmitting PDCP entityReceiving PDCP entityE-UTRAN/UESequence numberingHeader Compression(u-plane only)Packets associated to a PDCP SDU Integrity Protection(c-plane only)Ciphering Packets not associated to a PDCP SDUIn order delivery and duplicate detection(u-plane only)Header Decompression(u-plane only)Packets associated to a PDCP SDUIntegrity Verification(c-plane only)DecipheringPackets not associated to a PDCP SDUAdd PDCP headerRemove PDCP HeaderRadio Interface(Uu)一個UE可以定義多個PDCP實體，可以對攜帶用戶面數據的每個PDCP實體進行配置，來使用頭壓縮。每個PDCP實體攜帶一個無線承載的數據。根據無線承載所攜帶的數據，PDCP實體對應于控制平面或者用戶平面

3、PCDP層服務

向上層提供的服務：（PDCP提供服務給UE的RRC層和用戶面高層）（1）數據傳輸（2）頭壓縮（3）加密（4）完整性保護

從下層得到的服務：（RLC層向PDCP層提供服務）

（1）確認的數據傳輸業務，包括PDCP PDU成功傳輸的指示（2）非確認的數據傳輸業務

（3）有序傳送，除了在切換時的情況（4）重復丟棄，除了在切換時的情況

4、PDCP層功能

（1）發送和接收實體利用ROHC協議對IP數據流進行相應的頭壓縮和解壓縮（2）用戶面數據或者控制面數據的傳輸

（3）維護RLC AM模式下的映射的無線承載的PDCP SN（4）下層重建時，上層PDU的有序傳送

（5）下層重建時，RLC AM模式下的映射的無線承載的下層SDU重復消除（6）用戶面數據和控制面數據的加密和解密（7）控制面數據的完整性保護與完整性驗證（8）基于計時器的丟棄（9）重復丟棄

5、PDCP過程（具體過程見page 3）（1）PDCP數據傳輸過程 上行數據傳輸過程：每一個PDCP SDU對應一個Discard Timer，一旦由高層接收到一個PDCP SDU，即啟動該SDU對應的Discard Timer。同時，進行發送相關的狀態變量更新及加密、完整性保護等，具體過程如圖2所示。

下行數據傳輸過程：在不需重建的情況下，PDCP實體在接收到RLC AM實體提交的PDCP PDU時，不需執行重排序過程，因為RLC AM在向PDCP實體提交PDCP PDU時，已保證順序遞交。若UE先從源eNodeB收到一些PDCP SDU，重建開始后從目的eNodeB接收PDCP SDU(其中部分是源eNodeB轉給目的eNodeB的，并且有一些是源eNodeB已發給UE但尚未得到確認的)，因此，UE的PDCP實體收到的PDCP SDU可能是亂序并且有重復的，因此對于RLC AM模式，在重建情況下，PDCP接收實體需對接收的PDCP SDU進行重排序和重復檢測。

（2）重建過程

上行數據傳輸過程：映射到RLC AM的DRB過程

映射到RLC UM的DRB過程 SRB過程 下行數據傳輸過程：映射到RLC AM的DRB過程

映射到RLC UM的DRB過程 SRB過程（3）PDCP狀態報告 傳輸：

接收：

（4）PDCP丟棄：PDCP SDU的Discard_Timer超時或PDCP SDU的成功傳輸有PDCp狀態報告確認，UE丟棄PDCP SDU及相應的PDCP PDU（5）頭壓縮與解壓縮：

（6）加密和解密：加密不用于PDCP控制PDU 控制面：PDCP PDU中數據部分及MAC-I 用戶面：PDCP PDU的數據部分

（對消息和加密流做異或(XOR)運算來實現的，這里加密流是由基于接入層(AS)導出密鑰、無線承載ID、傳輸方向(上行或下行)以及COUNT值的加密算法所生成的。）

（7）完整性保護及確認：該功能僅用于SRB（8）未知的、意外的以及錯誤的協議數據的處理

6、PDCP協議數據單元及格式

PDCP數據PDU傳送：一個PDU SDU SN、包含一個基于非壓縮的PDCP SDU用戶面數據、包含一個基于壓縮的PDCP SDU用戶面數據、控制平面數據、只有SRB的MAC-I域 PDCP控制PDU傳送：PDCP狀態報告、頭壓縮信息

7、參數

（1）PDCP SN：

（2）DATA：未壓縮PDCP SDU（用戶面或控制面數據）/壓縮PDCP SDU（用戶面數據）（3）MAC-I：消息認證碼、未經過完整性保護的控制面數據MAC-I用0填充（4）COUNT：HFN+PDCP SN（5）R：保留位

（6）D/C：控制PDU或數據PDU（7）PDU type：status/ROHC/received（8）FMS：第一個丟失的PDCP SDU的PDCP SN值

（9）Bitmap：PDCP SDU是否被接收并正確的進行選擇性解壓

8、變量

PDCP實體發送端

（1）Next_PDCP_TX_SN：給定PDCP實體的下一個PDCP SDU的PDCP SN，實體重建時置0（2）TX_HFN:sehngcheng COUNT值的HFN值（COUNT值用于一個給定的PDCP實體的PDCP PDU），實體重建時置0 PDCP實體接收端

（1）Next_PDCP_RX_SN：下一個期望的PDCP SN，有一個給定PDCP實體的接收方給出，實體重建時置0（2）RX_HFN：生成COUNT值的HFN值，實體重建時置0（3）Last_Submitted_PDCP_RX_SN:傳輸到上層的最后一個PDCP SDU的SN，實體重建4095

9、常量

（1）Reordering_Window：2048，PDCP SN的一半，用于無線承載應設在RLC AM上的情況（2）Maximum_PDCP_SN：

10、定時器

（1）Discard_Timer丟棄定時器（2）Flush_Timer清空定時器

5.1 數據傳輸過程

5.1.1 上行

從上層接收到PDCP SDU后

UE啟動與此PDCP相關量的discardTimer 對于從上層接收到的PDCP SDU UE應關聯相應于Next_PDCP_TX_SN的PDCP SN到PDCP SDU UE應執行PDCP SDU頭壓縮 UE應執行完整性保密

UE應使用基于TX_HFN的COUNT以及關聯于PDCP SDU的PDCP SN值進行加密 UE將Next_PDCP_TX_SN加1 若果Next_PDCP_TX_SN﹥Maximum_PDCP_SN UE應將Next_PDCP_TX_SN置0 UE應將TX_HFN加1 UE應將最后產生的PDCP Data PDU傳送給低層

5.1.2 下行

一、DRB過程

1、映射到RLC AM的DRB過程

對于映射到 RLC AM的DRB，在接收到低層的PDCP Data PDU時

（1）如果接收到的PDCP SN－Last_Submitted_PDCP_RX_SN＞reordering_Window 或0≤Last_Submitted_PDCP_RX_SN－接收到的PDCP SN＜Reordering_Window Last_Submitted_PDCP_RX_SN0Maximum_PDCP_SNReordering_WindowNext_PDCP_RX_SNReceived PDCP SNRX_HFN-1

圖5.1 Received PDCP SN－Last_Submitted_PDCP_RX_SN＞reordering_Window 1）如果接收到的PDCP SN＞Next_PDCP_RX_SN 0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN-1且received PDCP SN＞Next_PDCP_RX_SN

圖5.2 0≤Last_Submitted_PDCP_RX_SN－received PDCP SN＜Reordering_Window UE應使用基于RX_HFN－1的COUNT與接收到的PDCP SN值，解密此PDCP 2）否則

0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNNext_PDCP_RX_SNRX_HFN圖5.3 0≤Last_Submitted_PDCP_RX_SN－received PDCP SN＜Reordering_Window

且Next_PDCP_RX_SN ＞received PDCP SN

UE應使用基于RX_HFN的COUNT與接收到的PDCP SN值，解密此PDCP PDU 3）UE應執行頭壓縮

4）UE應丟棄此PDCP SDU（2）否則，如果Next_PDCP_RX_SN－接收到的PDCP SN＞Reordering_Window 0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNRX_HFNNext_PDCP_RX_SN

圖5.4 Next_PDCP_RX_SN －received PDCP SN＞Reordering_Window 1）UE應將Next_HFN加1 2）UE應使用基于RX_HFN的COUNT與接收到的PDCP SN解密此PDCP PDU 3）UE應將Next_PDCP_RX_SN置為剛接收到的PDCP SN＋1（4）否則，如果接收到的PDCP SN－Next_PDCP_RX_SN≥Reordering_Window 0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN-1

圖5.5 received PDCP SN－Next_PDCP_RX_SN＞Reordering_Window

1）UE應使用基于RX_HFN－1的COUNT與接收到的PDCP SN解密此PDCP PDU（5）否則，如果接收到的PDCP SN≥Next_PDCP_RX_SN Last_Submitted_PDCP_RX_SN0Maximum_PDCP_Reordering_WindowNext_PDCP_RX_SNReceived PDCP SNRX_HFN

圖5.6 Received PDU SN≥Next_PDCP_RX_SN（1）

Last_0Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN

圖5.7 Received PDU SN≥Next_PDCP_RX_SN（2）

Last_0Submitted_PDCP_RX_SNMaximum_PDCP_SNNext_PDCP_RX_SNReceived PDCP SNRX_HFN

圖5.8 Received PDU SN≥Next_PDCP_RX_SN（3）

1）UE應使用基于RX_HFN的COUNT與接收到的PDCP SN解密此PDCP PDU 2）UE應將Next_PDCP_RX_SN置為接收到的PDCP SN＋1 3）如果Next_PDCP_RX_SN＞Maximum_PDCP_SN UE應將Next_PDCP_RX_SN置0 UE應將RX_HFN加1（6）否則，如果接收到的PDCP SN＜Next_PDCP_RX_SN Last_Submitted_PDCP_RX_SN0Maximum_PDCP_SNReordering_WindowReceived PDCP SNRX_HFNNext_PDCP_RX_SN

圖5.9 Received PDU SN＜Next_PDCP_RX_SN（1）

0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNRX_HFN

Next_PDCP_RX_

圖5.10 Received PDU SN＜Next_PDCP_RX_SN（2）0Last_Submitted_PDCP_RX_SNMaximum_PDCP_SNReceived PDCP SNNext_PDCP_RX_SNRX_HFN圖5.11 Received PDU SN＜Next_PDCP_RX_SN（3）

1)UE應使用基于RX_HFN的COUNT值域接收到的PDCP SN值解密此PDCP PDU（7）如果上面沒有丟棄此PDCP PDU 1)UE應執行PDCP PDU的解密與頭壓縮

2)如果一個具有相同PDCP SN值的PDCP PDU被存儲 UE應丟棄此PDU 3）否則

UE應存儲此PDCP SDU 4）如果由于下層重建導致PDCP沒有接收到此PDCP PDU UE應把相關的COUNT值按照升序傳遞給上層：

a.所有存儲的，相關COUNT值小于接收PDCP SDU的COUNT值的PDCP SDU b.所有存儲的，從接收到的PDCP SDU的COUNT值開始，連續COUNT值對應的PDCPSDU UE應將Last_Submitted_PDCP_RX_SN置為最后遞交給高層的PDCP SDU的PDCP SN值 5）否則，如果接收到的PDCP SN＝Last_Submitted_PDCP_RX_SN﹢1，6）或者接收到的PDCP SN＝Last_Submitted_PDCP_RX_SN－Maximum_PDCP_SN UE應把相關COUNT值按照升序傳遞給上層

a.所有存儲的，從接收到的PDCP SDU的COUNT值開始，連續COUNT值對應的PDCP SDU UE應將Last_Submitted_PDCP_RX_SN置為最后遞交給高層的PDCP SDU的

PDCP SN值

2、映射到RLC UM的DRB過程

對于映射到RLC UM的DRN，在接收到低層的PDCP Data PDU以后（1）如果接收到的PDCP SN＜Next_PDCP_RX_SN 1）UE應將RX_HFN加1（2）UE應使用基于RX_HFN的COUNT值與接收到的PDCP SN值來解密此PDCP Data PDU（3）如果Next_PDCP_RX_SN＞Maximum_PDCP_SN 1）UE應將Next_PDCP_RX_SN置0 2）UE應將RX_HFN﹢1（4）執行已解密的PDCP Data PDU的頭壓縮（5）UE應將最后產生的PDCP SDU遞交給上層

二、SRB過程

對于SRB，在接收到低層的PDCP Data PDU后（1）如果接收的PDCP SN＜Next_PDCP_RX_SN 1）UE應使用基于RX_HFN﹢1的COUNT與接收到的PDCP SN值來解密此PDU以及確認其完整性

（2）否則

1）UE應使用基于RX_HFN的COUNT與接收到的PDCP SN值來解密此PDU以及確認其完整性

（3）如果完整性確認使用并成功通過，或

（4）如果完整性確認不適用

1）如果接收的PDCP SN＜Next_PDCP_RX_SN UE應將RX_HFN加1 2）UE應將Next_PDCP_RX_SN置為接收到的PDCP SN﹢1 3）如果Next_PDCP_RX_SN＞Maximum_PDCP_SN UE應將Next_PDCP_RX_SN置0 UE應將RX_HFN加1 4）UE應將最后產生的PDCP SDU遞交給上層（5）否則，如果完整性確認適用，但失敗

1）UE應丟棄接收到的PDCP Data PDU 2）UE應將完整性確認失敗報告遞交給上層

5.2 重建過程

5.2.1 上行

1、映射到RLC AM的DRB過程 當上層請求一次PDCP重建時

（1）UE應重置上行鏈路的頭壓縮協議

（2）重建過程期間，UE應使用加密算法及上層提供的密鑰加密

（3）從第一個對應的PDCP PDU成功傳遞但沒有被下層確認的PDCP SDU開始，在如PDCP重建之前，執行所有由與此PDCP SDU對應的COUNT開始的，按照COUNT升序排列的PDCP SN值對應的PDCP SDU的重傳或傳輸（4）UE應執行DCP SDU的頭壓縮

（5）UE應使用與此PDCP SDU關聯的COUNT值來加密此PDCP SDU（6）UE應將最后產生的PDCP Data PDU傳遞給下層

2、映射到RLC UM的DRB過程 當上層請求一次PDCP重建時

（1）UE應重置上行鏈路的頭壓縮協議

（2）UE應置Next_PDCP_TX_SN以及TX_HFN為0（3）重建過程期間，UE應使用加密算法及上層提供的密鑰加密

（4）對于每一個已經對應于一個PDCP SN，但相應的PDU沒有事先傳遞給低層的PDCP SDU 1）UE認為此PDCP SDU是從上層接收而來

2）在PDCP重建之前，在不重啟discardTimer的情況下，UE應按照與PDCP SDU關聯的COUNT值的升序傳輸PDCP SDU

3、SRB過程

當上層請求一次PDCP重建時

（1）UE應置Next_PDCP_TX_SN及TX_HFN為0（2）UE應丟棄所有存儲的PDCP SDU和PDCP PDU（3）重建過程期間，UE應使用加密和完整性保護算法，以及使用上層提供的密鑰進行加密

5.2.2 下行

1、映射到RLC AM的DRB過程

當上層請求一次PDCP重建時

（1）UE應處理由于下層重建而從下層接收到的PDCP Data PDU（2）UE應重置下行鏈路的頭壓縮協議

（3）重建過程期間，UE應使用加密算法和上層提供的密鑰進行加密

2、映射到RLC UM的DRB過程 當上層請求一次PDCP重建時

（1）UE應處理由于下層重建而從下層接收到的PDCP Data PDU（2）UE 應重置下行鏈路的頭壓縮協議

（3）UE應將Next_PDCP_RX_SN及RX_HFN置0（4）重建過程奇跡，UE應使用加密算法和上層提供的密鑰進行加密

3、SRB過程

當上層請求一次PDCP重建時

（1）UE應丟棄由于下層重建而從下層接收來的PDCP Data PDU（2）UE應將Next_PDCP_RX_SN及RX_HFN置0（3）UE應丟棄所有存儲的PDCP SDU和PDCP PDU（4）重建過程期間，UE 應使用加密和完整性保護算法，以及使用上層提供的密鑰進行加密

5.3 PDCP狀態報告

5.3.1 傳輸

對于映射到RLC AM的RB當上層請求一次PDCP重建時

如果此RB被上層配置用于在上行鏈路發送一個PDCP狀態報告，在處理完因下層重建而從下層接收來的PDCP Data PCU以后，UE應按下述指示進行狀態報告：（1）UE應將FMS置為第一個丟失的PDCP SDU的PDCP SN值

（2）如果至少有一個失序PDCP SDU被存儲，則UE分配一個Bitmap field，長度等于從第一個丟失的PDCP SDU開始知道最后一個失序的PDCP SDU結束的PDCP SN的個數，四舍五入到下一個8的倍數

（3）UE將所有低層指示還未接受到的PDCP SDU以及任意解壓縮失敗的PDCP SDU在Bitmap field中對應的區域置0（4）對于其他的PDCP SDU，對應區域置1 5.3.2 接收

當在下行鏈路接收到一個PDCP狀態報告時，對已映射到RLC AM的RB 對于每個PDCP SDU，如果在Bitmap中對應的bit位為1，或者相關聯的COUNT值小于FMS字段確定的PDCP SDU的COUNT值，則相應PDCP SDU的成功傳輸將被確認，且UE應按照PDCP丟棄過程的規定來處理此PDCP。

5.4 PDCP丟棄

當用于PDCP SDU的discardTimer終止，或PDCP SDU的成功傳輸被PDCP狀態報告確認，UE應就其此PDCP SDU及其對應的PDCP PDU。如果對應的PDCP PDU已經成功傳遞給下層，則丟棄需要指示給下層。

5.5 頭壓縮與解壓縮

5.5.1 協議與簡表

頭壓縮協議基于可靠性頭壓縮（ROHC）框架，存在多種頭壓縮算法，成為簡表，定義用于ROHC框架。每個簡表為特定的網絡層、傳輸層或上層集合所專用。5.5.2 頭壓縮配置

與DRB關聯的PDCP實體可被上層配置來使用頭壓縮 5.5.3 協議參數

壓縮與解壓縮端之間定義了必須有上層配置的強制配置參數，定義ROHC信道（單行信道，上行或下行），屬于同一個PDCP實體的信道使用相同的配置。M、N/A、LARGE_CIDs、PROFILES（M）、FEEDBACK_FOR(N/A)、MRRU（N/A）5.5.4 頭壓縮

生成兩種類型的輸出數據包：

（1）壓縮包，各自關聯于一個PDCP SDU（與相關PDCP SDU相同的PDCP SN和COUNT關聯）（2）獨立數據包，為關聯于PDCP SDU，即零散的ROHC反饋包（不與PDCP SDU關聯，不與PDCP SN關聯，不加密）

5.5.5 頭解壓縮

如果上層為關聯與用戶平面數據的PDCP實體配置了頭解壓縮，則PDCP PDU將在執行解密程序后由頭解壓協議進行解壓縮

5.6 加密和解密

1、對于控制平面，加密的數據單元是PDCP PDU以及MAC-I的部分數據

2、對于用戶平面，加密的數據單元是PDCP PDU的部分數據

3、加密不適用與PDCP控制PDU

4、加密算法和密鑰由上層配置

5、加密功能由上層激活，激活后，應用于所有上層指示的上下行PDCP PDU

6、加密功能請求的輸入：COUNT、DIRECTION

7、PDCP請求的，由上層提供的參數：BEARER、KEY（控制面/用戶面）（1）BEARER：承載的標識，用于RB身份的標識

（2）DIRECTION：標識傳輸的方向，0用于上行、1用于下行（3）KEY：控制平面和用戶平面的加密密鑰分別為KRRCenc與KUPenc

5.7 完整性保護及確認

1、完整性保護+完整性確認

2、用于與SRB關聯的PDCP

3、受完整性保護的數據單元為：PDU頭和加密前的PDU部分數據

4、完整性保護算法和密鑰由上層提供

5、完整性保護功能由上層激活，激活后，應用于從上層指定的PDU之后的上下行PDCP PDU

6、完整性保護算法的輸入：COUNT、DIRECTION

7、PDCP請求的，由上層提供的數：BEARER、KEY

8、傳輸時，UE計算MAC-I字段的值

接收時，UE通過基于以上指定的輸入參數計算X-MAX來確認PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應，則完整性保護確認成功

5.8 未知的、意外的以及錯誤的協議數據的處理

PDCP收到一個包括保留至或非法值的PDCP PDU時，PDCP實體應丟棄收到的PDU

補充PDCP實現LTE 接入層安全性過程

PDCP層通過接受高層的安全配置信令，進入相應的狀態后才能對數據和信令進行加密及完整性保護，在正常的RRC連接建立完成并且通過層三的鑒權完成后，啟動接入層的安全模式命令。網絡端首先獲得由非介入層的AKA（Authentication and Key Agreement）過程產生密鑰KASME，然后RRC由該參數計算得到KeNB，再由KeNB計算得到控制平面的完整性保護密鑰KRRCint，以及用戶平面和控制平面需要的密鑰KUPenc、KRRCenc，在組裝成安全模式命令（SecurityModiCommand），發送給終端，配置中端的安全性參數。當網絡端發出SecurityModeCommand消息后開始對下行數據進行加密，終端的PDCP層接收到SecurityModeCommand消息后，先將其發送到RRC進行解碼操作，得出網絡端配給終端的完整性保護算法，再將完整性保護算法和相應的密鑰發給PDCP層，PDCP就可以對SecurityModeCommand消息進行完整性校驗。如果沒有通過完整性校驗，則向網絡端發送安全模式失敗（SecurityModeFailure）；如果通過，則取出里面包含的加密算法，并向網絡發送安全模式完成（SecurityModeComplete）消息，對其進行完整性保護但是不加密，自此后開始對上行數據加密，下行數據解密。網絡端收到該消息后開始對上行數據解密，安全性建好后，開始對信令進行完整性保護。

接入層的安全性是通過加密算法和完整性保護算法來實現的。

接收時，UE通過基于以上指定的輸入參數計算X-MAX來確認PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應，則完整性保護確認成功

第二篇：PDCP協議學習總結

PDCP協議學習總結

1、PDCP架構

UE/E-UTRANPDCP entiy Radio BearersPDCP-SAPPDCP-SAPC-SAPPDCP entityPDCP entity...PDCP sublayerPDCPSDU...RLC UM-SAPRLC AM-SAPRLC sublayer

2、PDCP實體：

一個UE可以定義多個PDCP實體，可以對攜帶用戶面數據的每個PDCP實體進行配置，來使用頭壓縮。每個PDCP實體攜帶一個無線承載的數據（復用為2個）。根據無線承載所攜帶的數據，PDCP實體對應于控制平面DCCH或者用戶平面DTCH

3、PCDP層服務 向上層提供的服務：（PDCP提供服務給UE的RRC層和用戶面高層）（1）數據傳輸

（2）頭壓縮：IP包頭壓縮（3）加密

（4）完整性保護 從下層得到的服務：（RLC層向PDCP層提供服務）

（1）確認的數據傳輸業務，包括PDCP PDU成功傳輸的指示（2）非確認的數據傳輸業務

（3）有序傳送，除了在切換時的情況（4）重復丟棄，除了在切換時的情況

4、PDCP層功能

（1）發送和接收實體利用ROHC（ROBUST HEADER COMPRESSION）協議對IP數據流進行相應的頭壓縮和解壓縮

（2）用戶面數據或者控制面數據的傳輸

（3）維護RLC AM模式下的映射的無線承載的PDCP SN（4）下層重建時，上層PDU的有序傳送

（5）下層重建時，RLC AM模式下的映射的無線承載的下層SDU重復消除（6）用戶面數據和控制面數據的加密和解密

（7）控制面數據的完整性保護與完整性驗證(RRC層和NAS層)（8）基于計時器的丟棄（9）重復丟棄

5、PDCP過程

（1）PDCP數據傳輸過程 上行數據傳輸過程：每一個PDCP SDU對應一個Discard Timer，一旦由高層接收到一個PDCP SDU，即啟動該SDU對應的Discard Timer。同時，進行發送相關的狀態變量更新及加密、完整性保護等，PDCP SDU的Discard_Timer超時或PDCP SDU的成功傳輸有PDCp狀態報告確認，UE丟棄PDCP SDU及相應的PDCP PDU

下行數據傳輸過程：在不需重建的情況下，PDCP實體在接收到RLC AM實體提交的PDCP PDU時，不需執行重排序過程，因為RLC AM在向PDCP實體提交PDCP PDU時，已保證順序遞交。若UE先從源eNodeB收到一些PDCP SDU，重建開始后從目的eNodeB接收PDCP SDU(其中部分是源eNodeB轉給目的eNodeB的，并且有一些是源eNodeB已發給UE但尚未得到確認的)，因此，UE的PDCP實體收到的PDCP SDU可能是亂序并且有重復的，因此對于RLC AM模式，在重建情況下，PDCP接收實體需對接收的PDCP SDU進行重排序和重復檢測。

（2）重建過程

上行數據傳輸過程：映射到RLC AM的DRB過程 映射到RLC UM的DRB過程 SRB過程 下行數據傳輸過程：映射到RLC AM的DRB過程 映射到RLC UM的DRB過程 SRB過程（4）PDCP丟棄：PDCP SDU的Discard_Timer超時或PDCP SDU的成功傳輸有PDCp狀態報告確認，UE丟棄PDCP SDU及相應的PDCP PDU（5）頭壓縮與解壓縮：

（6）加密和解密：加密不用于PDCP控制PDU 控制面：PDCP PDU中數據部分及MAC-I 用戶面：PDCP PDU的數據部分

（對消息和加密流做異或(XOR)運算來實現的，這里加密流是由基于接入層(AS)導出密鑰、無線承載ID、傳輸方向(上行或下行)以及COUNT值的加密算法所生成的。）

（7）完整性保護及確認：該功能僅用于SRB（8）未知的、意外的以及錯誤的協議數據的處理

6、PDCP協議數據單元及格式

PDCP數據PDU傳送：一個PDU SDU SN、包含一個基于非壓縮的PDCP SDU用戶面數據、包含一個基于壓縮的PDCP SDU用戶面數據、控制平面數據、只有SRB的MAC-I域 PDCP控制PDU傳送：PDCP狀態報告、頭壓縮信息

5.5 頭壓縮與解壓縮

5.5.1 協議與簡表

頭壓縮協議基于可靠性頭壓縮（ROHC）框架，存在多種頭壓縮算法，成為簡表，定義用于ROHC框架。每個簡表為特定的網絡層、傳輸層或上層集合所專用。5.5.2 頭壓縮配置

與DRB關聯的PDCP實體可被上層配置來使用頭壓縮 5.5.3 協議參數

壓縮與解壓縮端之間定義了必須有上層配置的強制配置參數，定義ROHC信道（單行信道，上行或下行），屬于同一個PDCP實體的信道使用相同的配置。M、N/A、LARGE_CIDs、PROFILES（M）、FEEDBACK_FOR(N/A)、MRRU（N/A）5.5.4 頭壓縮

生成兩種類型的輸出數據包：

（1）壓縮包，各自關聯于一個PDCP SDU（與相關PDCP SDU相同的PDCP SN和COUNT關聯）（2）獨立數據包，為關聯于PDCP SDU，即零散的ROHC反饋包（不與PDCP SDU關聯，不與PDCP SN關聯，不加密）5.5.5 頭解壓縮

如果上層為關聯與用戶平面數據的PDCP實體配置了頭解壓縮，則PDCP PDU將在執行解密程序后由頭解壓協議進行解壓縮

5.6 加密和解密

1、對于控制平面，加密的數據單元是PDCP PDU以及MAC-I的部分數據

2、對于用戶平面，加密的數據單元是PDCP PDU的部分數據

3、加密不適用于PDCP控制PDU

4、加密算法和密鑰由上層配置

5、加密功能由上層激活，激活后，應用于所有上層指示的上下行PDCP PDU

7、PDCP請求的，由上層提供的參數：BEARER、KEY（控制面/用戶面）（1）BEARER：承載的標識，用于RB身份的標識

（2）DIRECTION：標識傳輸的方向，0用于上行、1用于下行

（3）KEY：控制平面和用戶平面的加密密鑰分別為KRRCenc與KUPenc

5.7 完整性保護及確認

1、完整性保護+完整性確認

2、用于與SRB關聯的PDCP

3、受完整性保護的數據單元為：PDU頭和加密前的PDU部分數據

4、完整性保護算法和密鑰由上層提供

5、完整性保護功能由上層激活，激活后，應用于從上層指定的PDU之后的上下行PDCP PDU

7、PDCP請求的，由上層提供的數：BEARER、KEY

8、傳輸時，UE計算MAC-I字段的值

接收時，UE通過基于以上指定的輸入參數計算X-MAX來確認PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應，則完整性保護確認成功

5.8 未知的、意外的以及錯誤的協議數據的處理

PDCP收到一個包括保留值或非法值的PDCP PDU時，PDCP實體應丟棄收到的PDU

補充PDCP實現LTE 接入層安全性過程

PDCP層通過接受高層的安全配置信令，進入相應的狀態后才能對數據和信令進行加密及完整性保護，在正常的RRC連接建立完成并且通過層三的鑒權完成后，啟動接入層的安全模式命令。網絡端首先獲得由非接入層的AKA（Authentication and Key Agreement）過程產生密鑰KASME，然后RRC由該參數計算得到KeNB，再由KeNB計算得到控制平面的完整性保護密鑰KRRCint，以及用戶平面和控制平面需要的密鑰KUPenc、KRRCenc，在組裝成安全模式命令（SecurityModiCommand），發送給終端，配置終端的安全性參數。當網絡端發出SecurityModeCommand消息后開始對下行數據進行加密，終端的PDCP層接收到SecurityModeCommand消息后，先將其發送到RRC進行解碼操作，得出網絡端配給終端的完整性保護算法，再將完整性保護算法和相應的密鑰發給PDCP層，PDCP就可以對SecurityModeCommand消息進行完整性校驗。如果沒有通過完整性校驗，則向網絡端發送安全模式失敗（SecurityModeFailure）；如果通過，則取出里面包含的加密算法，并向網絡發送安全模式完成（SecurityModeComplete）消息，對其進行完整性保護但是不加密，自此后開始對上行數據加密，下行數據解密。網絡端收到該消息后開始對上行數據解密，安全性建好后，開始對信令進行完整性保護。

接入層的安全性是通過加密算法和完整性保護算法來實現的。接收時，UE通過基于以上指定的輸入參數計算X-MAX來確認PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應，則完整性保護確認成功

第三篇：Coap協議學習總結

Coap協議學習總結

1、Coap協議介紹

在2010年3月，CoRE工作組開始制定CoAP協議，到目前為止，該協議還沒有定稿。CoAP協議是為物聯網中資源受限設備制定的應用層協議。CoAP 是受限制的應用協議(Constrained Application Protocol)的代名詞。在最近幾年的時間中，專家們預測會有更多的設備相互連接，而這些設備的數量將遠超人類的數量。在這種大背景下，物聯網和 M2M技術應運而生。雖然對人而言，連接入互聯網顯得方便容易，但是對于那些微型設備而言接入互聯網非常困難。在當前由PC機組成的世界，信息交換是通過 TCP和應用層協議HTTP實現的。但是對于小型設備而言，實現TCP和HTTP協議顯然是一個過分的要求。為了讓小設備可以接入互聯網，CoAP協議被 設計出來。CoAP是一種應用層協議，它運行于UDP協議之上而不是像HTTP那樣運行于TCP之上。CoAP協議非常的小巧，最小的數據包僅為4字節。

為了克服HTTP對于受限環境的劣勢，CoAP既考慮到數據報長度的最優化，又考慮到提供可靠通信。一方面，CoAP提供URI，REST 式的方法如GET，POST，PUT和DELETE，以及可以獨立定義的頭選項提供的可擴展性。另一方面，CoAP基于輕量級的UDP協議，并且允許IP 多播。而組通信是物聯網最重要的需求之一，比如說用于自動化應用中。為了彌補UDP傳輸的不可靠性，CoAP定義了帶有重傳機制的事務處理機制。并且提供 資源發現機制，并帶有資源描述。

CoAP協議不是盲目的壓縮了HTTP協議，考慮到資源受限設備的低處理能力和低功耗限制，CoAP重新設計了HTTP的部分功能以適應設備的約束條件。另外，為了使協議適應物聯網和M2M應用，CoAP協議改進了一些機制，同時增加了一些功能。下圖1顯示了HTTP和CoAP的協議棧。CoAP和HTTP在傳輸層有明顯的區別。HTTP協議的傳輸層采用了TCP協議，而CoAP協議的傳輸層使用UDP 協議，開銷明顯降低，并支持多播。

事務層(Transaction layer)用于處理節點之間的信息交換，同時提供組播和擁塞控制等功能。請求／響應層(Request／Responselayer)用于傳輸對資源進行操作的請求和響應信息。CoAP協議的REST構架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒有采用TCP協議，也可以提供可靠的傳輸 機制。利用默認的定時器和指數增長的重傳間隔時間實現CON(Confirmable)消息的重傳，直到接收方發出確認消息。另外，CoAP的雙層處理方 式支持異步通信，這是物聯網和M2M應用的關鍵需求之一。

2、CoAP協議是否可以替換HTTP協議？

CoAP并不能替代HTTP協議，但是對于那些小設備（256KB Flash 32KB RAM 20MHz主頻）而言CoAP的確是一個好的解決方案。

3、CoAP的交互模型和消息類型

CoAP使用類似于HTTP的請求／響應模型：CoAP終端節點作為客戶端向服務器發送一個或多個請求，服務器端回復客戶端的CoAP請求。不同于 HTTP，CoAP的請求和響應在發送之前不需要事先建立連接，而是通過CoAP信息來進行異步信息交換。CoAP協議使用UDP進行傳輸。這是通過信息層選項的可靠性來實現的。CoAP采用和HTTP協議相同的請求響應工作模式。CoAP協議共有4中不同的消息類型。

CON——需要被確認的請求，如果CON請求被發送，那么對方必須做出響應。NON——不需要被確認的請求，如果NON請求被發送，那么對方不必做出回應。ACK——應答消息，如果接受到CON消息的響應。

RST——復位消息，當接收者接受到的消息包含一個錯誤，接受者解析消息或者不再關心發送者發送的內容，那么復位消息將會被發送。雖然CoAP協議目前還在制定當中，但Contiki和TinyOS嵌入式操作系統已經支持CoAP協議。Contiki是一個多任務操作系統，并帶有uIPv6協議棧，適用于嵌入式系統和無線傳感器網絡，它占用系統資源小，適用于資源受限的網絡和設備。目前，火狐瀏覽器已經集成了Copper插件，從而實現了CoAP協議。但是這種方式只能讀取傳感器節點上的實時數據，而不能查看各種歷史數據。為此，在Contiki系統的基礎上，基于uIPv6START KIT無線網絡開發套件，用自己編寫的客戶端程序實現了和數據庫的交互，把歷史數據存入數據庫中，從而在Web瀏覽器端不僅可以訪問傳感器節點上的實時數 據，還能查看歷史數據，以便于分析問題。

4、CoAP消息結構

一個CoAP消息最小為4個字節，以下是CoAP協議不同部分的描述。【版本Version】：類似于IPv6和IPv6，僅僅是一個版本號。

【消息類型Message Type】：CON，NON，ACK，RST。這些消息類型相當于HTTP協議的PUTGET等

【消息ID Message ID】：每個CoAP消息都有一個ID，在一次會話中ID總是保持不變。但是在這個會話之后該ID會被回收利用。【標記 Token】：標記是ID的另一種表現、【選項 Options】：CoAP選項類似于HTTP請求頭，它包括CoAP消息本身，例如CoAP端口號，CoAP主機和CoAP查詢字符串等。【負載Payload】：真正有用的被交互的數據。

圖 CoAP消息結構

5、CoAP的URL

在 HTTP的世界中，正式RESTFul協議由于其簡單性和適用性，在WEB應用中越來越受歡迎，這樣的道理同樣適用于CoAP。一個CoAP資源可以被一 個URI所描述，例如一個設備可以測量溫度，那么這個溫度傳感器的URI被描述為：CoAP://machine.address:5683 /sensors/temperature。請注意，CoAP的默認UDP端口號為5683。

6、CoAP觀察模式

在物聯網的世界中，你需要去監控某個傳感器例如溫度或濕度等。在這種情況下，CoAP客戶端并不需要不停的查詢CoAP服務器端的數據變化情況。CoAP客 戶端可以發送一個觀察請求到服務器端。從該時間點開始計算，服務器便會記住客戶端的連接信息，一旦溫度發生變化，服務器將會把新結果發送給客戶端。如果客 戶端不在希望獲得溫度檢測結果，那么客戶端將會發送一個RST復位請求，此時服務器便會清除與客戶端的連接信息。

7、CoAP塊傳輸

CoAP協議的特點是傳輸的內容小巧精簡，但是在某些情況下不得不傳輸較大的數據。在這種情況下可以使用CoAP協議中的某個選項設定分塊傳輸的大小，那么無論是服務器或客戶端可完成分片和組裝這兩個動作。

8、CoAP協議的特點：

（1）報頭壓縮：CoAP包含一個緊湊的二進制報頭和擴展報頭。它只有短短的4 B的基本報頭，基本報頭后面跟擴展選項。一個典型的請求報頭為10～20B。

報頭部分各字段的含義如下：V(Version)表示CoAP協議的版本號；T(Type)表示消息的信息類型；OC(Option Count)表示頭后面的可選的選項數量；Code表示消息的類型：請求消息、響應消息，或者是空消息；Message ID表示消息編號，用于重復消息檢測、匹配消息類型等。

（2）方法和URIs：為了實現客戶端訪問服務器上的資源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構的主要特點。(3)傳輸層使用UDP協議：CoAP協議是建立在UDP協議之上，以減少開銷和支持組播功能。它也支持一個簡單的停止和等待的可靠性傳輸機制。

(4)支持異步通信：HTTP對M2M(Machine-to-Machine)通信不適用，這是由于事務總是由客戶端發起。而CoAP協議支持異步通信，這對M2M通信應用來說是常見的休眠／喚醒機制。

(5)支持資源發現：為了自主的發現和使用資源，它支持內置的資源發現格式，用于發現設備上的資源列表，或者用于設備向服務目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路徑表示資源描述。

(6)支持緩存：CoAP協議支持資源描述的緩存以優化其性能。

(7)訂閱機制：CoAP使用異步通信方式，用訂閱機制實現從服務器到客戶端的消息推送。實現CoAP的發布，訂閱機制，它是請求成功后自動注冊的 一種資源后處理程序。是由默認的EVENT_和PERIODIC_RESOURCEs來進行配置的。它們的事件和輪詢處理程序用 EST．notify_subscri bers()函數來發布。

9、CoAP協議的火狐瀏覽器實現（B/S架構）

B/S架構的系統結構如圖9所示

系統由用戶瀏覽器、Web服務器、IPv6智能網關、MX231CC節點組成。用戶瀏覽器通過HTTP協議訪問Web服務器，MX231CC節點通 過CoAP協議和IPv6智能網關進行通信，從而實現用戶瀏覽器訪問節點上資源的功能。圖9中實線表示有線連接，虛線表示無線連接。

在當前的Contiki 2.5中，集成了CoAP 03和CoAP06這兩個版本。這兩個文件在Contiki 2.5的apps目錄下，關于CoAP的核心內容都在這兩個文件中。程序的主要部分為：

AUTOSTART_PROCESSES（PERIODIC_RESOURCE（）為進程的主體部分。

然后進行編譯，編譯成.elf文件，用JTAG下載器下載到節點上。節點地址設置為：2001：2：：11：22ff：：fe33：4499.這時，用火狐瀏覽器訪問節點，因為火狐瀏覽器自帶coap插件，如果用其他瀏覽器，那么需要進行coap的代理設置。以控制節點上的三色LED燈反轉為例，用下 面的請求格式：GETcoap://［］：

/readings其中mote_ip_address是節點的IPv6地址，port_number是節點的端口號，readings是客戶端請求的資源（溫度）。

所以在瀏覽器地址欄輸入：coap://［2001：2：：11：22ff：fe33：4499］：61616/toggle，作用是讓節點上的三色LED燈進行反轉。服務器端的響應信息如圖10所示。

從瀏覽器端可以看出，CoAP協議支持Discover和Observe功能，具有GET、POST、PUT和DELETE等方法。Type表示信 息類型為ACK，Code為200，表示成功完成客戶端的請求。事務ID為38 264，它用于重復信息檢測，options為1表示有一個可選項，內容類型為text表示文本類型。

由此可以看出，通過火狐瀏覽器的CoAP協議，可以訪問節點上的傳感器資源。

10、CoAP協議的客戶端實現（C/S架構）

通過火狐瀏覽器可以實現COAP協議，但是只能查看實時數據，不能查看歷史數據。為此，這里搭建了一個C/S架構的環境。如圖11所示。

圖11中客戶端軟件是用基于。NET架構的C#語言編寫的，數據庫使用SQL Server 2008.通過此程序，可以每隔10 s讀取一次數據，存入到數據庫中。并可以通過前臺的Web界面查看各種歷史數據，包括溫度、濕度、亮度等。

插入數據庫中的數據如圖12所示，圖中顯示的是室內的亮度值。

在Web瀏覽器端可以查看實時和歷史數據，頁面顯示效果如圖13所示。

由此看出，基于C/S架構的方式，不僅可以顯示實時數據，還可以查看歷史數據，以便及時發現問題，更加具有實用性。

第四篇：MODBUS通訊協議學習總結

MODBUS通訊協議學習總結

1、協議分3個層次看：

協議應用函數層，如讀寫coil，寄存器； RTU或者ASCII傳輸層 硬件底層

2、比如上位機發來:01 06 00 01 02 D5 00 55 含義:表示上午12點05分開始采集，12*60+5=725=0X02D5 01地址

06表示功能碼 00 01寄存器地址 02 D5數據 00 55 crc

3、就當是一個簡單的協議看。其它的都是格式。比如：上位機發送A，下位機知道這個是>90分

按照他給的框架，自己再自由定義

比如：從機地址，可以寫01-FF 255個這個是從機先固定好的。比如從機是01。上位機發了一串16進制數據，如果第一個字節是01，說明是在和自己通信。每臺從機地址都不一樣

再判斷功能碼。如03。這個看你寫程序是怎么定義的。比如我這里是要讀下位機采集到的數據，我這里就是設置了一個數組，把數據存了起來，等判斷03的時候就把數據給上位機。

4、寄存器地址。自己定義，我這邊是隨便寫的一個固定值

5、還有一個crc判斷。讀數據的時候，判斷下。如果上位機發過來的crc，和自己計算出來的crc一樣，才給返回數據

6、那個CRC怎么計算呢？

有固定的計算格式，只需調用即可。crc 在通過modbus串口傳數據的時候用，網絡上不用。

第五篇：RLC協議學習總結

RLC協議學習總結

1、RLC構架

圖1 RLC架構

2、RLC實體

（1）TM RLC實體：適用于不需要RLC配置的RRC消息使用TM RLC（BCCH、DL/UL CCCH、PCCH）

業務類型：廣播消息的固定部分、尋呼消息、RRC消息等

圖2 TM模式兩個對等實體

發送實體：不對RLC SDU進行串聯、分段

沒有RLC頭

對RLC SDU不做任何改動，向下層發送

接收實體：不做任何修改，一腳RLC SDU到上層協議實體

（2）UM RLC實體：適用于延時敏感和容忍差錯的實時應用

（DL/UL DTCH）RLC SDU分塊、串聯、重排序、重復檢測、重組

業務類型：VoIP、MBMS

圖3 UM模式兩個對等實體

發送實體：在獲得特定的發送機會時，要根據MAC層指示期待的RLC PDU大小進行分段或者串接RLC SDU

添加相應的RLC頭

接收實體：檢測收到的UMD PDU是否重復，重復則丟棄

重排失序的UMD PDU

能夠檢測出UMD PDU在MAC是否丟失，避免過長的重排序時延

若發現某RLC SDU的UMD PDU丟失，則丟棄其他同RLC SDU的PDU（3）AM RLC實體：適用于錯誤敏感、時延容忍的非實時應用

（DL/UL DCCH/DTCH）UM RLC功能+RLC數據PDU重傳、重傳RLC數據PDU再分快、輪詢、狀態報告、狀態禁止

業務類型：FTP、WWW、RRC消息等

圖4 AM模式實體

3、RLC層服務

RLC層向上層提供的服務：（RLC層向PDCP層提供服務）（1）TM數據傳輸：分段和重組、用戶數據的傳輸

（2）UM數據傳輸：分段和重組、串聯、填充、用戶數據的傳輸、加密、序號檢查

（3）AM數據傳輸：分段和重組、串聯、填充、用戶數據的傳輸、糾錯、按序傳送高層PDU、副本檢測、流量控制、協議錯誤檢測和恢復、加密 RLC層從下層得到的服務（1）數據傳輸

（2）通知發送時機，同時提供當次傳輸時發送RLC PDU的總大小（3）通知HARQ重傳失敗

4、RLC層功能

（1）高層PDU傳輸

（2）通過ARQ進行糾錯（AM）

（3）RLC SDU的分段、串接和重組（UM、AM）（4）RLC數據PDU的再分段（AM）（5）高層PDU的按序遞交（UM、TM）（6）重復檢測（UM、AM）（7）RLC SDU丟棄（UM、AM）（8）RLC重建

（9）協議錯誤及恢復

5、RLC過程（具體過程見page 6）（1）數據傳輸過程 TM： UM： AM：

（2）ARQ過程（AM）重傳: 輪詢：（防止發送端buffer溢出）

AMD PDU或AMD PDU片段重傳、接收狀態報告、t-PollRetransmit超時

狀態報告：接收側向對等段發送側反饋，那些PDU或PDU分段已經正確接收，那些沒有。（3）SDU丟棄過程：來自PDCP的指示，若被指示的RLC SDU沒有任何分段映射到一個RLC Data PDU，AM RLC實體發送側或者發送UM RLC實體丟棄該RLC PDU（4）重建過程：由RRC請求觸發，應用于AM、UM、TM

丟棄、重組、提交、停止、復位、初始化（5）對于未知的、意外的以及錯誤的協議數據的處理：丟棄

6、RLC協議數據單元及格式

（1）TMD PDU：僅有數據域組成，沒有任何RLC頭

（2）UMD PDU：UMDPDU頭（固定部分、擴展部分）+數據域（可對RLC SUD進行分段、串接、重組）

（3）AMD PDU：AMD PDU頭（固定部分、數據部分）+數據域（可對RCL SDU進行分段、串接、重組）

7、參數

（1）SN：RLC PDU序號，增量為1（保證按序接收）

（2）FI：指示在數據域的開始和最后是否飽飯RLC SDU分段（3）E：指示數據域或LI域和E域的集合（4）LI：對應數據域長度（5）R1：保留域，置0（6）D/C：控制PDU/數據PDU（7）RFAMD PDU/AMD PDU分段

（8）LSF：是否原始AMD PDU的最后一個分段

（9）SO：AMD PDU分段數據域中第一個字節在原始AMD PDU數據域中的位置（10）CPT：RLC控制PDU類型：STATUA PDU（11）ACK_SN：第一個沒有收到且在STATUS PDU中報告丟失的RLC data PDU的SN（12）E1：其后是否包括一組NACK_SN（13）E2：其后是否包括一組SOStart和SOend域

（14）NACK_SN：AM RLC實體接收側已檢測到丟失AMD PDU（或其一部分）的SN（15）SOstart、SOend：相關SN=NACK_SN的AMD PDU的丟失部分

8、變量

（1）UM發送端 1）VT（US）：

給出下一個要傳送的UMD PDU的序列號。UMD PDU沒傳送一次，該變量就更新一次，其初值為0.（2）UM接收端 1）VR（US）：接受者發送順序狀態變量

被接收的下一個PDU的序列號，初始值為0。當接收到一個PDU，其值設置為SN+1。2）VR（UR）：UM接收狀態變量

記錄等待重排序的最早的UMD PDU的序列號。在重排序窗口之內，序列號低于該變量的UMD PDU，其接收狀態為已確定，放棄對此范圍內的接收空隙處PDU的等待，將其余正確接收到的PDU重組形成SDU，順序遞交到高層，后續即使正確接收到此范圍內序列空隙處的PDU也采取刪除數據包的操作。該狀態變量的初始值為0。3）VR（UX）：UM重排序計時器狀態變量

記錄觸發重排序計時器的UMD PDU緊接著的下一個序列號。當重排序計時器啟動時，該變量與VR（UR）分別記錄當前重排序計時器對應的序列號范圍內的上邊界和下邊界。當該范圍內全部接收序列空隙處的PDU都正確接收后，終止當前重排序計時器。當重排序計時器不存在時，該變量無意義。4）VR（UH）：UM最高期望狀態變量

記錄接收到的PDU中最高序列號緊接著的下一個序列號，作為重排序窗口的上邊界。其初始值為0。（3）AM發送端 1）VT（A）：確認狀態變量

記錄已經收到肯定確認的連續PDU中最高序列號緊接著下一個序列號，座位發送窗口的下邊界。其初始值為0，只有當RM ELC實體發送端收到序列號等于當前VT（A）變量值的PDU的肯定確認時，該變量才會更新（SN=VT（A））。序列號小于該變量的PDU全部經過接收端肯定確認，表明已經全部正確接收。2）VT（MS）：最大發送狀態變量

VT（MS）=VT（A）+AM_Window_Size，座位發送窗口的上邊界。任何序列號發出超出該變量的PDU都不允許發送。當窗口溢出時，AM RLC實體發送端不能發送任何新產生的PDU。3）VT（S）：發送狀態變量

記錄下一個新產生的AMD PDU的序列號，初始值為0。在當前VT（S）值被賦予一個新產生的AMD PDU后，該變量做+1操作。4）POLL_SN_Pollsend ：發送狀態變量（4）AM接收端 1）VR（R）：接收狀態變量

記錄最新完整接收到的連續AMD PDU緊接著的下一個序列號，座位接收窗口的下邊界。該變量初始值為0，僅當當前R變量值對應的PDU被正確接收后才會更新。低于該變量。2）VR（MR）：最大可接收狀態變量

VR（R）=VR（R）+AM_Window_Size，座位接收窗口的上邊界且是第一個長處接收窗口的AMD PDU的序列號，序列號超出該變量的PDU不能被AM RLC實體接收端接收。3）VR（X）：重排序計時狀態變量

記錄發出重排序計時器的AMD PDU緊接著的下一個序列號。當沖排序計時器啟動時，fai變量與MS分別記錄當前重排序計時器對應的序列號范圍的上邊界與下邊界，當該范圍內全部接受序列號空隙處的PDI都正確接收后，終止當前重排序計時器。4）VR（MS）最大狀態發送狀態變量

記錄作為狀態報告中的ACK_SN的最高序列號值，初始值為0。處于接收窗口中，序列號低于該狀態變量的AMD PDU，要么確認接收，要么已經經過重排序計時器檢測認定為丟失的PDU；高于該狀態變量的接收序列號空隙處為沒有完成的重排序計時器檢測的，仍舊等待HARQ重傳的AMD PDU

9、常量

（1）AM_Window_Size：發送側為VT（A）到VT（MS）；接收側為VR（R）到VR（MR）（2）UM_Window_Size：可排序的SN范圍

10、計數器

（1）t-PollRetransmit：接收側AM RLC實體在進行重傳輪詢時使用（2）t-Reordering：接收側AM RLC實體和UM RLC實體檢查下層傳送的RLC PDU是否丟失時使用。如果t-Reordering正在運行，其他的t-Reordering計時器不能被啟動，在一個給定的時間內，每個RLC實體只能運行一個t-Reordering計時器。

（3）t-StatusProhibit：只有在使用了基于計時器的狀態發送時，使用該計時器。當RLC實體建立時，該計時器 啟動，每次計時器超時，就發送一個狀態報告并且計時器重啟。其值由RRC告知。

11、可配置參數（1）maxRetxThreshold：AM RLC實體用于限制每個AMD PDU重傳次數。（2）pollPDU：AM RLC實體發送端用于觸發一次輪詢（3）pollByte：每個AM RLC實體在觸發一個輪詢（4）sn-RieldLength：UM SN域的大小

1、數據傳輸過程

1.1 TM數據傳輸

（1）發送：當向下層發送一個新的TMD PDU時

接收端TM RLC實體應當給下層發送一個沒有經過任何處理的RLC SDU（2）接收：當從下層接收到一個新的TMD PDU時

發送端TM RLC實體應當向上層提交一個沒有經過任何處理的TMD PDU 1.2 UM數據傳輸

（1）發送：當向下層發送一個新的UMD PDU時

發送端UM RLC應當將該UMD PDU的SN置為VT（US），并將VT（US）加1（2）接收：

一、概述：

UM RLC實體接收端需要根據狀態變量VR（UH）來維護重排序窗口

1）當接收到的PDU SN滿足VR（UH）-UM_Window_size=SN

SN落入重排序窗內

2）否則，該SN落在重排序窗口之外 當從下層接收到UMD PUD時

1）UM RLC實體接收端應當丟棄接收到的UMD PDU或將其存儲在接收緩存中 2）如果接受到UMD PDU并將其存儲在接受緩存器中

UM RLC實體接收端應當更新狀態變量、重組并向上層傳送RLC SDUs，在需要的

時候，開始或停止t-Reordering計數器。

當t-Reordering計數器超時

UM RLC接受端實體應更新狀態變量、重組并向上層傳送RLC SDUs，在需要的時候開始 t-Reordering計數器。

二、當從下層接受到UMD PDU時：

當從下層接收到一個SN=x的UMD PDU時： 如果VR（UR）

UM RLC接收實體丟棄該UMD PDU 否則：

UM RLC接收實體應把這個UMD PDU存入接收緩存器中

三、當一個UMD PDU被存儲到接收緩存器時： 當一個SN=x的UMD PDU唄存入接收緩存器中時：（1）如果x落在重排序窗口之外

1）UM RLC接收實體應更新VR（UH）為x+1

2）UM RLC接收實體應從UMD PDU中重組所有SN落在重排序窗口之外的RLC SDU，去掉RLC頭并且按照RLC SN的升序方式向上層發送重組完成的RLC SDU。

3）如果VR（UR）落在重排序窗口之外：

UM RLC接收實體應將VR（UR）置為（VR（UH）-UM_Window_Size）（2）如果接收緩存器中有一個SN=VR（UR）的UMD PDU：

1）UM RLC接收實體應將VR（UR）更新為第一個沒有被接收的UMD PDU SN>當前VR（UR）的PDU

2）UM RLC接收實體應從UMD PDU中重組所有SN<更新后的VR（UR）的RLC SDU，去掉RLC頭并按照RLC SN的升序方式向上層發送重組后的RLC SDU。（3）如果t-Reordering計時器正在運行：

1）如果VR（UX）≤VR（UR），或者

2）如果VR（UX）落在重排序窗口之外且VR（UX）≠VR（UH）

UMD PDU接收實體應停止并重啟t-Reordering計時器（4）如果t-Reordering計數器沒有運行

1）如果VR（UH）＞VR（UR）

UMD PDU接收實體應啟動該t-Reordering計時器

UMD PDU接收實體應將VR（UX）置為VR（UH）

四、當t-Reordering計數器超時 當t-Reordering計數器超時：（1）UM RLC接收實體應更新RLC SDU為第一個沒有被接收的UMD PDU的SN（SN≥VR（UX））（2）UM RLC接收實體應重組所有SN＜更新后的VR（UR）的UMD PDU（3）如果VR（UH）＞VR（UR）

1）UM RLC接收實體應啟動t-Reordering計數器

2）UM RLC接收實體應將VR（UX）置為VR（UH）1.3 AM數據傳輸（1）發送：

1）AM RLC實體接收端應比RLC數據PDU優先發送RLC控制PDU；

2）AM RLC實體接收端應比新的AMD PDU優先發送重傳的RLC數據PDU； 3）發送端AM RLC實體應根據狀態變量VT（A）和VT（MS）維護發送窗口：

如果VT（A）≤SN＜VT（MS），則SN落入發送窗口之內

否則，SN落在發送窗口之外

4）發送端SM RLC實體不應將任何SN落在傳送窗口之外的RLC數據PDU傳送給下層

5）當傳送一個新的AMD PDU給下層時，發送端AM RLC實體應將該AMD PDU的SN置為VT（S），并將VT（S）加1；

6）AM RLC實體接收端可以通過如下方式接收一個RLC數據PDU的確認：

AM RCL實體的發送端可以通過每個AM RLC實體的STATUS PDU來確認 7）當接收到一個SN=VT（A）的AMD PDU的確認時：

a.接收端AM RLC 實體應將VT(A)置為還沒有被確認的最小SN的AMD PDU的SN值，且該SN滿足VT（A）≤SN≤VT（S）

b.如果屬于同一個RLC SDU的PDU都收到了確認，則AM RLC實體接收端應向上層發送RLC SDU成功發送的通知

（2）接收：

一、概述

（1）AM RLC實體接收端應根據狀態變量VR（R）和VR（MR）維護接收窗口：

1）如果VR（R）≤SN＜VR（MR），則SN落入接收窗口之內

2）否則，SN落在接收窗口之外

（2）當從下層接收到一個RLC數據PDU時：

1）AM RLC實體接收端或者丟棄該接收到的RLC數據PDU，或者將其存入接收緩存器

2）如果接收到的RLC數據PDU被存入接收緩存器：

AM RLC實體接收端應更新狀態變量、重組并向上層傳送RLC SDU，且在需要的時候啟動或停止t-Reordering計數器

3）當t-Reordering計數器超時，AM RLC實體接收端應更新狀態變量，并在需要的時候啟動t-Reordering計數器

二、當從下層接收到RLC數據PDU時：

當從下層接收到一個RLC數據PDU時，當它包含SN=x的AMD PDU分段字節為y到z時（1）如果x落在接收窗口之外，或者

（2）SN=x的AMD PDU的分段字節為y到z已經被接收時：

AM RLC實體接收端應丟棄該RLC數據PDU（3）否則：

1）接收AM RLC實體應將接收到的RLC數據PDU存入接收緩存器中

2）如果AMD PDU的有些字節分段包含之前已經接收到的RLC數據PDU：

AM RLC實體接收端應丟棄該重復的字節段

三、當已給RLC數據PDU被存入接收緩存器中時： 當一個SN=x的RLC數據PDU被存入接收緩存器中時：（1）如果x≥VR（H）

接收AM RLC實體應更新VR（H）為x+1（2）如果SN=VR（MS）的AMD PDU的字節段已經接收：

接收AM RLC實體應更新VR（MS）為第一個不是所有字節段都被接收的AMD PDU的SN，且該SN大于當前VR（MS）

（3）如果x=VR（R）：

1）如果AMD PDU的所有SN＝VR（R）的字節段都被接收：

a.接收AM RLC實體應更新VR（R）為第一個不是所有字節段都被接收的AMD PDU的SN，且該SN大于當前VR（R）

b.接收AM RLC實體應更新VR（MR）為已更新的VR（R）＋AM_Window_Size 2）從所有SN落在接收窗口之外的AMD PDU以及的字節段中重組RLC SDU，如果之前

沒有提交過，則去掉RLC頭并將重組的RLC SDU按順序發送給上層。

（4）如果t-Reordering計數器正在運行：

1）如果VR（X）＝VR（R）；或者

2）如果VR（X）落在接收窗口之外，且VR（X）≠VR（MR）

接收AM RLC實體應停止并重置t-Reordering計數器

（5）如果t-Reordering計數器沒有運行（包含因上述過程而停止的情況）：

1）如果VR（H）＞VR（R）

a.接收AM RLC實體應啟動t-Reordering計數器

b.接收AM RLC實體應置VR（X）為VR（H）

四、當t-Reordering計數器超時： 當t-Reordering計數器超時：

（1）接收AM RLC實體應更新VR（MS）為第一個不是所有字節段都被接收的AMD PDU的SN，且該SN≥VR（X）

（2）如果VR（H）＞VR（MS）：

1）接收AM RLC實體應啟動t-Reordering計數器

2）接收AM RLC實體應置VR（X）為VR（H）

2、ARQ過程（ARQ過程只在AM RLC實體執行）2.1 重傳（1）AM RLC實體接收端可以通過如下方式收到AMD PDU或AMD PDU部分的確認（其對等端AM RLC實體通知接收失敗）：

由對等端的AM RLC實體發送的STATUS PDU（2）當接收到從對等端AM RLC實體發送的STATUS PDU所獲取的AMD PDU或AMD PDU部分的否認：

1）如果對應的AMD PDU的SN落入VT（A）≤SN＜VT（S）的范圍內：

則認為這個AMD PDU或AMD PDU的一部分要求重傳

（3）當一個AMD PDU或AMD PDU的部分被認為需要重傳時：

1）如果該AMD PDU被認為是第一次重傳

接收AM RLC實體應將與該AMD PDU關聯的RETX_COUNT置0 2）否則，如果它或者它的一部分重傳沒有被掛起：

接收AM RLC實體應遞增RETX_COUNT 3）如果RETX_COUNT=maxRetxThreshold：

接收AM RLC實體應通知上層已經達到最大重傳次數（4）當重傳一個AMD PDU時

1）如果該AMD PDU的大小能夠完全容納在由下層指示的RLC PDU重傳機會中：

接收AM RLC實體應傳輸這個AMD PDU（除了P域）2）否則：

接收AM RLC將這個AMD PDU進行分段，使得分段后的AMD PDU片段大小可以完全被容納在有下層指示的傳輸機會中

（5）當傳輸一個AMD PDU的一部分時：

1）AM RLC實體接收端應在需要的情況下對該AMD PDU部分進行分段，使得分段后 的心AMD PDU片段可以完全被容納在下層指示的重傳機會中。

（6）當形成一個新的AMD PDU片段時

1）只要把原來的AMD PDU數據字段映射到新的AMD PDU分段的數據部分

2）設置新的AMD PDU分段包頭

3）設置P域 2.2 輪詢

一個AM RLC實體可以輪詢它的對等端實體來觸發對等端的發送狀態報告

一、發送一個AMD PDU或AMD PDU分段（1）當產生一個新的AMD PDU時

1）AM RLC實體接收端應對PDU_WITHOUT_POLL加1

2）對于每一個映射到RLC數據PDU數據域的新數據單元，AM RLC實體接收端應將BYTE_WITHOUT_POLL增加相應的字節數

3）如果PDU_WITHOUT_POLL≥pollPDU；或者

4）如果BYTE_WITHOUT_POLL≥pollBYTE

AM RLC實體發送端應按照如下所述在RLC數據PDU中包含一個POLL（2）當組成一個AMD PDU或者AMD PDU分段時

1）如果在傳送了RLC數據PDU之后，發送緩存器和接收緩存器同時為空（不包括還沒有被確認的RLC數據PDU）；或者

2）如果在傳送了RLC數據PDU之后沒有新的RLC數據PDU需要被傳送

AM RLC發送實體應按照如下所述在RLC數據PDU中包含一個POLL（3）要在RLC數據PDU中包含一個POLL

1）AM RLC實體發送端應設置RLC數據PDU的P域為1

2）AM RLC實體發送端應設置PDU_WITHOUT_POLL為0

3）AM RLC試題發送端應設置BYTE_WITHOUT_POLL為0（4）在根據需要輕狂對VT（S）進行增值后，當向下層發送一個含poll的RLC數據PDU時

1）AM RLC實體發送端應設置POLL_SN為VT（S）－1

2）如果t-PollRetransmit沒有運行

AM RLC實體發送端應啟動t-PollRetransmit計數器

3）否則

AM RLC實體發送端應重啟t-Pollretransmit計數器

二、接收一個STATUS報告

當從接收端RLC AM實體接收到一個STATUS報告時

（1）如果狀態報告包含的RLC數據PDU的確認或否認序號等于POLL_SN

1）如果t-Pollretransmit計數器正在運行

AM RLC實體接收端應停止并重置t-Pollretransmit計數器

三、t-Pollretransmit計數器超時

（1）如果發送緩存器和接收緩存器同時為空（不包括還沒有被確認的RLC數據PDU）；或者（2）如果沒有新的RLC數據PDU能夠傳輸（如，窗口溢出）、1）AM RLC實體發送端認為SN＝VT（S）－1的AMD PDU需要重傳；或者

2）AMRLC實體發送端認為沒有被確認的AMD PDU需要重傳（3）AM RLC實體發送端在RLC數據PDU中包含一個poll 2.3 狀態報告

（1）AM RLC實體向它的對等端AM RLC實體發送STATUS來提供RLC PDU的確認或否認（2）RRC層可以配置RLC是否啟動狀態報告禁止功能（3）初始化STATUS報告觸發包括：

1）從對等端AM RLC實體發起的輪詢

當從下層接收到一個SN=x且P域被置為1的RLC數據PDU時

a.如果該PDU要被丟棄；或者

b.如果x＜VR（MS）或x≥VR（MR）

觸發STATUS報告 c.否則

延遲觸發STATUS直到x＜VR（MS）

（基于此可以確保RLC狀態報告是在HARQ重排序之后發送）2）檢測到一個RLC數據PDU接收失敗

AM RLC實體接收端應在t-Reordering計數器超時時觸發一次STATUS報告

（t-Reordering計數器的超同時觸發了VR（MS）的更新和STATUS報告的觸發。但STATUS報告的觸發應該在VR（MS）更新觸發之后）（2）當STATUS報告被觸發：

1）如果t-StatusProhibit計數器沒有運行

在下層指示的第一次重傳機會中，構建一個STATUS PDU并將其傳給下層

2）否則

在t-StatusProhibit計數器超時后，在下層指示的第一次重傳機會中，構建一個STATUS PDU即使在t-StatusProhibit計數器運行時已經觸發過很多次，并將此傳送給下層

（3）當一個STATUS PDU被傳送給下層時

1）AM RLC實體接收端應啟動t-StatusProhibit計數器（4）當構建一個STATUS PDU時

1）對于滿足VR（R）≤SN＜VR（MS）的還沒有被完全接收到的AMD PDU，按照SN的升序和PDU字節段升序的方式，從SN＝VR（R）開始知道這個STATUS PDU的大小已經達到下層只是發送機會的大小為止。

a.對于一個還沒有被接收到任何字節分段的AMD PDU

AM RLC實體接收端應在STATUS PDU中包含一個NACK_SN，并將其設為該AMD PDU的SN值

b.對于一個部分接收到的AMD PDU，它的一個還沒有被接收到的連續的字節分段

AM RLC實體接收端應在STATUS PDU中包含NACK_SN、SOstart及SOend

2）將ACK_SN設為下一個沒有被接收到的RLC數據PDU的SN，且其在STATUS PDU中

并不是丟失狀態

3、SDU丟棄過程

當上層指示丟棄一個特定的RLC SDU時，AM RLC實體發送端或UM RLC實體接收端應將還沒有任何分段映射到RLC AMD PDU的RLC SDU直接丟棄。

4、重建過程

RLC重建是在RRC層的請求下執行，這個功能為AM、UM和TM RLC實體均適用（1）當RRC層指示一個RLC實體需要一次重建時

1）如果該實體為TM RLC發送實體

則丟棄所有RLC SDU 2）如果該實體為UM RLC接收實體

a.在可能的情況下，在接收側從所有沒有被傳送的SN＜VT（MR）的AMD PDU中重組RLC SDU，并將所有重組完成的RLC SDU按照RLC SN的升序傳送給上層。

b.丟棄所有剩余的RLC SDU

3）如果該實體為UM RLC發送實體

丟棄所有的RLC SDU

4）如果該實體為AM RLC實體

a.在可能的情況下，在接收側將所有沒有被傳送的SN＜VR（MR）的UMD PDU重組為RLC SDU，去掉RLC頭，并將所有重組完成的RLC SDU按照RLC SN的升序傳送給上層。

b.丟棄接收側剩余的AMD PDU和AMD PDU字節分段

c.丟棄發送側所有的RLC SDU和AMD PDU

d.丟棄所有的RLC控制PDU

5）RLC實體應停止并重置所有計數器

6）RLC實體應重置所有狀態變量為初始值

5、對未知的、意外的以及錯誤的協議數據的處理

當一個RLC實體接收到包含著保留值或無效值的RLC PDU時

RLC實體應丟棄該接收到的PDU

零碎：（不在總結的整體結構之中但覺得應該對以后也有用的零散東西）

1、UM 傳輸解析

已提交的PDU

重排序窗口

還未接收 到PDU

丟失的PDU

丟失的PDU

VR(UH)-UM_window_size

VR(UR)需要 重排序PDU 的下邊界

VR(UH)接收到的 PDU最大序列號加1

已丟失PDU

已提交的PDU

還未收到的PDU

待組包的PDU其中重排序窗口的上邊界為當前收到的所有UMD PDU中序列號中最高的序列號加一獲得：用VR(UH)表示；重排序窗口的下邊界是由上邊界減去重排序窗口大小而得到的一個數值。如果新接收到的UMD PDU其序列號位于重排序窗口之外，則接收UM RLC實體認為其為新數據，相應更新重排序窗口的上邊界，并將該數據放入接收緩存，等待進一步處理。如果接收到的UMD PDU其序列號位于重排序窗口之內，則需要進一步判斷該序列號的 PDU 是否屬于重復接收或則已經超過了重排序等待時間，如果是這兩類PDU，則UM RLC接收實體直接采取刪除這個PDU；否則，這個UMD PDU是一個正常接收到的PDU，則放入接收緩存，等待進一步處理。

UM RLC接收實體基于重排序計時器進行重排序操作，重排序計時器的具體取值由高層配置。UM RLC 接收實體對未接收到的PDU對應的序列號啟動重排序計時器，在重排序計時器超時后，如果該PDU仍然沒有收到，則放棄對該PDU的等待并相應的更新重排序等待的下邊界；在重排序計時器超時前，收到了該PDU，則按照正常接收處理，將PDU放入接收緩存。UM RLC 接收實體并對每一個還沒有接收到的PDU對應序列號都啟動一個重排序計時器，而是整個接收UM RLC實體最多維護一個重排序計時器，以相應的變量記錄每一次啟動重排序計時器對應的序列號上邊界和下邊界，對該范圍內的所有序列號空缺統一處理，當該范圍內所有序列號空缺中的PDU都正確接收，則停止該重排序計時器；當該重排序計時器超時后，如果仍然有新的接收序列號空隙，則對后續所有新的空隙重啟重排序計時器，并記錄相應的重排序等待的序列號上邊界和下邊界。

對于UM RLC接收實體中放置于接收緩存中的PDU，一旦該PDU序列號超出了重排序窗口或者超出了目前重排序等待的下邊界，則將該UMD PDU去掉RLC頭部，重組成為RLC SDU并按照序列號的升序順序遞交到高層。

2、AM傳輸解析

已經收到的肯

VT（A）下一個將收到 確認的PDU序列號

已提交PDU后 請求重傳的PDU

VT（S）下一個將傳輸的PDU序列號

VT（MS）=VT（A）+ AM_Window_Size 定確認的PDU

發送窗口

AM RLC實體發送端優先發送重傳的RLC PDU，AM RLC實體發送端維護狀態變量VT(S)，含義為分配給下一個新生成的RLC PDU的序列號數值。該變量初始值為零，當生成一個新的 AMD PDU 時，將該變量作為該PDU的序列號，然后將該變量的數值加一。

AM RLC 實體發送端維護一個發送窗口，如圖所示，發送窗口的下邊界定義為收到接收端肯定確認且連續的最高PDU緊接著的下一個序列號的數值。發送窗口的上邊界為下邊界的數值加上窗口的大小。窗口大小為常數值 512，即為AM序列號空間長度 1024的一半。AM RLC實體發送端不會發送任何序列號位于發送窗口之外的AMD PDU到底層。AM RLC實體發送端根據對端發來的狀態PDU中包含的肯定確認來更新發送窗口變量，發送窗口的下邊界總是更新為當前發送窗口內的最小需要收到肯定確認的PDU的序列號。

AM RLC實體發送端根據對端發來的狀態PDU中包含的肯定確認來更新發送窗口變量，發送窗口的下邊界總是更新為當前發送窗口內的最小需要收到肯定確認的PDU的序列號。

AM RLC 實體接收端基于AMD PDU的序列號來完成窗口維護和更新，重復接收檢測、重排序和狀態報告等功能。AMD PDU的序列號10比特，窗口大小為512在進行序列號比較和判斷等操作時，需要考慮序列號翻轉問題。序列號實際取值范圍為[0,1023]，在對序列號進行比較判斷是需要進行模1024。

AM RLC實體接收端維護一個接收窗口，如圖所示，其中接收窗口的下邊界為當前接收到的連續AMD PDU中序列號最高的緊接著的一個序列號數值VR(R)；接收窗口的上邊界是由下邊界加上窗口大小而得到的數值。如果新接收到的AMD PDU其序列號位于接收窗口之外或者該PDU分段已經收到過，則AM RLC實體接收端刪除收到的數據；否則放入接收緩存，等待進一步處理，對已經收到的PDU分段，刪除其重復接收部分。

AM RLC實體接收端基于重排序計時器來進行重排序操作，重排序進行重排序操作，重排序計時器的具體取值由高層配置。在重排序計時器時后，該空隙處的 PDU 仍舊沒有收到，則認為檢測到RLC PDU接收失敗，根據情況發起狀態報告過程；在重排序計時器超時前，收到了空隙出的 PDU，則按照正常接受處理，將PDU放入接收緩存中，AM RLC實體接收端并不是對每一處序列號空隙都啟動一個重排序計時器，而是整個AM RLC實體接收端僅維護最多一個重排序計時器，以相應變量記錄每次啟動的重排序計時器對應的序列號上邊界和下邊界，對該范圍內的序列號空隙統一對待；該范圍內所有序列號空隙處的PDU都正確接收后，停止該重排序計時器；當該重排序計時器超時后，如果后續仍舊有新的接收序列號空隙，則對后續的空隙重啟重排序計時器，并記錄相應的重排序等待的序列號上邊界和下邊界。位于AM RLC實體接收端接收緩存中的PDU，一旦它們的序列號超出了接收窗口，則將該AMD PDU去掉RLC頭部，重組成為了RLC SDU并按照序列號的升序順序發送到高層。

ARQ過程

AMRLC實體發送端收到接收端的STATUS PDU有關AMD PDU或AMD PDU分段的否定確VR（R）

下一個完整接收的連續PDU的序列號

VR（MS）經過重排序檢測的PDU序列號上邊界

VR（H）接收到的PDU最大序列號加1 已提交的PDU

接收窗口

重排序以及狀態報告操作的時間窗

丟失的PDU 未成功接收 未成功接收 認，對于AMDPDU序列號位于發送窗口內的已發送部分，認為該確認的AMD PDU或AMD PDU分段需要重傳，記錄該AMD PDU或AMD PDU分段的重傳次數，初次重傳計數器為0，以后每次重傳計數器加1，當計數器大于重傳次數是，向上層報告。

重傳AMD PDU或AMD PDU分段式其輪詢比特需根據當前需要重新設置，當下層指示的傳輸機會中RLC PDU的大小足夠容納需要重傳的AMD PDU時，則直接發送該AMD PDU至下層，否則需要根據下層傳輸機會中指示的大小重新對需要重傳的AMD PDU進行分段，如果需要重傳數據本身為AMD PDU分段式，則根據需要切斷原始的AMD PDU的相應數據在和部分組成新的AMD PDU分段一適應下層指示的傳輸機會中RLC PDU的大小。在構造AMD PDU分段式，僅對原始AMD PDU的數據部分進行新的映射并按照實際分段和串接情況組織新的包頭，最終形成新的AMD PDU分段。

POLLING過程

Polling實現的方式為將RLC PDU中的P域（輪詢比特）置為1，發送攜帶Polling的RLC PDU后，記錄當前已經發送的PDU中最高的序列號為Polling序列號，并啟動或重啟動Polling重傳計數器。

當收到記錄的Polling序列號相關的肯定火否定確認后，停止并復位輪詢重傳計數器，此次輪詢過程結束。

當Polling計數器超時，則發起一次新的Polling過程。如果此時發送緩存和重傳緩存均為空或者沒有新的RLC PDU傳輸，則將當前已經傳輸過的序列號最高的AMD PDU或者任意沒有收到肯定確認的AMD PDU進行重傳，用以攜帶Polling比特。

3、狀態報告解析

AMD RLC 實體向對等端發送狀態報告，用以告知其 RLC PDU 的是否成功接收。觸發狀態報告的條件包括：

（1）接收到來自 AM RLC 實體對等端的探詢；

（2）檢測到 RLC PDU 的接收失敗。

需要注意的是，如果相關攜帶探詢的RLC PDU仍舊處于重排序計時器檢測的階段，則需要延遲到該 PDU 的接收狀態明確后再觸發狀態報告。

RRC 層可以配置RLC是否啟動狀態報告禁止功能。該功能主要是為了避免頻繁發送狀態報告。當狀態報告禁止功能開啟，則對于觸發的狀態報告只能延遲到狀態報告禁止計時器超時后的第一次傳輸機會才能根據最新的接收狀態發送；在狀態PDU發往底層之后，啟動狀態報告禁止計時器。狀態報告的內容包括兩部分：肯定確認部分（ACK_SN）和否定確認部分（NACK_SN）。其中否定確認部分為當前接收窗口中已經檢測到接收失敗的RLC PDU的序列號列表，并按照序列號和字節分段升序排列。當存在一個AMD PDU中部分字節而非全部接收失敗的情況，除了需要用序列號指示，還需要攜帶接收失敗部分的起始與終止字節位置。肯定確認部分設置為未在此狀態報告中包含并且緊接著的下一個沒有收到的RLC PDU的序列號。簡單來講，狀態報告的含義為除了在本狀態報告明確列出的接收失敗的RLC PDU或分段以外，其余所有已肯定確認指示（ACK SN）為上限的PDU均已經正確接收。

4、三種實體比較：

（1）對于TM/UM，各有一個發送與接收實體（2）AM接收發送同屬于一個實體

由于AM支持ARQ，發送端需要接收端提供確認信息來決定是否需要重傳，因此AM接收發送同屬于一個實體

5、RLC PDU：

（1）RLC數據PDU：

1）TMD PDU：因為透明傳輸，所以不需要做任何處理直接透傳到MAC

2）UMD PDU：

3）AMD PDU：第一次發送的RLC SDU的一部分生成的PDU，或者在重傳的時候不需要分段的PDU

4）AMD PDU segment：重傳的PDU需要分段，從而產生（2）RLC控制PDU：（3）STATUS PDU：

格式的選取取決于：

（1）對分段的支持（2）上層所使用的業務（3）針對AM實體的重傳機制的支持

6、ARQ與HARQ HARQ和ARQ都可以通過沖傳來糾正傳輸過程中的錯誤，因此看起來在RLC上的ARQ事多余的，但是在某些情況下HARQ并不能夠糾正所有的錯誤：（1）NACK重傳過程出錯被理解成ACK（2）HARQ重傳次數超過門限值 雖然上述錯誤概率很低，但TCP業務仍舊無法接受，在告訴移動數據業務室會導致性能降低。