欧美色欧美亚洲高清在线观看,国产特黄特色a级在线视频,国产一区视频一区欧美,亚洲成a 人在线观看中文

  1. <ul id="fwlom"></ul>

    <object id="fwlom"></object>

    <span id="fwlom"></span><dfn id="fwlom"></dfn>

      <object id="fwlom"></object>

      PDCP協(xié)議學(xué)習(xí)總結(jié)(合集五篇)

      時間:2019-05-12 08:44:29下載本文作者:會員上傳
      簡介:寫寫幫文庫小編為你整理了多篇相關(guān)的《PDCP協(xié)議學(xué)習(xí)總結(jié)》,但愿對你工作學(xué)習(xí)有幫助,當(dāng)然你在寫寫幫文庫還可以找到更多《PDCP協(xié)議學(xué)習(xí)總結(jié)》。

      第一篇:PDCP協(xié)議學(xué)習(xí)總結(jié)

      PDCP協(xié)議學(xué)習(xí)總結(jié)

      1、PDCP架構(gòu)

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

      2、PDCP實體:

      一個UE可以定義多個PDCP實體,可以對攜帶用戶面數(shù)據(jù)的每個PDCP實體進(jìn)行配置,來使用頭壓縮。每個PDCP實體攜帶一個無線承載的數(shù)據(jù)(復(fù)用為2個)。根據(jù)無線承載所攜帶的數(shù)據(jù),PDCP實體對應(yīng)于控制平面DCCH或者用戶平面DTCH

      3、PCDP層服務(wù) 向上層提供的服務(wù):(PDCP提供服務(wù)給UE的RRC層和用戶面高層)(1)數(shù)據(jù)傳輸

      (2)頭壓縮:IP包頭壓縮(3)加密

      (4)完整性保護(hù) 從下層得到的服務(wù):(RLC層向PDCP層提供服務(wù))

      (1)確認(rèn)的數(shù)據(jù)傳輸業(yè)務(wù),包括PDCP PDU成功傳輸?shù)闹甘荆?)非確認(rèn)的數(shù)據(jù)傳輸業(yè)務(wù)

      (3)有序傳送,除了在切換時的情況(4)重復(fù)丟棄,除了在切換時的情況

      4、PDCP層功能

      (1)發(fā)送和接收實體利用ROHC(ROBUST HEADER COMPRESSION)協(xié)議對IP數(shù)據(jù)流進(jìn)行相應(yīng)的頭壓縮和解壓縮

      (2)用戶面數(shù)據(jù)或者控制面數(shù)據(jù)的傳輸

      (3)維護(hù)RLC AM模式下的映射的無線承載的PDCP SN(4)下層重建時,上層PDU的有序傳送

      (5)下層重建時,RLC AM模式下的映射的無線承載的下層SDU重復(fù)消除(6)用戶面數(shù)據(jù)和控制面數(shù)據(jù)的加密和解密

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

      5、PDCP過程

      (1)PDCP數(shù)據(jù)傳輸過程 上行數(shù)據(jù)傳輸過程:每一個PDCP SDU對應(yīng)一個Discard Timer,一旦由高層接收到一個PDCP SDU,即啟動該SDU對應(yīng)的Discard Timer。同時,進(jìn)行發(fā)送相關(guān)的狀態(tài)變量更新及加密、完整性保護(hù)等,PDCP SDU的Discard_Timer超時或PDCP SDU的成功傳輸有PDCp狀態(tài)報告確認(rèn),UE丟棄PDCP SDU及相應(yīng)的PDCP PDU

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

      (2)重建過程

      上行數(shù)據(jù)傳輸過程:映射到RLC AM的DRB過程 映射到RLC UM的DRB過程 SRB過程 下行數(shù)據(jù)傳輸過程:映射到RLC AM的DRB過程 映射到RLC UM的DRB過程 SRB過程(4)PDCP丟棄:PDCP SDU的Discard_Timer超時或PDCP SDU的成功傳輸有PDCp狀態(tài)報告確認(rèn),UE丟棄PDCP SDU及相應(yīng)的PDCP PDU(5)頭壓縮與解壓縮:

      (6)加密和解密:加密不用于PDCP控制PDU 控制面:PDCP PDU中數(shù)據(jù)部分及MAC-I 用戶面:PDCP PDU的數(shù)據(jù)部分

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

      (7)完整性保護(hù)及確認(rèn):該功能僅用于SRB(8)未知的、意外的以及錯誤的協(xié)議數(shù)據(jù)的處理

      6、PDCP協(xié)議數(shù)據(jù)單元及格式

      PDCP數(shù)據(jù)PDU傳送:一個PDU SDU SN、包含一個基于非壓縮的PDCP SDU用戶面數(shù)據(jù)、包含一個基于壓縮的PDCP SDU用戶面數(shù)據(jù)、控制平面數(shù)據(jù)、只有SRB的MAC-I域 PDCP控制PDU傳送:PDCP狀態(tài)報告、頭壓縮信息

      5.5 頭壓縮與解壓縮

      5.5.1 協(xié)議與簡表

      頭壓縮協(xié)議基于可靠性頭壓縮(ROHC)框架,存在多種頭壓縮算法,成為簡表,定義用于ROHC框架。每個簡表為特定的網(wǎng)絡(luò)層、傳輸層或上層集合所專用。5.5.2 頭壓縮配置

      與DRB關(guān)聯(lián)的PDCP實體可被上層配置來使用頭壓縮 5.5.3 協(xié)議參數(shù)

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

      生成兩種類型的輸出數(shù)據(jù)包:

      (1)壓縮包,各自關(guān)聯(lián)于一個PDCP SDU(與相關(guān)PDCP SDU相同的PDCP SN和COUNT關(guān)聯(lián))(2)獨(dú)立數(shù)據(jù)包,為關(guān)聯(lián)于PDCP SDU,即零散的ROHC反饋包(不與PDCP SDU關(guān)聯(lián),不與PDCP SN關(guān)聯(lián),不加密)5.5.5 頭解壓縮

      如果上層為關(guān)聯(lián)與用戶平面數(shù)據(jù)的PDCP實體配置了頭解壓縮,則PDCP PDU將在執(zhí)行解密程序后由頭解壓協(xié)議進(jìn)行解壓縮

      5.6 加密和解密

      1、對于控制平面,加密的數(shù)據(jù)單元是PDCP PDU以及MAC-I的部分?jǐn)?shù)據(jù)

      2、對于用戶平面,加密的數(shù)據(jù)單元是PDCP PDU的部分?jǐn)?shù)據(jù)

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

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

      5、加密功能由上層激活,激活后,應(yīng)用于所有上層指示的上下行PDCP PDU

      7、PDCP請求的,由上層提供的參數(shù):BEARER、KEY(控制面/用戶面)(1)BEARER:承載的標(biāo)識,用于RB身份的標(biāo)識

      (2)DIRECTION:標(biāo)識傳輸?shù)姆较颍?用于上行、1用于下行

      (3)KEY:控制平面和用戶平面的加密密鑰分別為KRRCenc與KUPenc

      5.7 完整性保護(hù)及確認(rèn)

      1、完整性保護(hù)+完整性確認(rèn)

      2、用于與SRB關(guān)聯(lián)的PDCP

      3、受完整性保護(hù)的數(shù)據(jù)單元為:PDU頭和加密前的PDU部分?jǐn)?shù)據(jù)

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

      5、完整性保護(hù)功能由上層激活,激活后,應(yīng)用于從上層指定的PDU之后的上下行PDCP PDU

      7、PDCP請求的,由上層提供的數(shù):BEARER、KEY

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

      接收時,UE通過基于以上指定的輸入?yún)?shù)計算X-MAX來確認(rèn)PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應(yīng),則完整性保護(hù)確認(rèn)成功

      5.8 未知的、意外的以及錯誤的協(xié)議數(shù)據(jù)的處理

      PDCP收到一個包括保留值或非法值的PDCP PDU時,PDCP實體應(yīng)丟棄收到的PDU

      補(bǔ)充PDCP實現(xiàn)LTE 接入層安全性過程

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

      接入層的安全性是通過加密算法和完整性保護(hù)算法來實現(xiàn)的。接收時,UE通過基于以上指定的輸入?yún)?shù)計算X-MAX來確認(rèn)PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應(yīng),則完整性保護(hù)確認(rèn)成功

      第二篇:PDCP協(xié)議學(xué)習(xí)總結(jié)

      PDCP協(xié)議學(xué)習(xí)總結(jié)

      1、PDCP架構(gòu)

      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實體,可以對攜帶用戶面數(shù)據(jù)的每個PDCP實體進(jìn)行配置,來使用頭壓縮。每個PDCP實體攜帶一個無線承載的數(shù)據(jù)。根據(jù)無線承載所攜帶的數(shù)據(jù),PDCP實體對應(yīng)于控制平面或者用戶平面

      3、PCDP層服務(wù)

      向上層提供的服務(wù):(PDCP提供服務(wù)給UE的RRC層和用戶面高層)(1)數(shù)據(jù)傳輸(2)頭壓縮(3)加密(4)完整性保護(hù)

      從下層得到的服務(wù):(RLC層向PDCP層提供服務(wù))

      (1)確認(rèn)的數(shù)據(jù)傳輸業(yè)務(wù),包括PDCP PDU成功傳輸?shù)闹甘荆?)非確認(rèn)的數(shù)據(jù)傳輸業(yè)務(wù)

      (3)有序傳送,除了在切換時的情況(4)重復(fù)丟棄,除了在切換時的情況

      4、PDCP層功能

      (1)發(fā)送和接收實體利用ROHC協(xié)議對IP數(shù)據(jù)流進(jìn)行相應(yīng)的頭壓縮和解壓縮(2)用戶面數(shù)據(jù)或者控制面數(shù)據(jù)的傳輸

      (3)維護(hù)RLC AM模式下的映射的無線承載的PDCP SN(4)下層重建時,上層PDU的有序傳送

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

      5、PDCP過程(具體過程見page 3)(1)PDCP數(shù)據(jù)傳輸過程 上行數(shù)據(jù)傳輸過程:每一個PDCP SDU對應(yīng)一個Discard Timer,一旦由高層接收到一個PDCP SDU,即啟動該SDU對應(yīng)的Discard Timer。同時,進(jìn)行發(fā)送相關(guān)的狀態(tài)變量更新及加密、完整性保護(hù)等,具體過程如圖2所示。

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

      (2)重建過程

      上行數(shù)據(jù)傳輸過程:映射到RLC AM的DRB過程

      映射到RLC UM的DRB過程 SRB過程 下行數(shù)據(jù)傳輸過程:映射到RLC AM的DRB過程

      映射到RLC UM的DRB過程 SRB過程(3)PDCP狀態(tài)報告 傳輸:

      接收:

      (4)PDCP丟棄:PDCP SDU的Discard_Timer超時或PDCP SDU的成功傳輸有PDCp狀態(tài)報告確認(rèn),UE丟棄PDCP SDU及相應(yīng)的PDCP PDU(5)頭壓縮與解壓縮:

      (6)加密和解密:加密不用于PDCP控制PDU 控制面:PDCP PDU中數(shù)據(jù)部分及MAC-I 用戶面:PDCP PDU的數(shù)據(jù)部分

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

      (7)完整性保護(hù)及確認(rèn):該功能僅用于SRB(8)未知的、意外的以及錯誤的協(xié)議數(shù)據(jù)的處理

      6、PDCP協(xié)議數(shù)據(jù)單元及格式

      PDCP數(shù)據(jù)PDU傳送:一個PDU SDU SN、包含一個基于非壓縮的PDCP SDU用戶面數(shù)據(jù)、包含一個基于壓縮的PDCP SDU用戶面數(shù)據(jù)、控制平面數(shù)據(jù)、只有SRB的MAC-I域 PDCP控制PDU傳送:PDCP狀態(tài)報告、頭壓縮信息

      7、參數(shù)

      (1)PDCP SN:

      (2)DATA:未壓縮PDCP SDU(用戶面或控制面數(shù)據(jù))/壓縮PDCP SDU(用戶面數(shù)據(jù))(3)MAC-I:消息認(rèn)證碼、未經(jīng)過完整性保護(hù)的控制面數(shù)據(jù)MAC-I用0填充(4)COUNT:HFN+PDCP SN(5)R:保留位

      (6)D/C:控制PDU或數(shù)據(jù)PDU(7)PDU type:status/ROHC/received(8)FMS:第一個丟失的PDCP SDU的PDCP SN值

      (9)Bitmap:PDCP SDU是否被接收并正確的進(jìn)行選擇性解壓

      8、變量

      PDCP實體發(fā)送端

      (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:傳輸?shù)缴蠈拥淖詈笠粋€PDCP SDU的SN,實體重建4095

      9、常量

      (1)Reordering_Window:2048,PDCP SN的一半,用于無線承載應(yīng)設(shè)在RLC AM上的情況(2)Maximum_PDCP_SN:

      10、定時器

      (1)Discard_Timer丟棄定時器(2)Flush_Timer清空定時器

      5.1 數(shù)據(jù)傳輸過程

      5.1.1 上行

      從上層接收到PDCP SDU后

      UE啟動與此PDCP相關(guān)量的discardTimer 對于從上層接收到的PDCP SDU UE應(yīng)關(guān)聯(lián)相應(yīng)于Next_PDCP_TX_SN的PDCP SN到PDCP SDU UE應(yīng)執(zhí)行PDCP SDU頭壓縮 UE應(yīng)執(zhí)行完整性保密

      UE應(yīng)使用基于TX_HFN的COUNT以及關(guān)聯(lián)于PDCP SDU的PDCP SN值進(jìn)行加密 UE將Next_PDCP_TX_SN加1 若果Next_PDCP_TX_SN﹥Maximum_PDCP_SN UE應(yīng)將Next_PDCP_TX_SN置0 UE應(yīng)將TX_HFN加1 UE應(yīng)將最后產(chǎn)生的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應(yīng)使用基于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應(yīng)使用基于RX_HFN的COUNT與接收到的PDCP SN值,解密此PDCP PDU 3)UE應(yīng)執(zhí)行頭壓縮

      4)UE應(yīng)丟棄此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應(yīng)將Next_HFN加1 2)UE應(yīng)使用基于RX_HFN的COUNT與接收到的PDCP SN解密此PDCP PDU 3)UE應(yīng)將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應(yīng)使用基于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應(yīng)使用基于RX_HFN的COUNT與接收到的PDCP SN解密此PDCP PDU 2)UE應(yīng)將Next_PDCP_RX_SN置為接收到的PDCP SN+1 3)如果Next_PDCP_RX_SN>Maximum_PDCP_SN UE應(yīng)將Next_PDCP_RX_SN置0 UE應(yīng)將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應(yīng)使用基于RX_HFN的COUNT值域接收到的PDCP SN值解密此PDCP PDU(7)如果上面沒有丟棄此PDCP PDU 1)UE應(yīng)執(zhí)行PDCP PDU的解密與頭壓縮

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

      UE應(yīng)存儲此PDCP SDU 4)如果由于下層重建導(dǎo)致PDCP沒有接收到此PDCP PDU UE應(yīng)把相關(guān)的COUNT值按照升序傳遞給上層:

      a.所有存儲的,相關(guān)COUNT值小于接收PDCP SDU的COUNT值的PDCP SDU b.所有存儲的,從接收到的PDCP SDU的COUNT值開始,連續(xù)COUNT值對應(yīng)的PDCPSDU UE應(yīng)將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應(yīng)把相關(guān)COUNT值按照升序傳遞給上層

      a.所有存儲的,從接收到的PDCP SDU的COUNT值開始,連續(xù)COUNT值對應(yīng)的PDCP SDU UE應(yīng)將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應(yīng)將RX_HFN加1(2)UE應(yīng)使用基于RX_HFN的COUNT值與接收到的PDCP SN值來解密此PDCP Data PDU(3)如果Next_PDCP_RX_SN>Maximum_PDCP_SN 1)UE應(yīng)將Next_PDCP_RX_SN置0 2)UE應(yīng)將RX_HFN﹢1(4)執(zhí)行已解密的PDCP Data PDU的頭壓縮(5)UE應(yīng)將最后產(chǎn)生的PDCP SDU遞交給上層

      二、SRB過程

      對于SRB,在接收到低層的PDCP Data PDU后(1)如果接收的PDCP SN<Next_PDCP_RX_SN 1)UE應(yīng)使用基于RX_HFN﹢1的COUNT與接收到的PDCP SN值來解密此PDU以及確認(rèn)其完整性

      (2)否則

      1)UE應(yīng)使用基于RX_HFN的COUNT與接收到的PDCP SN值來解密此PDU以及確認(rèn)其完整性

      (3)如果完整性確認(rèn)使用并成功通過,或

      (4)如果完整性確認(rèn)不適用

      1)如果接收的PDCP SN<Next_PDCP_RX_SN UE應(yīng)將RX_HFN加1 2)UE應(yīng)將Next_PDCP_RX_SN置為接收到的PDCP SN﹢1 3)如果Next_PDCP_RX_SN>Maximum_PDCP_SN UE應(yīng)將Next_PDCP_RX_SN置0 UE應(yīng)將RX_HFN加1 4)UE應(yīng)將最后產(chǎn)生的PDCP SDU遞交給上層(5)否則,如果完整性確認(rèn)適用,但失敗

      1)UE應(yīng)丟棄接收到的PDCP Data PDU 2)UE應(yīng)將完整性確認(rèn)失敗報告遞交給上層

      5.2 重建過程

      5.2.1 上行

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

      (1)UE應(yīng)重置上行鏈路的頭壓縮協(xié)議

      (2)重建過程期間,UE應(yīng)使用加密算法及上層提供的密鑰加密

      (3)從第一個對應(yīng)的PDCP PDU成功傳遞但沒有被下層確認(rèn)的PDCP SDU開始,在如PDCP重建之前,執(zhí)行所有由與此PDCP SDU對應(yīng)的COUNT開始的,按照COUNT升序排列的PDCP SN值對應(yīng)的PDCP SDU的重傳或傳輸(4)UE應(yīng)執(zhí)行DCP SDU的頭壓縮

      (5)UE應(yīng)使用與此PDCP SDU關(guān)聯(lián)的COUNT值來加密此PDCP SDU(6)UE應(yīng)將最后產(chǎn)生的PDCP Data PDU傳遞給下層

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

      (1)UE應(yīng)重置上行鏈路的頭壓縮協(xié)議

      (2)UE應(yīng)置Next_PDCP_TX_SN以及TX_HFN為0(3)重建過程期間,UE應(yīng)使用加密算法及上層提供的密鑰加密

      (4)對于每一個已經(jīng)對應(yīng)于一個PDCP SN,但相應(yīng)的PDU沒有事先傳遞給低層的PDCP SDU 1)UE認(rèn)為此PDCP SDU是從上層接收而來

      2)在PDCP重建之前,在不重啟discardTimer的情況下,UE應(yīng)按照與PDCP SDU關(guān)聯(lián)的COUNT值的升序傳輸PDCP SDU

      3、SRB過程

      當(dāng)上層請求一次PDCP重建時

      (1)UE應(yīng)置Next_PDCP_TX_SN及TX_HFN為0(2)UE應(yīng)丟棄所有存儲的PDCP SDU和PDCP PDU(3)重建過程期間,UE應(yīng)使用加密和完整性保護(hù)算法,以及使用上層提供的密鑰進(jìn)行加密

      5.2.2 下行

      1、映射到RLC AM的DRB過程

      當(dāng)上層請求一次PDCP重建時

      (1)UE應(yīng)處理由于下層重建而從下層接收到的PDCP Data PDU(2)UE應(yīng)重置下行鏈路的頭壓縮協(xié)議

      (3)重建過程期間,UE應(yīng)使用加密算法和上層提供的密鑰進(jìn)行加密

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

      (1)UE應(yīng)處理由于下層重建而從下層接收到的PDCP Data PDU(2)UE 應(yīng)重置下行鏈路的頭壓縮協(xié)議

      (3)UE應(yīng)將Next_PDCP_RX_SN及RX_HFN置0(4)重建過程奇跡,UE應(yīng)使用加密算法和上層提供的密鑰進(jìn)行加密

      3、SRB過程

      當(dāng)上層請求一次PDCP重建時

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

      5.3 PDCP狀態(tài)報告

      5.3.1 傳輸

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

      如果此RB被上層配置用于在上行鏈路發(fā)送一個PDCP狀態(tài)報告,在處理完因下層重建而從下層接收來的PDCP Data PCU以后,UE應(yīng)按下述指示進(jìn)行狀態(tài)報告:(1)UE應(yīng)將FMS置為第一個丟失的PDCP SDU的PDCP SN值

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

      (3)UE將所有低層指示還未接受到的PDCP SDU以及任意解壓縮失敗的PDCP SDU在Bitmap field中對應(yīng)的區(qū)域置0(4)對于其他的PDCP SDU,對應(yīng)區(qū)域置1 5.3.2 接收

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

      5.4 PDCP丟棄

      當(dāng)用于PDCP SDU的discardTimer終止,或PDCP SDU的成功傳輸被PDCP狀態(tài)報告確認(rèn),UE應(yīng)就其此PDCP SDU及其對應(yīng)的PDCP PDU。如果對應(yīng)的PDCP PDU已經(jīng)成功傳遞給下層,則丟棄需要指示給下層。

      5.5 頭壓縮與解壓縮

      5.5.1 協(xié)議與簡表

      頭壓縮協(xié)議基于可靠性頭壓縮(ROHC)框架,存在多種頭壓縮算法,成為簡表,定義用于ROHC框架。每個簡表為特定的網(wǎng)絡(luò)層、傳輸層或上層集合所專用。5.5.2 頭壓縮配置

      與DRB關(guān)聯(lián)的PDCP實體可被上層配置來使用頭壓縮 5.5.3 協(xié)議參數(shù)

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

      生成兩種類型的輸出數(shù)據(jù)包:

      (1)壓縮包,各自關(guān)聯(lián)于一個PDCP SDU(與相關(guān)PDCP SDU相同的PDCP SN和COUNT關(guān)聯(lián))(2)獨(dú)立數(shù)據(jù)包,為關(guān)聯(lián)于PDCP SDU,即零散的ROHC反饋包(不與PDCP SDU關(guān)聯(lián),不與PDCP SN關(guān)聯(lián),不加密)

      5.5.5 頭解壓縮

      如果上層為關(guān)聯(lián)與用戶平面數(shù)據(jù)的PDCP實體配置了頭解壓縮,則PDCP PDU將在執(zhí)行解密程序后由頭解壓協(xié)議進(jìn)行解壓縮

      5.6 加密和解密

      1、對于控制平面,加密的數(shù)據(jù)單元是PDCP PDU以及MAC-I的部分?jǐn)?shù)據(jù)

      2、對于用戶平面,加密的數(shù)據(jù)單元是PDCP PDU的部分?jǐn)?shù)據(jù)

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

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

      5、加密功能由上層激活,激活后,應(yīng)用于所有上層指示的上下行PDCP PDU

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

      7、PDCP請求的,由上層提供的參數(shù):BEARER、KEY(控制面/用戶面)(1)BEARER:承載的標(biāo)識,用于RB身份的標(biāo)識

      (2)DIRECTION:標(biāo)識傳輸?shù)姆较颍?用于上行、1用于下行(3)KEY:控制平面和用戶平面的加密密鑰分別為KRRCenc與KUPenc

      5.7 完整性保護(hù)及確認(rèn)

      1、完整性保護(hù)+完整性確認(rèn)

      2、用于與SRB關(guān)聯(lián)的PDCP

      3、受完整性保護(hù)的數(shù)據(jù)單元為:PDU頭和加密前的PDU部分?jǐn)?shù)據(jù)

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

      5、完整性保護(hù)功能由上層激活,激活后,應(yīng)用于從上層指定的PDU之后的上下行PDCP PDU

      6、完整性保護(hù)算法的輸入:COUNT、DIRECTION

      7、PDCP請求的,由上層提供的數(shù):BEARER、KEY

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

      接收時,UE通過基于以上指定的輸入?yún)?shù)計算X-MAX來確認(rèn)PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應(yīng),則完整性保護(hù)確認(rèn)成功

      5.8 未知的、意外的以及錯誤的協(xié)議數(shù)據(jù)的處理

      PDCP收到一個包括保留至或非法值的PDCP PDU時,PDCP實體應(yīng)丟棄收到的PDU

      補(bǔ)充PDCP實現(xiàn)LTE 接入層安全性過程

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

      接入層的安全性是通過加密算法和完整性保護(hù)算法來實現(xiàn)的。

      接收時,UE通過基于以上指定的輸入?yún)?shù)計算X-MAX來確認(rèn)PDCP PDU的完整性。如果計算得到的X-MAC與接收的MAC-I值相對應(yīng),則完整性保護(hù)確認(rèn)成功

      第三篇:Coap協(xié)議學(xué)習(xí)總結(jié)

      Coap協(xié)議學(xué)習(xí)總結(jié)

      1、Coap協(xié)議介紹

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

      為了克服HTTP對于受限環(huán)境的劣勢,CoAP既考慮到數(shù)據(jù)報長度的最優(yōu)化,又考慮到提供可靠通信。一方面,CoAP提供URI,REST 式的方法如GET,POST,PUT和DELETE,以及可以獨(dú)立定義的頭選項提供的可擴(kuò)展性。另一方面,CoAP基于輕量級的UDP協(xié)議,并且允許IP 多播。而組通信是物聯(lián)網(wǎng)最重要的需求之一,比如說用于自動化應(yīng)用中。為了彌補(bǔ)UDP傳輸?shù)牟豢煽啃裕珻oAP定義了帶有重傳機(jī)制的事務(wù)處理機(jī)制。并且提供 資源發(fā)現(xiàn)機(jī)制,并帶有資源描述。

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

      事務(wù)層(Transaction layer)用于處理節(jié)點(diǎn)之間的信息交換,同時提供組播和擁塞控制等功能。請求/響應(yīng)層(Request/Responselayer)用于傳輸對資源進(jìn)行操作的請求和響應(yīng)信息。CoAP協(xié)議的REST構(gòu)架是基于該層的通信。CoAP的雙層處理方式,使得CoAP沒有采用TCP協(xié)議,也可以提供可靠的傳輸 機(jī)制。利用默認(rèn)的定時器和指數(shù)增長的重傳間隔時間實現(xiàn)CON(Confirmable)消息的重傳,直到接收方發(fā)出確認(rèn)消息。另外,CoAP的雙層處理方 式支持異步通信,這是物聯(lián)網(wǎng)和M2M應(yīng)用的關(guān)鍵需求之一。

      2、CoAP協(xié)議是否可以替換HTTP協(xié)議?

      CoAP并不能替代HTTP協(xié)議,但是對于那些小設(shè)備(256KB Flash 32KB RAM 20MHz主頻)而言CoAP的確是一個好的解決方案。

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

      CoAP使用類似于HTTP的請求/響應(yīng)模型:CoAP終端節(jié)點(diǎn)作為客戶端向服務(wù)器發(fā)送一個或多個請求,服務(wù)器端回復(fù)客戶端的CoAP請求。不同于 HTTP,CoAP的請求和響應(yīng)在發(fā)送之前不需要事先建立連接,而是通過CoAP信息來進(jìn)行異步信息交換。CoAP協(xié)議使用UDP進(jìn)行傳輸。這是通過信息層選項的可靠性來實現(xiàn)的。CoAP采用和HTTP協(xié)議相同的請求響應(yīng)工作模式。CoAP協(xié)議共有4中不同的消息類型。

      CON——需要被確認(rèn)的請求,如果CON請求被發(fā)送,那么對方必須做出響應(yīng)。NON——不需要被確認(rèn)的請求,如果NON請求被發(fā)送,那么對方不必做出回應(yīng)。ACK——應(yīng)答消息,如果接受到CON消息的響應(yīng)。

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

      4、CoAP消息結(jié)構(gòu)

      一個CoAP消息最小為4個字節(jié),以下是CoAP協(xié)議不同部分的描述?!景姹綱ersion】:類似于IPv6和IPv6,僅僅是一個版本號。

      【消息類型Message Type】:CON,NON,ACK,RST。這些消息類型相當(dāng)于HTTP協(xié)議的PUTGET等

      【消息ID Message ID】:每個CoAP消息都有一個ID,在一次會話中ID總是保持不變。但是在這個會話之后該ID會被回收利用?!緲?biāo)記 Token】:標(biāo)記是ID的另一種表現(xiàn)、【選項 Options】:CoAP選項類似于HTTP請求頭,它包括CoAP消息本身,例如CoAP端口號,CoAP主機(jī)和CoAP查詢字符串等?!矩?fù)載Payload】:真正有用的被交互的數(shù)據(jù)。

      圖 CoAP消息結(jié)構(gòu)

      5、CoAP的URL

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

      6、CoAP觀察模式

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

      7、CoAP塊傳輸

      CoAP協(xié)議的特點(diǎn)是傳輸?shù)膬?nèi)容小巧精簡,但是在某些情況下不得不傳輸較大的數(shù)據(jù)。在這種情況下可以使用CoAP協(xié)議中的某個選項設(shè)定分塊傳輸?shù)拇笮。敲礋o論是服務(wù)器或客戶端可完成分片和組裝這兩個動作。

      8、CoAP協(xié)議的特點(diǎn):

      (1)報頭壓縮:CoAP包含一個緊湊的二進(jìn)制報頭和擴(kuò)展報頭。它只有短短的4 B的基本報頭,基本報頭后面跟擴(kuò)展選項。一個典型的請求報頭為10~20B。

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

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

      (4)支持異步通信:HTTP對M2M(Machine-to-Machine)通信不適用,這是由于事務(wù)總是由客戶端發(fā)起。而CoAP協(xié)議支持異步通信,這對M2M通信應(yīng)用來說是常見的休眠/喚醒機(jī)制。

      (5)支持資源發(fā)現(xiàn):為了自主的發(fā)現(xiàn)和使用資源,它支持內(nèi)置的資源發(fā)現(xiàn)格式,用于發(fā)現(xiàn)設(shè)備上的資源列表,或者用于設(shè)備向服務(wù)目錄公告自己的資源。它支持RFC5785中的格式,在CoRE中用/.well—known/core的路徑表示資源描述。

      (6)支持緩存:CoAP協(xié)議支持資源描述的緩存以優(yōu)化其性能。

      (7)訂閱機(jī)制:CoAP使用異步通信方式,用訂閱機(jī)制實現(xiàn)從服務(wù)器到客戶端的消息推送。實現(xiàn)CoAP的發(fā)布,訂閱機(jī)制,它是請求成功后自動注冊的 一種資源后處理程序。是由默認(rèn)的EVENT_和PERIODIC_RESOURCEs來進(jìn)行配置的。它們的事件和輪詢處理程序用 EST.notify_subscri bers()函數(shù)來發(fā)布。

      9、CoAP協(xié)議的火狐瀏覽器實現(xiàn)(B/S架構(gòu))

      B/S架構(gòu)的系統(tǒng)結(jié)構(gòu)如圖9所示

      系統(tǒng)由用戶瀏覽器、Web服務(wù)器、IPv6智能網(wǎng)關(guān)、MX231CC節(jié)點(diǎn)組成。用戶瀏覽器通過HTTP協(xié)議訪問Web服務(wù)器,MX231CC節(jié)點(diǎn)通 過CoAP協(xié)議和IPv6智能網(wǎng)關(guān)進(jìn)行通信,從而實現(xiàn)用戶瀏覽器訪問節(jié)點(diǎn)上資源的功能。圖9中實線表示有線連接,虛線表示無線連接。

      在當(dāng)前的Contiki 2.5中,集成了CoAP 03和CoAP06這兩個版本。這兩個文件在Contiki 2.5的apps目錄下,關(guān)于CoAP的核心內(nèi)容都在這兩個文件中。程序的主要部分為:

      AUTOSTART_PROCESSES(PERIODIC_RESOURCE()為進(jìn)程的主體部分。

      然后進(jìn)行編譯,編譯成.elf文件,用JTAG下載器下載到節(jié)點(diǎn)上。節(jié)點(diǎn)地址設(shè)置為:2001:2::11:22ff::fe33:4499.這時,用火狐瀏覽器訪問節(jié)點(diǎn),因為火狐瀏覽器自帶coap插件,如果用其他瀏覽器,那么需要進(jìn)行coap的代理設(shè)置。以控制節(jié)點(diǎn)上的三色LED燈反轉(zhuǎn)為例,用下 面的請求格式:GETcoap://[]:

      /readings其中mote_ip_address是節(jié)點(diǎn)的IPv6地址,port_number是節(jié)點(diǎn)的端口號,readings是客戶端請求的資源(溫度)。

      所以在瀏覽器地址欄輸入:coap://[2001:2::11:22ff:fe33:4499]:61616/toggle,作用是讓節(jié)點(diǎn)上的三色LED燈進(jìn)行反轉(zhuǎn)。服務(wù)器端的響應(yīng)信息如圖10所示。

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

      由此可以看出,通過火狐瀏覽器的CoAP協(xié)議,可以訪問節(jié)點(diǎn)上的傳感器資源。

      10、CoAP協(xié)議的客戶端實現(xiàn)(C/S架構(gòu))

      通過火狐瀏覽器可以實現(xiàn)COAP協(xié)議,但是只能查看實時數(shù)據(jù),不能查看歷史數(shù)據(jù)。為此,這里搭建了一個C/S架構(gòu)的環(huán)境。如圖11所示。

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

      插入數(shù)據(jù)庫中的數(shù)據(jù)如圖12所示,圖中顯示的是室內(nèi)的亮度值。

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

      由此看出,基于C/S架構(gòu)的方式,不僅可以顯示實時數(shù)據(jù),還可以查看歷史數(shù)據(jù),以便及時發(fā)現(xiàn)問題,更加具有實用性。

      第四篇:MODBUS通訊協(xié)議學(xué)習(xí)總結(jié)

      MODBUS通訊協(xié)議學(xué)習(xí)總結(jié)

      1、協(xié)議分3個層次看:

      協(xié)議應(yīng)用函數(shù)層,如讀寫coil,寄存器; RTU或者ASCII傳輸層 硬件底層

      2、比如上位機(jī)發(fā)來:01 06 00 01 02 D5 00 55 含義:表示上午12點(diǎn)05分開始采集,12*60+5=725=0X02D5 01地址

      06表示功能碼 00 01寄存器地址 02 D5數(shù)據(jù) 00 55 crc

      3、就當(dāng)是一個簡單的協(xié)議看。其它的都是格式。比如:上位機(jī)發(fā)送A,下位機(jī)知道這個是>90分

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

      比如:從機(jī)地址,可以寫01-FF 255個這個是從機(jī)先固定好的。比如從機(jī)是01。上位機(jī)發(fā)了一串16進(jìn)制數(shù)據(jù),如果第一個字節(jié)是01,說明是在和自己通信。每臺從機(jī)地址都不一樣

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

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

      5、還有一個crc判斷。讀數(shù)據(jù)的時候,判斷下。如果上位機(jī)發(fā)過來的crc,和自己計算出來的crc一樣,才給返回數(shù)據(jù)

      6、那個CRC怎么計算呢?

      有固定的計算格式,只需調(diào)用即可。crc 在通過modbus串口傳數(shù)據(jù)的時候用,網(wǎng)絡(luò)上不用。

      第五篇:RLC協(xié)議學(xué)習(xí)總結(jié)

      RLC協(xié)議學(xué)習(xí)總結(jié)

      1、RLC構(gòu)架

      圖1 RLC架構(gòu)

      2、RLC實體

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

      業(yè)務(wù)類型:廣播消息的固定部分、尋呼消息、RRC消息等

      圖2 TM模式兩個對等實體

      發(fā)送實體:不對RLC SDU進(jìn)行串聯(lián)、分段

      沒有RLC頭

      對RLC SDU不做任何改動,向下層發(fā)送

      接收實體:不做任何修改,一腳RLC SDU到上層協(xié)議實體

      (2)UM RLC實體:適用于延時敏感和容忍差錯的實時應(yīng)用

      (DL/UL DTCH)RLC SDU分塊、串聯(lián)、重排序、重復(fù)檢測、重組

      業(yè)務(wù)類型:VoIP、MBMS

      圖3 UM模式兩個對等實體

      發(fā)送實體:在獲得特定的發(fā)送機(jī)會時,要根據(jù)MAC層指示期待的RLC PDU大小進(jìn)行分段或者串接RLC SDU

      添加相應(yīng)的RLC頭

      接收實體:檢測收到的UMD PDU是否重復(fù),重復(fù)則丟棄

      重排失序的UMD PDU

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

      若發(fā)現(xiàn)某RLC SDU的UMD PDU丟失,則丟棄其他同RLC SDU的PDU(3)AM RLC實體:適用于錯誤敏感、時延容忍的非實時應(yīng)用

      (DL/UL DCCH/DTCH)UM RLC功能+RLC數(shù)據(jù)PDU重傳、重傳RLC數(shù)據(jù)PDU再分快、輪詢、狀態(tài)報告、狀態(tài)禁止

      業(yè)務(wù)類型:FTP、WWW、RRC消息等

      圖4 AM模式實體

      3、RLC層服務(wù)

      RLC層向上層提供的服務(wù):(RLC層向PDCP層提供服務(wù))(1)TM數(shù)據(jù)傳輸:分段和重組、用戶數(shù)據(jù)的傳輸

      (2)UM數(shù)據(jù)傳輸:分段和重組、串聯(lián)、填充、用戶數(shù)據(jù)的傳輸、加密、序號檢查

      (3)AM數(shù)據(jù)傳輸:分段和重組、串聯(lián)、填充、用戶數(shù)據(jù)的傳輸、糾錯、按序傳送高層PDU、副本檢測、流量控制、協(xié)議錯誤檢測和恢復(fù)、加密 RLC層從下層得到的服務(wù)(1)數(shù)據(jù)傳輸

      (2)通知發(fā)送時機(jī),同時提供當(dāng)次傳輸時發(fā)送RLC PDU的總大?。?)通知HARQ重傳失敗

      4、RLC層功能

      (1)高層PDU傳輸

      (2)通過ARQ進(jìn)行糾錯(AM)

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

      (9)協(xié)議錯誤及恢復(fù)

      5、RLC過程(具體過程見page 6)(1)數(shù)據(jù)傳輸過程 TM: UM: AM:

      (2)ARQ過程(AM)重傳: 輪詢:(防止發(fā)送端buffer溢出)

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

      狀態(tài)報告:接收側(cè)向?qū)Φ榷伟l(fā)送側(cè)反饋,那些PDU或PDU分段已經(jīng)正確接收,那些沒有。(3)SDU丟棄過程:來自PDCP的指示,若被指示的RLC SDU沒有任何分段映射到一個RLC Data PDU,AM RLC實體發(fā)送側(cè)或者發(fā)送UM RLC實體丟棄該RLC PDU(4)重建過程:由RRC請求觸發(fā),應(yīng)用于AM、UM、TM

      丟棄、重組、提交、停止、復(fù)位、初始化(5)對于未知的、意外的以及錯誤的協(xié)議數(shù)據(jù)的處理:丟棄

      6、RLC協(xié)議數(shù)據(jù)單元及格式

      (1)TMD PDU:僅有數(shù)據(jù)域組成,沒有任何RLC頭

      (2)UMD PDU:UMDPDU頭(固定部分、擴(kuò)展部分)+數(shù)據(jù)域(可對RLC SUD進(jìn)行分段、串接、重組)

      (3)AMD PDU:AMD PDU頭(固定部分、數(shù)據(jù)部分)+數(shù)據(jù)域(可對RCL SDU進(jìn)行分段、串接、重組)

      7、參數(shù)

      (1)SN:RLC PDU序號,增量為1(保證按序接收)

      (2)FI:指示在數(shù)據(jù)域的開始和最后是否飽飯RLC SDU分段(3)E:指示數(shù)據(jù)域或LI域和E域的集合(4)LI:對應(yīng)數(shù)據(jù)域長度(5)R1:保留域,置0(6)D/C:控制PDU/數(shù)據(jù)PDU(7)RFAMD PDU/AMD PDU分段

      (8)LSF:是否原始AMD PDU的最后一個分段

      (9)SO:AMD PDU分段數(shù)據(jù)域中第一個字節(jié)在原始AMD PDU數(shù)據(jù)域中的位置(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實體接收側(cè)已檢測到丟失AMD PDU(或其一部分)的SN(15)SOstart、SOend:相關(guān)SN=NACK_SN的AMD PDU的丟失部分

      8、變量

      (1)UM發(fā)送端 1)VT(US):

      給出下一個要傳送的UMD PDU的序列號。UMD PDU沒傳送一次,該變量就更新一次,其初值為0.(2)UM接收端 1)VR(US):接受者發(fā)送順序狀態(tài)變量

      被接收的下一個PDU的序列號,初始值為0。當(dāng)接收到一個PDU,其值設(shè)置為SN+1。2)VR(UR):UM接收狀態(tài)變量

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

      記錄觸發(fā)重排序計時器的UMD PDU緊接著的下一個序列號。當(dāng)重排序計時器啟動時,該變量與VR(UR)分別記錄當(dāng)前重排序計時器對應(yīng)的序列號范圍內(nèi)的上邊界和下邊界。當(dāng)該范圍內(nèi)全部接收序列空隙處的PDU都正確接收后,終止當(dāng)前重排序計時器。當(dāng)重排序計時器不存在時,該變量無意義。4)VR(UH):UM最高期望狀態(tài)變量

      記錄接收到的PDU中最高序列號緊接著的下一個序列號,作為重排序窗口的上邊界。其初始值為0。(3)AM發(fā)送端 1)VT(A):確認(rèn)狀態(tài)變量

      記錄已經(jīng)收到肯定確認(rèn)的連續(xù)PDU中最高序列號緊接著下一個序列號,座位發(fā)送窗口的下邊界。其初始值為0,只有當(dāng)RM ELC實體發(fā)送端收到序列號等于當(dāng)前VT(A)變量值的PDU的肯定確認(rèn)時,該變量才會更新(SN=VT(A))。序列號小于該變量的PDU全部經(jīng)過接收端肯定確認(rèn),表明已經(jīng)全部正確接收。2)VT(MS):最大發(fā)送狀態(tài)變量

      VT(MS)=VT(A)+AM_Window_Size,座位發(fā)送窗口的上邊界。任何序列號發(fā)出超出該變量的PDU都不允許發(fā)送。當(dāng)窗口溢出時,AM RLC實體發(fā)送端不能發(fā)送任何新產(chǎn)生的PDU。3)VT(S):發(fā)送狀態(tài)變量

      記錄下一個新產(chǎn)生的AMD PDU的序列號,初始值為0。在當(dāng)前VT(S)值被賦予一個新產(chǎn)生的AMD PDU后,該變量做+1操作。4)POLL_SN_Pollsend :發(fā)送狀態(tài)變量(4)AM接收端 1)VR(R):接收狀態(tài)變量

      記錄最新完整接收到的連續(xù)AMD PDU緊接著的下一個序列號,座位接收窗口的下邊界。該變量初始值為0,僅當(dāng)當(dāng)前R變量值對應(yīng)的PDU被正確接收后才會更新。低于該變量。2)VR(MR):最大可接收狀態(tài)變量

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

      記錄發(fā)出重排序計時器的AMD PDU緊接著的下一個序列號。當(dāng)沖排序計時器啟動時,fai變量與MS分別記錄當(dāng)前重排序計時器對應(yīng)的序列號范圍的上邊界與下邊界,當(dāng)該范圍內(nèi)全部接受序列號空隙處的PDI都正確接收后,終止當(dāng)前重排序計時器。4)VR(MS)最大狀態(tài)發(fā)送狀態(tài)變量

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

      9、常量

      (1)AM_Window_Size:發(fā)送側(cè)為VT(A)到VT(MS);接收側(cè)為VR(R)到VR(MR)(2)UM_Window_Size:可排序的SN范圍

      10、計數(shù)器

      (1)t-PollRetransmit:接收側(cè)AM RLC實體在進(jìn)行重傳輪詢時使用(2)t-Reordering:接收側(cè)AM RLC實體和UM RLC實體檢查下層傳送的RLC PDU是否丟失時使用。如果t-Reordering正在運(yùn)行,其他的t-Reordering計時器不能被啟動,在一個給定的時間內(nèi),每個RLC實體只能運(yùn)行一個t-Reordering計時器。

      (3)t-StatusProhibit:只有在使用了基于計時器的狀態(tài)發(fā)送時,使用該計時器。當(dāng)RLC實體建立時,該計時器 啟動,每次計時器超時,就發(fā)送一個狀態(tài)報告并且計時器重啟。其值由RRC告知。

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

      1、數(shù)據(jù)傳輸過程

      1.1 TM數(shù)據(jù)傳輸

      (1)發(fā)送:當(dāng)向下層發(fā)送一個新的TMD PDU時

      接收端TM RLC實體應(yīng)當(dāng)給下層發(fā)送一個沒有經(jīng)過任何處理的RLC SDU(2)接收:當(dāng)從下層接收到一個新的TMD PDU時

      發(fā)送端TM RLC實體應(yīng)當(dāng)向上層提交一個沒有經(jīng)過任何處理的TMD PDU 1.2 UM數(shù)據(jù)傳輸

      (1)發(fā)送:當(dāng)向下層發(fā)送一個新的UMD PDU時

      發(fā)送端UM RLC應(yīng)當(dāng)將該UMD PDU的SN置為VT(US),并將VT(US)加1(2)接收:

      一、概述:

      UM RLC實體接收端需要根據(jù)狀態(tài)變量VR(UH)來維護(hù)重排序窗口

      1)當(dāng)接收到的PDU SN滿足VR(UH)-UM_Window_size=SN

      SN落入重排序窗內(nèi)

      2)否則,該SN落在重排序窗口之外 當(dāng)從下層接收到UMD PUD時

      1)UM RLC實體接收端應(yīng)當(dāng)丟棄接收到的UMD PDU或?qū)⑵浯鎯υ诮邮站彺嬷?2)如果接受到UMD PDU并將其存儲在接受緩存器中

      UM RLC實體接收端應(yīng)當(dāng)更新狀態(tài)變量、重組并向上層傳送RLC SDUs,在需要的

      時候,開始或停止t-Reordering計數(shù)器。

      當(dāng)t-Reordering計數(shù)器超時

      UM RLC接受端實體應(yīng)更新狀態(tài)變量、重組并向上層傳送RLC SDUs,在需要的時候開始 t-Reordering計數(shù)器。

      二、當(dāng)從下層接受到UMD PDU時:

      當(dāng)從下層接收到一個SN=x的UMD PDU時: 如果VR(UR)

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

      UM RLC接收實體應(yīng)把這個UMD PDU存入接收緩存器中

      三、當(dāng)一個UMD PDU被存儲到接收緩存器時: 當(dāng)一個SN=x的UMD PDU唄存入接收緩存器中時:(1)如果x落在重排序窗口之外

      1)UM RLC接收實體應(yīng)更新VR(UH)為x+1

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

      3)如果VR(UR)落在重排序窗口之外:

      UM RLC接收實體應(yīng)將VR(UR)置為(VR(UH)-UM_Window_Size)(2)如果接收緩存器中有一個SN=VR(UR)的UMD PDU:

      1)UM RLC接收實體應(yīng)將VR(UR)更新為第一個沒有被接收的UMD PDU SN>當(dāng)前VR(UR)的PDU

      2)UM RLC接收實體應(yīng)從UMD PDU中重組所有SN<更新后的VR(UR)的RLC SDU,去掉RLC頭并按照RLC SN的升序方式向上層發(fā)送重組后的RLC SDU。(3)如果t-Reordering計時器正在運(yùn)行:

      1)如果VR(UX)≤VR(UR),或者

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

      UMD PDU接收實體應(yīng)停止并重啟t-Reordering計時器(4)如果t-Reordering計數(shù)器沒有運(yùn)行

      1)如果VR(UH)>VR(UR)

      UMD PDU接收實體應(yīng)啟動該t-Reordering計時器

      UMD PDU接收實體應(yīng)將VR(UX)置為VR(UH)

      四、當(dāng)t-Reordering計數(shù)器超時 當(dāng)t-Reordering計數(shù)器超時:(1)UM RLC接收實體應(yīng)更新RLC SDU為第一個沒有被接收的UMD PDU的SN(SN≥VR(UX))(2)UM RLC接收實體應(yīng)重組所有SN<更新后的VR(UR)的UMD PDU(3)如果VR(UH)>VR(UR)

      1)UM RLC接收實體應(yīng)啟動t-Reordering計數(shù)器

      2)UM RLC接收實體應(yīng)將VR(UX)置為VR(UH)1.3 AM數(shù)據(jù)傳輸(1)發(fā)送:

      1)AM RLC實體接收端應(yīng)比RLC數(shù)據(jù)PDU優(yōu)先發(fā)送RLC控制PDU;

      2)AM RLC實體接收端應(yīng)比新的AMD PDU優(yōu)先發(fā)送重傳的RLC數(shù)據(jù)PDU; 3)發(fā)送端AM RLC實體應(yīng)根據(jù)狀態(tài)變量VT(A)和VT(MS)維護(hù)發(fā)送窗口:

      如果VT(A)≤SN<VT(MS),則SN落入發(fā)送窗口之內(nèi)

      否則,SN落在發(fā)送窗口之外

      4)發(fā)送端SM RLC實體不應(yīng)將任何SN落在傳送窗口之外的RLC數(shù)據(jù)PDU傳送給下層

      5)當(dāng)傳送一個新的AMD PDU給下層時,發(fā)送端AM RLC實體應(yīng)將該AMD PDU的SN置為VT(S),并將VT(S)加1;

      6)AM RLC實體接收端可以通過如下方式接收一個RLC數(shù)據(jù)PDU的確認(rèn):

      AM RCL實體的發(fā)送端可以通過每個AM RLC實體的STATUS PDU來確認(rèn) 7)當(dāng)接收到一個SN=VT(A)的AMD PDU的確認(rèn)時:

      a.接收端AM RLC 實體應(yīng)將VT(A)置為還沒有被確認(rèn)的最小SN的AMD PDU的SN值,且該SN滿足VT(A)≤SN≤VT(S)

      b.如果屬于同一個RLC SDU的PDU都收到了確認(rèn),則AM RLC實體接收端應(yīng)向上層發(fā)送RLC SDU成功發(fā)送的通知

      (2)接收:

      一、概述

      (1)AM RLC實體接收端應(yīng)根據(jù)狀態(tài)變量VR(R)和VR(MR)維護(hù)接收窗口:

      1)如果VR(R)≤SN<VR(MR),則SN落入接收窗口之內(nèi)

      2)否則,SN落在接收窗口之外

      (2)當(dāng)從下層接收到一個RLC數(shù)據(jù)PDU時:

      1)AM RLC實體接收端或者丟棄該接收到的RLC數(shù)據(jù)PDU,或者將其存入接收緩存器

      2)如果接收到的RLC數(shù)據(jù)PDU被存入接收緩存器:

      AM RLC實體接收端應(yīng)更新狀態(tài)變量、重組并向上層傳送RLC SDU,且在需要的時候啟動或停止t-Reordering計數(shù)器

      3)當(dāng)t-Reordering計數(shù)器超時,AM RLC實體接收端應(yīng)更新狀態(tài)變量,并在需要的時候啟動t-Reordering計數(shù)器

      二、當(dāng)從下層接收到RLC數(shù)據(jù)PDU時:

      當(dāng)從下層接收到一個RLC數(shù)據(jù)PDU時,當(dāng)它包含SN=x的AMD PDU分段字節(jié)為y到z時(1)如果x落在接收窗口之外,或者

      (2)SN=x的AMD PDU的分段字節(jié)為y到z已經(jīng)被接收時:

      AM RLC實體接收端應(yīng)丟棄該RLC數(shù)據(jù)PDU(3)否則:

      1)接收AM RLC實體應(yīng)將接收到的RLC數(shù)據(jù)PDU存入接收緩存器中

      2)如果AMD PDU的有些字節(jié)分段包含之前已經(jīng)接收到的RLC數(shù)據(jù)PDU:

      AM RLC實體接收端應(yīng)丟棄該重復(fù)的字節(jié)段

      三、當(dāng)已給RLC數(shù)據(jù)PDU被存入接收緩存器中時: 當(dāng)一個SN=x的RLC數(shù)據(jù)PDU被存入接收緩存器中時:(1)如果x≥VR(H)

      接收AM RLC實體應(yīng)更新VR(H)為x+1(2)如果SN=VR(MS)的AMD PDU的字節(jié)段已經(jīng)接收:

      接收AM RLC實體應(yīng)更新VR(MS)為第一個不是所有字節(jié)段都被接收的AMD PDU的SN,且該SN大于當(dāng)前VR(MS)

      (3)如果x=VR(R):

      1)如果AMD PDU的所有SN=VR(R)的字節(jié)段都被接收:

      a.接收AM RLC實體應(yīng)更新VR(R)為第一個不是所有字節(jié)段都被接收的AMD PDU的SN,且該SN大于當(dāng)前VR(R)

      b.接收AM RLC實體應(yīng)更新VR(MR)為已更新的VR(R)+AM_Window_Size 2)從所有SN落在接收窗口之外的AMD PDU以及的字節(jié)段中重組RLC SDU,如果之前

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

      (4)如果t-Reordering計數(shù)器正在運(yùn)行:

      1)如果VR(X)=VR(R);或者

      2)如果VR(X)落在接收窗口之外,且VR(X)≠VR(MR)

      接收AM RLC實體應(yīng)停止并重置t-Reordering計數(shù)器

      (5)如果t-Reordering計數(shù)器沒有運(yùn)行(包含因上述過程而停止的情況):

      1)如果VR(H)>VR(R)

      a.接收AM RLC實體應(yīng)啟動t-Reordering計數(shù)器

      b.接收AM RLC實體應(yīng)置VR(X)為VR(H)

      四、當(dāng)t-Reordering計數(shù)器超時: 當(dāng)t-Reordering計數(shù)器超時:

      (1)接收AM RLC實體應(yīng)更新VR(MS)為第一個不是所有字節(jié)段都被接收的AMD PDU的SN,且該SN≥VR(X)

      (2)如果VR(H)>VR(MS):

      1)接收AM RLC實體應(yīng)啟動t-Reordering計數(shù)器

      2)接收AM RLC實體應(yīng)置VR(X)為VR(H)

      2、ARQ過程(ARQ過程只在AM RLC實體執(zhí)行)2.1 重傳(1)AM RLC實體接收端可以通過如下方式收到AMD PDU或AMD PDU部分的確認(rèn)(其對等端AM RLC實體通知接收失?。?/p>

      由對等端的AM RLC實體發(fā)送的STATUS PDU(2)當(dāng)接收到從對等端AM RLC實體發(fā)送的STATUS PDU所獲取的AMD PDU或AMD PDU部分的否認(rèn):

      1)如果對應(yīng)的AMD PDU的SN落入VT(A)≤SN<VT(S)的范圍內(nèi):

      則認(rèn)為這個AMD PDU或AMD PDU的一部分要求重傳

      (3)當(dāng)一個AMD PDU或AMD PDU的部分被認(rèn)為需要重傳時:

      1)如果該AMD PDU被認(rèn)為是第一次重傳

      接收AM RLC實體應(yīng)將與該AMD PDU關(guān)聯(lián)的RETX_COUNT置0 2)否則,如果它或者它的一部分重傳沒有被掛起:

      接收AM RLC實體應(yīng)遞增RETX_COUNT 3)如果RETX_COUNT=maxRetxThreshold:

      接收AM RLC實體應(yīng)通知上層已經(jīng)達(dá)到最大重傳次數(shù)(4)當(dāng)重傳一個AMD PDU時

      1)如果該AMD PDU的大小能夠完全容納在由下層指示的RLC PDU重傳機(jī)會中:

      接收AM RLC實體應(yīng)傳輸這個AMD PDU(除了P域)2)否則:

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

      (5)當(dāng)傳輸一個AMD PDU的一部分時:

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

      (6)當(dāng)形成一個新的AMD PDU片段時

      1)只要把原來的AMD PDU數(shù)據(jù)字段映射到新的AMD PDU分段的數(shù)據(jù)部分

      2)設(shè)置新的AMD PDU分段包頭

      3)設(shè)置P域 2.2 輪詢

      一個AM RLC實體可以輪詢它的對等端實體來觸發(fā)對等端的發(fā)送狀態(tài)報告

      一、發(fā)送一個AMD PDU或AMD PDU分段(1)當(dāng)產(chǎn)生一個新的AMD PDU時

      1)AM RLC實體接收端應(yīng)對PDU_WITHOUT_POLL加1

      2)對于每一個映射到RLC數(shù)據(jù)PDU數(shù)據(jù)域的新數(shù)據(jù)單元,AM RLC實體接收端應(yīng)將BYTE_WITHOUT_POLL增加相應(yīng)的字節(jié)數(shù)

      3)如果PDU_WITHOUT_POLL≥pollPDU;或者

      4)如果BYTE_WITHOUT_POLL≥pollBYTE

      AM RLC實體發(fā)送端應(yīng)按照如下所述在RLC數(shù)據(jù)PDU中包含一個POLL(2)當(dāng)組成一個AMD PDU或者AMD PDU分段時

      1)如果在傳送了RLC數(shù)據(jù)PDU之后,發(fā)送緩存器和接收緩存器同時為空(不包括還沒有被確認(rèn)的RLC數(shù)據(jù)PDU);或者

      2)如果在傳送了RLC數(shù)據(jù)PDU之后沒有新的RLC數(shù)據(jù)PDU需要被傳送

      AM RLC發(fā)送實體應(yīng)按照如下所述在RLC數(shù)據(jù)PDU中包含一個POLL(3)要在RLC數(shù)據(jù)PDU中包含一個POLL

      1)AM RLC實體發(fā)送端應(yīng)設(shè)置RLC數(shù)據(jù)PDU的P域為1

      2)AM RLC實體發(fā)送端應(yīng)設(shè)置PDU_WITHOUT_POLL為0

      3)AM RLC試題發(fā)送端應(yīng)設(shè)置BYTE_WITHOUT_POLL為0(4)在根據(jù)需要輕狂對VT(S)進(jìn)行增值后,當(dāng)向下層發(fā)送一個含poll的RLC數(shù)據(jù)PDU時

      1)AM RLC實體發(fā)送端應(yīng)設(shè)置POLL_SN為VT(S)-1

      2)如果t-PollRetransmit沒有運(yùn)行

      AM RLC實體發(fā)送端應(yīng)啟動t-PollRetransmit計數(shù)器

      3)否則

      AM RLC實體發(fā)送端應(yīng)重啟t-Pollretransmit計數(shù)器

      二、接收一個STATUS報告

      當(dāng)從接收端RLC AM實體接收到一個STATUS報告時

      (1)如果狀態(tài)報告包含的RLC數(shù)據(jù)PDU的確認(rèn)或否認(rèn)序號等于POLL_SN

      1)如果t-Pollretransmit計數(shù)器正在運(yùn)行

      AM RLC實體接收端應(yīng)停止并重置t-Pollretransmit計數(shù)器

      三、t-Pollretransmit計數(shù)器超時

      (1)如果發(fā)送緩存器和接收緩存器同時為空(不包括還沒有被確認(rèn)的RLC數(shù)據(jù)PDU);或者(2)如果沒有新的RLC數(shù)據(jù)PDU能夠傳輸(如,窗口溢出)、1)AM RLC實體發(fā)送端認(rèn)為SN=VT(S)-1的AMD PDU需要重傳;或者

      2)AMRLC實體發(fā)送端認(rèn)為沒有被確認(rèn)的AMD PDU需要重傳(3)AM RLC實體發(fā)送端在RLC數(shù)據(jù)PDU中包含一個poll 2.3 狀態(tài)報告

      (1)AM RLC實體向它的對等端AM RLC實體發(fā)送STATUS來提供RLC PDU的確認(rèn)或否認(rèn)(2)RRC層可以配置RLC是否啟動狀態(tài)報告禁止功能(3)初始化STATUS報告觸發(fā)包括:

      1)從對等端AM RLC實體發(fā)起的輪詢

      當(dāng)從下層接收到一個SN=x且P域被置為1的RLC數(shù)據(jù)PDU時

      a.如果該P(yáng)DU要被丟棄;或者

      b.如果x<VR(MS)或x≥VR(MR)

      觸發(fā)STATUS報告 c.否則

      延遲觸發(fā)STATUS直到x<VR(MS)

      (基于此可以確保RLC狀態(tài)報告是在HARQ重排序之后發(fā)送)2)檢測到一個RLC數(shù)據(jù)PDU接收失敗

      AM RLC實體接收端應(yīng)在t-Reordering計數(shù)器超時時觸發(fā)一次STATUS報告

      (t-Reordering計數(shù)器的超同時觸發(fā)了VR(MS)的更新和STATUS報告的觸發(fā)。但STATUS報告的觸發(fā)應(yīng)該在VR(MS)更新觸發(fā)之后)(2)當(dāng)STATUS報告被觸發(fā):

      1)如果t-StatusProhibit計數(shù)器沒有運(yùn)行

      在下層指示的第一次重傳機(jī)會中,構(gòu)建一個STATUS PDU并將其傳給下層

      2)否則

      在t-StatusProhibit計數(shù)器超時后,在下層指示的第一次重傳機(jī)會中,構(gòu)建一個STATUS PDU即使在t-StatusProhibit計數(shù)器運(yùn)行時已經(jīng)觸發(fā)過很多次,并將此傳送給下層

      (3)當(dāng)一個STATUS PDU被傳送給下層時

      1)AM RLC實體接收端應(yīng)啟動t-StatusProhibit計數(shù)器(4)當(dāng)構(gòu)建一個STATUS PDU時

      1)對于滿足VR(R)≤SN<VR(MS)的還沒有被完全接收到的AMD PDU,按照SN的升序和PDU字節(jié)段升序的方式,從SN=VR(R)開始知道這個STATUS PDU的大小已經(jīng)達(dá)到下層只是發(fā)送機(jī)會的大小為止。

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

      AM RLC實體接收端應(yīng)在STATUS PDU中包含一個NACK_SN,并將其設(shè)為該AMD PDU的SN值

      b.對于一個部分接收到的AMD PDU,它的一個還沒有被接收到的連續(xù)的字節(jié)分段

      AM RLC實體接收端應(yīng)在STATUS PDU中包含NACK_SN、SOstart及SOend

      2)將ACK_SN設(shè)為下一個沒有被接收到的RLC數(shù)據(jù)PDU的SN,且其在STATUS PDU中

      并不是丟失狀態(tài)

      3、SDU丟棄過程

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

      4、重建過程

      RLC重建是在RRC層的請求下執(zhí)行,這個功能為AM、UM和TM RLC實體均適用(1)當(dāng)RRC層指示一個RLC實體需要一次重建時

      1)如果該實體為TM RLC發(fā)送實體

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

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

      b.丟棄所有剩余的RLC SDU

      3)如果該實體為UM RLC發(fā)送實體

      丟棄所有的RLC SDU

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

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

      b.丟棄接收側(cè)剩余的AMD PDU和AMD PDU字節(jié)分段

      c.丟棄發(fā)送側(cè)所有的RLC SDU和AMD PDU

      d.丟棄所有的RLC控制PDU

      5)RLC實體應(yīng)停止并重置所有計數(shù)器

      6)RLC實體應(yīng)重置所有狀態(tài)變量為初始值

      5、對未知的、意外的以及錯誤的協(xié)議數(shù)據(jù)的處理

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

      RLC實體應(yīng)丟棄該接收到的PDU

      零碎:(不在總結(jié)的整體結(jié)構(gòu)之中但覺得應(yīng)該對以后也有用的零散東西)

      1、UM 傳輸解析

      已提交的PDU

      重排序窗口

      還未接收 到PDU

      丟失的PDU

      丟失的PDU

      VR(UH)-UM_window_size

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

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

      已丟失PDU

      已提交的PDU

      還未收到的PDU

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

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

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

      2、AM傳輸解析

      已經(jīng)收到的肯

      VT(A)下一個將收到 確認(rèn)的PDU序列號

      已提交PDU后 請求重傳的PDU

      VT(S)下一個將傳輸?shù)腜DU序列號

      VT(MS)=VT(A)+ AM_Window_Size 定確認(rèn)的PDU

      發(fā)送窗口

      AM RLC實體發(fā)送端優(yōu)先發(fā)送重傳的RLC PDU,AM RLC實體發(fā)送端維護(hù)狀態(tài)變量VT(S),含義為分配給下一個新生成的RLC PDU的序列號數(shù)值。該變量初始值為零,當(dāng)生成一個新的 AMD PDU 時,將該變量作為該P(yáng)DU的序列號,然后將該變量的數(shù)值加一。

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

      AM RLC實體發(fā)送端根據(jù)對端發(fā)來的狀態(tài)PDU中包含的肯定確認(rèn)來更新發(fā)送窗口變量,發(fā)送窗口的下邊界總是更新為當(dāng)前發(fā)送窗口內(nèi)的最小需要收到肯定確認(rèn)的PDU的序列號。

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

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

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

      ARQ過程

      AMRLC實體發(fā)送端收到接收端的STATUS PDU有關(guān)AMD PDU或AMD PDU分段的否定確VR(R)

      下一個完整接收的連續(xù)PDU的序列號

      VR(MS)經(jīng)過重排序檢測的PDU序列號上邊界

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

      接收窗口

      重排序以及狀態(tài)報告操作的時間窗

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

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

      POLLING過程

      Polling實現(xiàn)的方式為將RLC PDU中的P域(輪詢比特)置為1,發(fā)送攜帶Polling的RLC PDU后,記錄當(dāng)前已經(jīng)發(fā)送的PDU中最高的序列號為Polling序列號,并啟動或重啟動Polling重傳計數(shù)器。

      當(dāng)收到記錄的Polling序列號相關(guān)的肯定火否定確認(rèn)后,停止并復(fù)位輪詢重傳計數(shù)器,此次輪詢過程結(jié)束。

      當(dāng)Polling計數(shù)器超時,則發(fā)起一次新的Polling過程。如果此時發(fā)送緩存和重傳緩存均為空或者沒有新的RLC PDU傳輸,則將當(dāng)前已經(jīng)傳輸過的序列號最高的AMD PDU或者任意沒有收到肯定確認(rèn)的AMD PDU進(jìn)行重傳,用以攜帶Polling比特。

      3、狀態(tài)報告解析

      AMD RLC 實體向?qū)Φ榷税l(fā)送狀態(tài)報告,用以告知其 RLC PDU 的是否成功接收。觸發(fā)狀態(tài)報告的條件包括:

      (1)接收到來自 AM RLC 實體對等端的探詢;

      (2)檢測到 RLC PDU 的接收失敗。

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

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

      4、三種實體比較:

      (1)對于TM/UM,各有一個發(fā)送與接收實體(2)AM接收發(fā)送同屬于一個實體

      由于AM支持ARQ,發(fā)送端需要接收端提供確認(rèn)信息來決定是否需要重傳,因此AM接收發(fā)送同屬于一個實體

      5、RLC PDU:

      (1)RLC數(shù)據(jù)PDU:

      1)TMD PDU:因為透明傳輸,所以不需要做任何處理直接透傳到MAC

      2)UMD PDU:

      3)AMD PDU:第一次發(fā)送的RLC SDU的一部分生成的PDU,或者在重傳的時候不需要分段的PDU

      4)AMD PDU segment:重傳的PDU需要分段,從而產(chǎn)生(2)RLC控制PDU:(3)STATUS PDU:

      格式的選取取決于:

      (1)對分段的支持(2)上層所使用的業(yè)務(wù)(3)針對AM實體的重傳機(jī)制的支持

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

      下載PDCP協(xié)議學(xué)習(xí)總結(jié)(合集五篇)word格式文檔
      下載PDCP協(xié)議學(xué)習(xí)總結(jié)(合集五篇).doc
      將本文檔下載到自己電腦,方便修改和收藏,請勿使用迅雷等下載。
      點(diǎn)此處下載文檔

      文檔為doc格式


      聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)自行上傳,本網(wǎng)站不擁有所有權(quán),未作人工編輯處理,也不承擔(dān)相關(guān)法律責(zé)任。如果您發(fā)現(xiàn)有涉嫌版權(quán)的內(nèi)容,歡迎發(fā)送郵件至:645879355@qq.com 進(jìn)行舉報,并提供相關(guān)證據(jù),工作人員會在5個工作日內(nèi)聯(lián)系你,一經(jīng)查實,本站將立刻刪除涉嫌侵權(quán)內(nèi)容。

      相關(guān)范文推薦

        常見接口協(xié)議學(xué)習(xí)筆記總結(jié)

        SPI通信 SPI簡介:(高速,全雙工,4線同步串行總線) SCK:主機(jī)輸出的用來同步數(shù)據(jù)傳輸?shù)拇袝r鐘;MOSI:主機(jī)輸出從機(jī)輸入;MISO主機(jī)輸入從機(jī)輸出;NSS:由主機(jī)輸出的片選使能低電平有效 SPI例......

        英語學(xué)習(xí)協(xié)議

        英語協(xié)議書 甲方: 乙方:學(xué)生及其代理人 為了實現(xiàn)我們的承諾,保證教學(xué)任務(wù)徹底完成,經(jīng)雙方協(xié)商,甲乙雙方簽定培訓(xùn)協(xié)議書,雙方必須嚴(yán)格按照協(xié)議書的內(nèi)容履行自己的責(zé)職。 一、甲方的......

        醫(yī)保協(xié)議學(xué)習(xí)2014

        臨汾市城鎮(zhèn)醫(yī)療保險、生育保險 2014年度定點(diǎn)醫(yī)院服務(wù)協(xié)議學(xué)習(xí)第二部分 醫(yī)療服務(wù)管理 第十一條 乙方應(yīng)堅持“以病人為中心”的服務(wù)準(zhǔn)則,嚴(yán)格執(zhí)行首診醫(yī)師負(fù)責(zé)制和因病施治的......

        外出學(xué)習(xí)協(xié)議

        外出學(xué)習(xí)協(xié)議我是美術(shù)特長生,高三第一學(xué)期末要進(jìn)行專業(yè)考試。為了提高專業(yè)成績,我自愿在校外培訓(xùn)班學(xué)習(xí)美術(shù)專業(yè),由此而產(chǎn)生的一切經(jīng)濟(jì)和安全問題,由我家長和我本人負(fù)責(zé)。學(xué)習(xí)時......

        計算機(jī)網(wǎng)絡(luò)協(xié)議總結(jié)

        1. 物理層(比特流) 2. 數(shù)據(jù)鏈路層(幀) PPP(點(diǎn)對點(diǎn)協(xié)議):面向連接,不可靠,只支持全雙工鏈路,成幀技術(shù),PPP 幀是面向字節(jié)的,所有的PPP幀的長度都是整數(shù)字節(jié)的。 只檢錯不糾錯,沒有流量控......

        三方協(xié)議總結(jié)

        三方協(xié)議是《全國普通高等學(xué)校畢業(yè)生就業(yè)協(xié)議書》的簡稱,它是明確畢業(yè)生、用人單位、學(xué)校三方在畢業(yè)生就業(yè)工作中的權(quán)利和義務(wù)的書面表現(xiàn)形式,能解決應(yīng)屆畢業(yè)生戶籍、檔案、保......

        HTTP協(xié)議學(xué)習(xí)心得體會

        HTTP協(xié)議學(xué)習(xí)心得體會 HTTP (HyperText Transfer Protocol) ==================================== 是TCP/IP協(xié)議集中的一個應(yīng)用層協(xié)議,用于定義瀏覽器和Web服務(wù)器之間交換數(shù)......

        輔導(dǎo)班學(xué)習(xí)安全協(xié)議(精選合集)

        奧林匹克花園輔導(dǎo)班學(xué)習(xí)安全協(xié)議為保障學(xué)生學(xué)習(xí)期間的安全,我們就相關(guān)問題做如下說明: 一. 學(xué)生在學(xué)習(xí)期間,我們將會對孩子進(jìn)行安全教育和思想動員,在上放學(xué)路上,請學(xué)生自覺遵守交......