第一篇：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ù)量將遠超人類的數(shù)量。在這種大背景下，物聯(lián)網(wǎng)和 M2M技術(shù)應(yīng)運而生。雖然對人而言，連接入互聯(lián)網(wǎng)顯得方便容易，但是對于那些微型設(shè)備而言接入互聯(lián)網(wǎng)非常困難。在當前由PC機組成的世界，信息交換是通過 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é)議，它運行于UDP協(xié)議之上而不是像HTTP那樣運行于TCP之上。CoAP協(xié)議非常的小巧，最小的數(shù)據(jù)包僅為4字節(jié)。

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

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

事務(wù)層(Transaction layer)用于處理節(jié)點之間的信息交換，同時提供組播和擁塞控制等功能。請求／響應(yīng)層(Request／Responselayer)用于傳輸對資源進行操作的請求和響應(yīng)信息。CoAP協(xié)議的REST構(gòu)架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒有采用TCP協(xié)議，也可以提供可靠的傳輸 機制。利用默認的定時器和指數(shù)增長的重傳間隔時間實現(xiàn)CON(Confirmable)消息的重傳，直到接收方發(fā)出確認消息。另外，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é)點作為客戶端向服務(wù)器發(fā)送一個或多個請求，服務(wù)器端回復(fù)客戶端的CoAP請求。不同于 HTTP，CoAP的請求和響應(yīng)在發(fā)送之前不需要事先建立連接，而是通過CoAP信息來進行異步信息交換。CoAP協(xié)議使用UDP進行傳輸。這是通過信息層選項的可靠性來實現(xiàn)的。CoAP采用和HTTP協(xié)議相同的請求響應(yīng)工作模式。CoAP協(xié)議共有4中不同的消息類型。

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

RST——復(fù)位消息，當接收者接受到的消息包含一個錯誤，接受者解析消息或者不再關(guān)心發(fā)送者發(fā)送的內(nèi)容，那么復(fù)位消息將會被發(fā)送。雖然CoAP協(xié)議目前還在制定當中，但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é)點上的實時數(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é)點上的實時數(shù) 據(jù)，還能查看歷史數(shù)據(jù)，以便于分析問題。

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

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

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

【消息ID Message ID】：每個CoAP消息都有一個ID，在一次會話中ID總是保持不變。但是在這個會話之后該ID會被回收利用?！緲擞?Token】：標記是ID的另一種表現(xiàn)、【選項 Options】：CoAP選項類似于HTTP請求頭，它包括CoAP消息本身，例如CoAP端口號，CoAP主機和CoAP查詢字符串等?！矩撦dPayload】：真正有用的被交互的數(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的默認UDP端口號為5683。

6、CoAP觀察模式

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

7、CoAP塊傳輸

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

8、CoAP協(xié)議的特點：

（1）報頭壓縮：CoAP包含一個緊湊的二進制報頭和擴展報頭。它只有短短的4 B的基本報頭，基本報頭后面跟擴展選項。一個典型的請求報頭為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)的主要特點。(3)傳輸層使用UDP協(xié)議：CoAP協(xié)議是建立在UDP協(xié)議之上，以減少開銷和支持組播功能。它也支持一個簡單的停止和等待的可靠性傳輸機制。

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

(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)訂閱機制：CoAP使用異步通信方式，用訂閱機制實現(xiàn)從服務(wù)器到客戶端的消息推送。實現(xiàn)CoAP的發(fā)布，訂閱機制，它是請求成功后自動注冊的 一種資源后處理程序。是由默認的EVENT_和PERIODIC_RESOURCEs來進行配置的。它們的事件和輪詢處理程序用 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é)點組成。用戶瀏覽器通過HTTP協(xié)議訪問Web服務(wù)器，MX231CC節(jié)點通 過CoAP協(xié)議和IPv6智能網(wǎng)關(guān)進行通信，從而實現(xiàn)用戶瀏覽器訪問節(jié)點上資源的功能。圖9中實線表示有線連接，虛線表示無線連接。

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

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

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

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

所以在瀏覽器地址欄輸入：coap://［2001：2：：11：22ff：fe33：4499］：61616/toggle，作用是讓節(jié)點上的三色LED燈進行反轉(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é)點上的傳感器資源。

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)問題，更加具有實用性。

第二篇：外文翻譯Lithe物聯(lián)網(wǎng)中的輕量級安全CoAP協(xié)議

Lithe:物聯(lián)網(wǎng)中的輕量級安全CoAP協(xié)議

摘要：物聯(lián)網(wǎng)支持廣泛的包含潛在驅(qū)動和傳感任務(wù)的應(yīng)用場景，例如，在電子健康領(lǐng)域。為了在應(yīng)用層通信，資源受限的設(shè)備要能夠使用資源受限的應(yīng)用協(xié)議（CoAP），目前互聯(lián)網(wǎng)工程組正在使這項協(xié)議標準化。為了保護感知信息的傳送，安全的資源受限協(xié)議授權(quán)使用數(shù)據(jù)報傳輸層安全協(xié)議（DTLS）作為底層安全協(xié)議來進行身份認證和保密通信。然而，數(shù)據(jù)包傳輸層安全協(xié)議最初是用在比較強大的設(shè)備上的，這些設(shè)備通過可靠的高帶寬的鏈路來進行通信。在這篇論文中我們提出了Lithe——物聯(lián)網(wǎng)中數(shù)據(jù)報傳輸層安全協(xié)議和資源受限的應(yīng)用協(xié)議的集成協(xié)議。通過Lithe，另外我們利用低功率無線個人區(qū)域網(wǎng)絡(luò)IPV6協(xié)議（6 LoWPAN），提出了一個新穎的DTLS頭壓縮計劃，旨在顯著降低能源消耗。最重要的是我們提出的DTLS頭壓縮方案不威協(xié)DTLS提供的端到端的安全屬性。同時，它在保持DTLS標準性的情況下，大大降低了傳播的數(shù)量字節(jié)。我們在Contiki操作系統(tǒng)下基于DTLS來評估了我們的方法。評估結(jié)果表明該方案在包的大小，能量消耗，處理時間方面有了顯著改善，而且能夠在壓縮DTLS時得到全網(wǎng)響應(yīng)。

索引詞：CoAP，DTLS，CoAPs，6LoWPAN，security，IoT

一、簡介

低功率無線個人區(qū)域網(wǎng)絡(luò)IPV6協(xié)議（6 LowPAN）允許使用低功耗的IP網(wǎng)絡(luò)和有損耗的無線傳感器網(wǎng)絡(luò)，例如無線傳感網(wǎng)（WSNs）。這樣的IP連接的智能設(shè)備正成為互聯(lián)網(wǎng)的一部分，因此形成了物聯(lián)網(wǎng)或者嚴格來說形成了IP連接的物聯(lián)網(wǎng)。然而由于TCP的擁塞控制算法，使得它在無線網(wǎng)絡(luò)中的性能很差，低功率無線電和傳感網(wǎng)絡(luò)中的損耗進一步惡化了它的性能。因此物聯(lián)網(wǎng)中主要使用無連接的UDP。此外。HTTP主要是在TCP基礎(chǔ)上運行，它在損耗和受限環(huán)境下效率低下。IETF工作在無連接的輕量級的CoAP上，CoAP是物聯(lián)網(wǎng)中新提出的協(xié)議。它是為了滿足特定需求，如在資源受限下支持簡單，低開銷，多播傳輸。當物體連接到不可信的網(wǎng)絡(luò)時，安全就尤其重要了。例如，醫(yī)療監(jiān)測代表一個典型的對安全敏感的應(yīng)用場景。這里，一種智能裝置，例如，如胰島素，可能被附加到病人的身體并向后端服務(wù)互聯(lián)網(wǎng)定期報告病人的情況。在緊急情況下，醫(yī)生還可以向病人的身體即時注射治療藥物。

為了實現(xiàn)自動鍵管理、數(shù)據(jù)加密、完整性保護和身份驗證，CoAP提出使用數(shù)據(jù)報傳輸層安全(DTLS)作為安全協(xié)議。DPLS支持的CoAP被稱為安全CoAP（CoAPs）。DTLS是一個健壯的協(xié)議，它需要大量的信息交流來建立一個安全的會話。雖然DTLS支持多種對等認證的加密原語和負載保護，但它最初用于長度不是一個關(guān)鍵因素的網(wǎng)絡(luò)場景。因此，它限制物聯(lián)網(wǎng)設(shè)備，使用DTLS協(xié)議就會很低效。為應(yīng)對資源約束和基于網(wǎng)絡(luò)的IEEE 802.15.4的大小限制，定義了6 LoWPAN頭壓縮機制。6 LoWPAN標準已經(jīng)定義了IP報頭的標題壓縮格式，IP擴展報頭和UDP報頭。我們相信把6 LoWPAN報頭壓縮機制應(yīng)用于壓縮其他有明確的頭字段的協(xié)議非常有益。

在這篇文章中我們通過用6 LoWPAN報頭壓縮機制來壓縮底層DTLS協(xié)議并提出了輕量級 CoAPs。我們命名輕量級6 LoWPAN為壓縮的CoAPs Lithe。DTLS頭的目的是雙重壓縮。

首先，由于通信比計算需要更多的能量，所以可以通過減少消息大小來提高能源效率。第二，當數(shù)據(jù)報大小大于鏈路層MTU時，避免應(yīng)用6 LoWPAN碎片。從安全角度來看，由于6 LoWPAN禁不住碎片攻擊，所以只要有可能，避免碎片是非常重要的。壓縮的DTLS保證了Lithe中的6 LoWPAN主機和典型的應(yīng)用未壓縮的CoAPs網(wǎng)絡(luò)主機之間的端到端安全。圖1顯示了一個典型的物聯(lián)網(wǎng)設(shè)備，包含了應(yīng)用CoAPs的節(jié)點的6 LoWPAN網(wǎng)絡(luò)通過6LowPAN邊界路由器(6BR)與互聯(lián)網(wǎng)連接。

據(jù)我們所知，我們是第一個提出用6LowPAN機制壓縮DTLS并使輕量級CoAPs應(yīng)用于物聯(lián)網(wǎng)的。我們在Contiki操作系統(tǒng)中實現(xiàn)了DTLS頭壓縮機制。這篇論文的主要貢獻有：

為了增加DTLS的適用性，我們提出了新穎的標準的DTLS壓縮機制，在此基礎(chǔ)上可以將CoAPs應(yīng)用于受限的設(shè)備。

我們在一個應(yīng)用于物聯(lián)網(wǎng)的操作系統(tǒng)上實現(xiàn)壓縮的DTLS并且在硬件上進行了評估。結(jié)果定量的表明，與未壓縮的CoAP/DTLS相比，Lithe在很多方面都很高效。

文章的余下部分是這樣安排的。我們首先在第二章總結(jié)了相關(guān)工作。第三章對所用到的技術(shù)做了簡要的概述。第四章，我們介紹了DTLS頭壓縮機制。第五章，我們給出了實現(xiàn)。第六章，論述了網(wǎng)絡(luò)設(shè)置并討論評估結(jié)果。最后在第七章做出總結(jié)。

二、相關(guān)工作

在傳統(tǒng)互聯(lián)網(wǎng)中提供端到端的安全通信是一個廣泛的研究領(lǐng)域。然而，相對來說，在端到端安全研究中很少考慮到了6LoWPANs。設(shè)備的資源約束和無線鏈接的自然損耗是阻礙把端到端安全應(yīng)用到6LoWPANs的主要原因。最近，有組織在分析基于IP的物聯(lián)網(wǎng)的安全性挑戰(zhàn)，為滿足資源有限的設(shè)備的需求，該組織還提出了改善或修改標準IP安全協(xié)議的方案。在相關(guān)工作的討論中，我們專注于旨在實現(xiàn)物聯(lián)網(wǎng)端到端安全的方案。

先前，我們提出了一個頭壓縮方法，它通過用IPsec來保證6LowPAN中的節(jié)點與因特網(wǎng)中的主機之間的通信安全。我們定義下一個頭壓縮(NHC)編碼來壓縮認證頭(AH)和封裝安全有效載荷(ESP)的擴展報頭。Jorge擴展了我們的解決方案，其中包括IPsec隧道模式。他們在微型操作系統(tǒng)上實施和評估了他們的建議。IPsec安全服務(wù)在特定的機器上運行的所有應(yīng)用程序之間共享。盡管我們用

6LowPAN壓縮的IPsec可以用來在網(wǎng)絡(luò)層提供輕量級的E2E安全，但它最初不是為像HTTP和CoAP這樣的網(wǎng)絡(luò)協(xié)議設(shè)計的。TLS或DTLS web協(xié)議是常見的安全解決方案。TLS運行在TCP上，而在UDP基礎(chǔ)上

6LowPAN網(wǎng)絡(luò)優(yōu)先。

Brachmann提出了TLS-DTLS映射來保障物聯(lián)網(wǎng)安全。然而，這需要有可靠的6BR和在6BR間歇時的端到端安全。Kothmayr調(diào)查了在可信平臺模塊上用DTLS來獲得對RSA算法的硬件支持。然而，他們利用了DTLS，而沒有用任何壓縮方法，這會造成DTLS消息中的冗余位縮短整個網(wǎng)絡(luò)的生命周期。Granjal評估了帶有CoAP的DTLS在安全通信中的性能。他們注意到稀缺性負載空間在需要更大的有效載荷的應(yīng)用程序中會有問題。作為一種替代方法，他們建議在其他層使用像IPsec這樣的壓縮形式來保證安全。在最近的研究中，Keoh 討論了保護以IP連接并使用DTLS協(xié)議的物聯(lián)網(wǎng)的安全的意義，并提出了一個安全的網(wǎng)絡(luò)架構(gòu)，用延長的DTLS對單播和多播密鑰進行訪問和管理。

上述解決方案要么對物聯(lián)網(wǎng)中的TLS或DTLS的使用進行了評估，要么對破壞端到端安全的當前架構(gòu)進行評估。本文通過使用6LowPAN頭壓縮機制來減少物聯(lián)網(wǎng)中DTLS的開銷。

我們提出了設(shè)計思想以減少雙向的基于證書的DTLS握手的能源消費。我們提出的建議如下：

1、預(yù)先驗證可靠的6BR中的證書。

2、全面恢復(fù)會話以避免重新握手。

3、資源有限的設(shè)備的所有者來承擔(dān)握手任務(wù)。在物聯(lián)網(wǎng)中驗證基于證書的可行性的工作與這一工作是互補的。為使基于證書的相互握手更高效，我們計劃把DTLS報頭壓縮與這些想法集合起來。最近，類似于NHC的通用頭壓縮（GHC）也被定義成可以允許上層頭壓縮。6LowPANGHC對于所有的頭和類似于頭的結(jié)構(gòu)是一個通用的壓縮方案，但是一個低效的方法。它是我們的解決方案的替代方法，在將來的工作中，我們計劃把我們的6LowPAN-NHC與6LowPAN-GHC做一個比較。

三、背景

由于物聯(lián)網(wǎng)的異質(zhì)性，將有資源限制的設(shè)備安全而有效的連接起來是一項很有挑戰(zhàn)性的工作。目前，互聯(lián)網(wǎng)工程任務(wù)組正在標準化不同的協(xié)議，如CoAP，6LowPAN，低電力有損網(wǎng)絡(luò)中的IPv6路由協(xié)議，以使這些協(xié)議可以應(yīng)用在物聯(lián)網(wǎng)中。本文的重點是讓用CoAP協(xié)議的物聯(lián)網(wǎng)設(shè)備之間進行安全有效的溝通。在本章中我們突出了在輕量級CoAP發(fā)展中使用的技術(shù)，即物聯(lián)網(wǎng)的HTTP變體。

A、CoAP和DTLS CoAP是運行在不可靠UDP協(xié)議上的網(wǎng)絡(luò)協(xié)議，它最初是為物聯(lián)網(wǎng)設(shè)計的。CoAP是最常用的同步Web協(xié)議的變種，如HTTP，是專為受限制的設(shè)備和機器與機器之間的溝通設(shè)計的。

然而，盡管CoAP提供了與HTTP類似的REST接口，但與現(xiàn)在物聯(lián)網(wǎng)中它的變體相比，CoAP更注重輕量級和成本效益。為了保護CoAP傳輸，建議數(shù)據(jù)報TLS(DTLS)作為主要的安全協(xié)議，類似于TLS保護HTTP(HTTPs)，安全的DTLS CoAP協(xié)議稱為CoAPs。然后就可以通過如下的CoAPs協(xié)議安全地訪問物聯(lián)網(wǎng)設(shè)備中的web資源：

coaps://myIPv6Address:port/MyResource 我們給出了DTLS協(xié)議的簡要概述來作為DTLS壓縮機制的基礎(chǔ)。

通過對傳輸層和應(yīng)用層的操作，DTLS保證了單個機器上不同程序之間的E2E的安全。DTLS包含兩層：底層包含記錄協(xié)議，上層要么包含握手，警告和

ChangeCIPherSpec，要么包含應(yīng)用數(shù)據(jù)。ChangeCIPherSpec在握手過程中使用，這僅僅表明，記錄協(xié)議應(yīng)該通過新密碼套件和安全協(xié)商鑰匙來保護后續(xù)信息。DTLS使用警報協(xié)議來實現(xiàn)不同DTLS之間錯誤消息的傳送。圖2顯示了在IP/UDP數(shù)據(jù)報中DTLS的消息結(jié)構(gòu)。

記錄協(xié)議是上層協(xié)議的載體。記錄頭包含其他內(nèi)容類型和片段字段?；趦?nèi)容類型的值，片段字段要么包含握手協(xié)議，警告協(xié)議和ChangeCIPherSpec協(xié)議，要么包含應(yīng)用數(shù)據(jù)。

一旦握手過程完成，記錄頭主要是負責(zé)用密碼保護上層協(xié)議或應(yīng)用數(shù)據(jù)。記錄協(xié)議的保護包括機密性、完整性和真實性的保護。DTLS記錄是一個相當簡單的協(xié)議而握手協(xié)議是一個復(fù)雜的過程，它包含以異步的方式大量交換的消息。圖3給出了完整的握手過程。握手消息，通常在航班、談判安全密鑰、密碼套件和壓縮方法中使用。本文的范圍只限于報頭壓縮，而不包括處理密碼記錄和握手協(xié)議。詳細的握手消息我們參考TLS和DTLS消息。

B、6LoWPAN 6LoWPAN標準定義了與IPv6相關(guān)的WSNs中的IPv6數(shù)據(jù)報的標題壓縮和分化機制的，也稱為6LowPAN網(wǎng)絡(luò)。壓縮機制包括IP頭壓縮(IPHC)和下一個頭壓縮(NHC)。IPHC加密可以在單跳網(wǎng)絡(luò)中將IPv6頭長度壓縮至2字節(jié)，在多跳網(wǎng)絡(luò)中壓縮至7字節(jié)（1字節(jié)IPHC、1字節(jié)發(fā)送、1字節(jié)跳限制，2字節(jié)源地址，2字節(jié)目的地地址）。在IPHC中的其他加密比特是NH比特，它在設(shè)置時顯示下一個頭是用NHC壓縮。NHC是用來加密IPv6的擴展頭和UDP頭。

NHC的大小是一個多重的八位字節(jié)（主要是一個八位字節(jié)），它包含可變長度ID比特和一個特定的頭編碼比特。有些協(xié)議是UDP負載的一部分，有著類似于IP和UDP 的頭結(jié)構(gòu)。例如DTLS，IKE。因此，值得推廣6LowPAN頭壓縮機制來壓縮這些協(xié)議頭。6LowPAN標準的定義了NHC編碼，可用于UDP頭壓縮，但不能用于上層。需要一個新的NHC，因為在NHC中沒有給UDP的NH位，這表明UDP負載也壓縮了。在第四部分，我們提供了6LowPAN-DTLS的集合和6LowPAN NHCs來壓縮DTLS。

如圖1所示是頭壓縮在6LowPAN網(wǎng)絡(luò)中應(yīng)用。例如，在有限的節(jié)點和6LowPAN邊界路由器之間的應(yīng)用。6BR是用在網(wǎng)絡(luò)和英特網(wǎng)之間轉(zhuǎn)發(fā)消息前，來壓縮/解壓縮或者片段化/重新組裝它們之間的消息。在這種物聯(lián)網(wǎng)設(shè)備中，CoAP使得設(shè)備可以與網(wǎng)絡(luò)主機之間安全通信，例如標準的電腦和智能電話等，它支持CoAPs協(xié)議。為了適應(yīng)安全協(xié)議，例如在資源受限的物聯(lián)網(wǎng)中的DTLS，把6LowPAN頭壓縮機制應(yīng)用到這些協(xié)議中也是非常有益的。第四節(jié)里我們提出了DTLS的6LowPAN頭壓縮機制。以DTLS標準來設(shè)計這些報頭壓縮是非常重要的，要能夠在傳統(tǒng)的互聯(lián)網(wǎng)上與現(xiàn)有的和新的DTLS主機之間互操作。

四、DTLS壓縮

DTLS頭壓縮類似于IPHC，僅在6LowPAN網(wǎng)絡(luò)中應(yīng)用，如在傳感器節(jié)點和6BR中使用。這是因為DTLS報頭是UDP負載的一部分，而且路由所需的所有信息已經(jīng)在IP層提取。在本章中除了描述DTLS的6LowPAN頭壓縮，我們詳細介紹了如何以符合標準的方式將壓縮的DTLS連接到6 LowPAN。

A、DTLS-6LowPAN 為了將6LowPAN頭壓縮機制應(yīng)用于壓縮UDP負載中的頭，我們要么需要在6LowPAN協(xié)議中修改當前UDP中的NHC編碼，要么需要給UDP定義一個不同于ID位的新的NHC。第一個解決方案需在當前標準中修改，因此不是一個有

利的解決方案。在這篇論文中我們用了第二種方案，它是6LowPAN標準的延伸，有一個類似的方法適合于區(qū)分NHC和GHC。UDP中NHC的ID位11110，與6LowPAN中定義的標準一樣，表明UDP負載不壓縮。定義ID位11011表明UDP負載用6LowPAN-NHC壓縮。ID位1101目前在6LowPAN標準中還未定義。圖4給出了我們提出的UDP中的NHC，它允許UDP負載的壓縮。在我們的例子中，UDP負載包含用6LowPAN-NHC壓縮的DTLS頭。

B、用于記錄頭和握手頭的6LowPAN-NHC記錄協(xié)議 在使用DTLS的設(shè)備的生命周期中，給發(fā)送的每個數(shù)據(jù)包增加了13個字節(jié)長的頭字段，另一方面，握手協(xié)議，在握手消息中增加了12字節(jié)的頭。我們提出6LowPAN-NHC來壓縮記錄協(xié)議和握手協(xié)議，并分別把頭長度減少到3~5個字節(jié)。在所有情況下，記錄頭仍是未加密的。因此，總是用在這章中解釋的機制來壓縮。

為了向記錄和握手頭提供頭壓縮，我們考慮兩種情況。在第一種情況中，記錄頭的片段（見第三部分）包含握手消息，我們用加密字節(jié)來壓縮記錄和握手頭消息，并且給出了記錄+握手中6LowPAN-NHC的定義。在第二種情況下，我們給記錄頭定義了6LowPAN-NHC（6LowPAN-NHC-R），與第一種情況不同的是，在記錄頭中的片段是應(yīng)用數(shù)據(jù)而不是握手消息。

我們成功實現(xiàn)了在DTLS握手后應(yīng)用6LowPAN-NHC-R，并且對隨后的消息進行加密和完整性保護。圖2a給出了記錄+握手頭和記錄頭的6LowPAN-NHC加密。加密為有以下功能：前4位代表的ID字段用來區(qū)分 6LowPAN-NHC-RHS和其他編碼，而且符合 6LowPAN-NHC編碼方案。在 6LoWPAN-NHC-RHS情況下我們把ID位設(shè)置到了1000，在 6LoWPAN-NHC-R情況下ID位設(shè)置到了1001。

版本（V）：如果是0，是最新的DTLS，版本1.2，省略了字段。如果是1，版本字段進行內(nèi)聯(lián)。

時代（EC）：如果是0，使用了八位表示時代，最左邊的八位省略。如果是1，所有16為進行內(nèi)聯(lián)。在大多數(shù)情況下實際年代要么是0要么是1。所以通常使用8位表示年代，這樣允許更大的空間。

序列號（SN）：序列號包含48位，有些事前導(dǎo)0。如果序列號設(shè)為0，就用了16位的序列號，并且左邊的32位省略了。如果是1，所有的48位用于內(nèi)聯(lián)。如圖5a所示，在 6LoWPAN-NHC-R情況下，我們的SN設(shè)為2位，這樣可以更高效的壓縮序列號字段。如果SN=00，就用了16位的序列號，并且左邊的32位省略了。如果SN=01，就用了32位的序列號并且最左邊的32位省略。如果SN=01，就用了32位的序列號，并且最左邊的16位省略了。如果SN=10，就用了24位的序列號，并且最左邊的24位省略了。如果SN=11，所有的48位序列號用于內(nèi)聯(lián)。

片段（F）：如果F=0，則握手消息沒有片段化，并且省略了fragment_offset 和 fragment_length字段。這是常見的情況，如果握手消息短于最大記錄長度時就會發(fā)生。如果F=1，fragment_offset 和 fragment_length字段用于互聯(lián)。

在記錄頭上，content_ type字段總是用于內(nèi)聯(lián)。記錄頭中的長度字段總是省略，因為可以從較低層推算出：或者從 6LoWPAN的頭，或者從 IEEE 802.15.4的頭。我們必須從低層到高層解壓layer-wise，直到完全解壓出UDP報頭。然后就可以知道UDP有效負載的長度并可以計算出DTLS負載長度。由于我們希望在受限的環(huán)境中每個UDP包只有一個DTLS記錄頭，所以記錄頭的長度字段也省略了。當 6LoWPAN中的源裝置在每個UDP包中發(fā)送一個DTLS記錄時，傳統(tǒng)網(wǎng)絡(luò)側(cè)會有典型的目的裝置在一個UDP包中傳送多個DTLS記錄頭。然而，當6BR對傳入的包執(zhí)行壓縮/解壓時，有可能在6LoWPAN網(wǎng)絡(luò)中給出這些包的路由之前，對每個UDP包執(zhí)行一個DTLS記錄。

C、6LoWPAN-NHC for ClientHello 我們提出了客戶端友好型的消息6LoWPAN-NHC（6LoWPAN-NHC-C）。在握手過程中會發(fā)送兩次客戶端友好型消息，第一次沒有cookie而第二次有服務(wù)器的cookie。圖5b給出了用6LoWPAN-NHC對客戶端友好型消息進行加密的過程。

每一個壓縮頭字段的功能描述如下： 6LoWPAN-NHC-CH中前四位設(shè)為1010用來表示ID字段。

會話ID（SI）：如果SI=0，session_id不可用，并將這一字段和8位的前綴長度字段省略。在DTLS協(xié)議中如果沒有字段可用，或者用戶想生成新的安全參數(shù)，那么session_id就是空的。只有在DTLS客戶想要恢復(fù)舊會話時，才會使用ClientHello消息。真正的ClientHello中session_id字段包含0-32字節(jié)。然而，它的前綴中總是有一個8位的字段來表示session_id的大小。如果SI=1，session_id字段用于內(nèi)聯(lián)。

Cookie（C）如果C=0，cookie字段不可用，省略這一字段和前綴8位。在ClientHello中真正的cookie字段包含1-255字節(jié)。然而，它總是有8位來表示cookie的長度。如果C=1，cookie字段用于內(nèi)聯(lián)。

密碼套件（CS): 如果CS=0，使用了CoAP默認的（強制性）支持自動的鍵管理的密碼套件，并且這個字段和前綴16位被省略了。在當前的CoAP草稿中，TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8是一個強制性的密碼套件。真正的密碼套件字段包含2-2^16?1字節(jié)。并且在前綴中包含16字節(jié)來表示 cIPher_suites的大小。如果C=1，cipher_suites用于內(nèi)線互聯(lián)。

壓縮方法（CM）：如果CM=0，就為默認的壓縮方法，例如，用到了COMPRESSION_NULL，省略這個字段和前綴8位字段。實際上壓縮方法字段包含1-2^8-1字節(jié)。它總是在前綴八位包含壓縮方法的大小。如果CM=1，那么壓縮

方法字段用于內(nèi)線互聯(lián)。

在ClientHello中隨機字段總是用于內(nèi)線互聯(lián)并且總是省略版本字段。版本字段包含的值與DTLS記錄頭中的值一樣。在TLS/SSL情況下，定義版本字段來讓一個TLS的客戶指定一個舊版本以兼容SSL客戶機，而這在實際中很少用到。當前所有的Web瀏覽器在記錄和ClientHello中使用相同的TLS版本。DTLS1.2（改編自TLS 1.2）提到客戶在ClientHello消息中發(fā)送最新的支持版本。所有DTLS版本(1.0和1.2)的ClientHello消息相兼容。如果客戶機不兼容這種版本，那么ServerHello消息將包含支持的版本。如果客戶不能夠處理服務(wù)器的版本，它將給出終止與協(xié)議版本連接的警報。

使用 6LoWPAN-NHC-CH，通常只傳送 ClientHello消息中的隨機字段，而省略所有其他字段。同時，cookie會包含可壓縮的字段。圖6給出了一個包含ClientHello且未壓縮的IP/UDP數(shù)據(jù)報。圖7給出了我們提出的壓縮DTLS，它包含ClientHello消息。在應(yīng)用IPHC和 6LoWPAN-NHC頭壓縮后，數(shù)據(jù)報的尺寸是顯著降低了。

D、服務(wù)器友好型 6LoWPAN-NHC 我們提出了SeverHello消息的 6LoWPAN-NHC（6LoWPAN-NHC-SH）。SeverHello與ClientHello除了密碼套件和壓縮方法字段分別位16和8位外，它們非常相似。圖5給出了用 6LoWPAN-NHC 加密的ServerHello消息。每個壓縮頭的功能描述如下：前6 LoWPAN-NHC-SH中前四位設(shè)置為1011代表ID字段。版本（V）：為了在最初版本的握手中避免談判，DTLS 1.2標準表明服務(wù)器的實現(xiàn)應(yīng)該使用DTLS 1.0版本。如果V設(shè)為0，就使用DTLS1.0版本并省略版本字段。盡管DTLS1.2客戶端不能假定服務(wù)器不支持更高的版本，否則它最終將使用DTLS1.0而非DTLS1.2。如果V設(shè)為1，那么版本字段用于內(nèi)線互聯(lián)。

會話（ID），密碼套件（CS）和壓縮方法（CM）的加密方式與討論的IV-C部分類似。為了不影響安全性ServerHello中的隨機字段總是進行內(nèi)聯(lián)。

E、其他握手消息中的 6LoWPAN-NHC 剩下的強制性握手消息ServerHelloDone ClientKeyExchange，和Finish沒有可以壓縮的字段，因此所有字段進行內(nèi)聯(lián)。包含了證書鏈的可選的握手消息和包含了握手消息的數(shù)字簽名的 CertificateVerify，也用來內(nèi)線互聯(lián)。然而，壓縮一些證書中的字段也是可能的，但超出了本文的范圍。Pritikin提出了X.509的壓縮計劃。

大多數(shù)時候不傳送ServerKeyExchange消息，要么由于加密的出口限制要么因為服務(wù)器的證書消息包含足夠的信息來承認客戶端交換premaster secret。然而，如果傳送了這一消息，那么所有的字段都用于內(nèi)線互聯(lián)。在可選的消息CertificateRequest的情況下所有的字段都可以省略。這是可能實現(xiàn)的，因為certificate_types，supported_signature_algorith和 certificate_authorities字段可以在6LoWPAN網(wǎng)絡(luò)的一組支持的和優(yōu)先的值之前定義，并且所有的網(wǎng)絡(luò)中的節(jié)點使用相同的設(shè)置值。在傳統(tǒng)的互聯(lián)網(wǎng)中，在將消息發(fā)送到目的地之前，6 BR可以通過缺省設(shè)置值來填充空CertificateRequest消息。如果 6LoWPAN網(wǎng)絡(luò)中沒有定義缺省的設(shè)置值，那么所有字段用于內(nèi)線互聯(lián)。

五、實現(xiàn)

我們在Contiki中實現(xiàn)了Lithe，Contiki是物聯(lián)網(wǎng)的開放源代碼的操作系統(tǒng)。

然而，我們建議的報頭壓縮機制可以在任何支持6LowPAN的操作系統(tǒng)中實現(xiàn)。Lithe的實現(xiàn)包含4個部分（1）DTLS（2）CoAP(3)CoAP和DTLS的集合模型。（4）DTLS頭壓縮。DTLS部分，我們使用了開放源代碼的微型DTLS，它支持基于pre-shared鍵的基本的密碼套件：TLS_PSK_WITH_AES_128_CCM_8。我們使得微型DTLS適用于WiSMote平臺和支持 msp430-gcc的20位地址。（版本4.7.0）。CoAP部分，我們在Contiki操作系統(tǒng)中實現(xiàn)缺省的CoAP。我們開發(fā)出了連接CoAP和DTLS的集成模型，并可以使用CoAPs協(xié)議。這種集成允許應(yīng)用程序獨立訪問CoAPs，在這里CoAP消息都是透明的傳送給能夠傳輸保護信息到目的地DTLS。所有的傳入消息都通過DTLS來保護，因此在DTLS層首先處理并透明傳送給駐留在應(yīng)用層的CoAP。

第四節(jié)我們實現(xiàn)提出的頭壓縮作為在Contiki操作系統(tǒng)中實現(xiàn)的6LoWPAN 的擴展。6LoWPAN 層在IP層和MAC層之間。IP層的數(shù)據(jù)包可以從節(jié)點傳出來作為輸出數(shù)據(jù)包。MAC層節(jié)點接受到的數(shù)據(jù)包被看做輸入包。6LoWPAN層從兩個方向處理所有UDP包。因此，我們使用兩種方法來從其他UDP包中區(qū)分攜帶DTLS消息的UDP包做為有效載荷。在輸入包情況下，預(yù)配置的默認DTLS端口用于識別CoAPs消息。在第二種情況下，包從MAC層接受，NHC-for-UDP和DTLS頭的NHC中的DTLS端口和ID位用來區(qū)分壓縮頭和未壓縮的頭。第四節(jié)中給出了細節(jié)。

此外，重要的是要強調(diào)，盡管應(yīng)用頭壓縮，端到端的安全性是不能降低的。這是由于DTLS的設(shè)計和我們的努力來保持標準兼容。頭字段在與密碼套件聯(lián)系之后，在記錄層進行完整性保護。在壓縮/解壓過程中不修改原來的標題也保護了完整性。在6LoWPAN層解壓后，在DTLS層進行包的完整性檢查。把正確性完整性保護作為正確的減壓證明。

六、評價

我們在運行Contiki操作系統(tǒng)的真正的傳感器節(jié)點上評估Lithe。我們用 WiSMote作為硬件平臺。該平臺的配置有（1）16兆赫，MSP430 5系列、16位RISC微控制器，（2）128/16 kB的 ROM/RAM，（3）一個IEEE 802.15.4(CC2520)收發(fā)器。我們選擇WiSMotes是因為由于RAM和ROM的需要DTLS實現(xiàn)，這會在第六章B部分詳細討論。網(wǎng)絡(luò)設(shè)備包括兩個直接通過無線電通信的WiSMotes。CC2520收發(fā)器提供了一個AES-128安全模塊。然而，對我們不使用AES硬件支持而依靠軟件AES來評估。利用涉及DTLS的AES硬件支持的加密計算得到了更高的性能。我們的評價關(guān)注的是DTLS報頭壓縮對響應(yīng)時間和能源消耗節(jié)點的影響。因此，由于軟件AES造成的性能損失不會影響我們的評估。此外，為了能夠分析單獨壓縮的處理開銷，我們不支持鏈路層安全。在先前的工作中，我們已經(jīng)用AES支持的硬件來評估性能增益。在那里，我們實施和評估了IEEE802.15.4鏈路層安全。

A、減少數(shù)據(jù)包大小

我們可以使用6LoWPAN-NHC壓縮機制顯著降低DTLS頭的長度。表1顯示了我們提出的DTLS頭壓縮顯著減少了頭比特的數(shù)量，這也類似地減少了無線傳輸時間。

包含在所有DTLS消息中的記錄頭，可以壓縮64位，節(jié)省62%的空間。在握手頭的情況下，可以節(jié)省75%的空間。應(yīng)用程序數(shù)據(jù)構(gòu)成的最大數(shù)量的DTLS消息。把記錄頭從104位減少到40位，就允許在每個包中多傳送64位。大于鏈路層MTU的數(shù)據(jù)包是分散的。碎片不僅引入更多的節(jié)點和網(wǎng)絡(luò)開銷，它也帶來安全漏洞。因此，只要有可能，最好避免碎片。在有效載荷略高于分割閾值時，我們使用壓縮來避免碎片或減少碎片的數(shù)量。此外，在有限的網(wǎng)絡(luò)中減少傳輸比特對網(wǎng)絡(luò)的性能和壽命有著巨大的影響。無線電通信的能源消耗通常高于節(jié)點內(nèi)計算約10倍。壓縮的能源消耗平衡在用于壓縮和解壓縮的額外內(nèi)部節(jié)點與減少無線傳輸之間。這種權(quán)衡的影響將在第六章C部分進一步討論。

B、RAM和ROM的要求

我們用MSP430工具鏈中的msp430-objdump工具來分析靜態(tài)RAM和ROM。如表2所示，Lithe需要59.4kB的ROM和9.2kB的RAM。

DTLS的實現(xiàn)包括密碼功能并且DTLS狀態(tài)機需要16.8 kB的ROM和3.7 kB的 RAM。

這使得DTLS對ROM來說是僅次于操作系統(tǒng)的主要貢獻者。The CoAP-Server 需要8 kB的ROM 和.5 kB 的RAM.我們的CoAP-Server提供單個的資源，這基于CoAP GET請求，把可變負載長度的響應(yīng)消息發(fā)送回來。我們的評價中用這個來分析壓縮對不同負載長度的CoAPs消息的影響。COAP得以實現(xiàn)的腳本取決于提供的資源。DTLS頭實現(xiàn)了對ROM壓縮2820字節(jié)，對靜態(tài)RAB

壓縮一個字節(jié)。一個字節(jié)的靜態(tài)RAM對UDP報頭的壓縮。在Contiki中 6LoWPAN使用的用來壓縮和片段化的（沒有DTLS壓縮）全部ROM是3782字節(jié)。這驗證了壓縮的DTLS使用相同的ROM順序作為標準的6LoWPAN。如今的感知節(jié)點，例如帶有128K字節(jié)的WiSMote一定能滿足壓縮的CoAPs和其他操作系統(tǒng)的組件，而且還可以提供為其他應(yīng)用提供重要的空間。

C、運行時間性能

我觀察當使用壓縮的DTLS時的運行時間性能，并把它與使用為經(jīng)壓縮的DTLS做比較。我們分別在一個具有 Radio Duty Cycling(RDC)和沒有RDC的6LoW-PAN網(wǎng)絡(luò)中進行這個實驗。當使用RDC時，收音機在大部分時間是關(guān)閉的，并且要么在特定的間隔打開來檢查傳入數(shù)據(jù)包的媒介，要么在傳送包是打開。我們使用在Contiki操作系統(tǒng)中提供的duty cycled MAC協(xié)議，有著默認設(shè)置的X-MAC。在我們對運行時間進行評估時，我們關(guān)注的是傳感器節(jié)點的能量消耗和網(wǎng)絡(luò)范圍的執(zhí)行時間。為評估能量消耗，我們使用Contiki操作系統(tǒng)提供的能量估計模塊。這個模塊提供CPU的使用時間，LPM，特定函數(shù)收發(fā)器。每個這些組件的絕對計時器值可以使用以下方程轉(zhuǎn)換成能源：

（1）DTLS壓縮開銷：DTLS頭的節(jié)點內(nèi)計算壓縮和解壓縮而引起的開銷幾乎可以忽略不計。然而，為了完整性我們測量和顯示它的完整性。圖8顯示了頭消息中用于壓縮（壓縮和解壓縮）的額外能量消耗。每一個握手消息包含記錄和握手頭。平均來說，每個基于預(yù)共享秘鑰的DTLS握手消息消耗4.2uJ能量。

（2）CoAPs初始化：在CoAPs初始化過程中在使用DTLS握手協(xié)議的兩個通信終端建立了一個安全會話。這一握手過程同時使用了記錄和握手頭，這意味著這兩種頭都可以被壓縮。額外的節(jié)點內(nèi)計算和減少數(shù)據(jù)包大小之間的權(quán)衡表明

他自身在DTLS握手時傳輸包的能源消耗。表3把在應(yīng)用壓縮情況下的傳輸能量損耗和未應(yīng)用壓縮情況下的能量損耗進行了比較。平均來看，傳輸和接受壓縮包需要使用的能量減少15%。這是因為在壓縮過程中包的大小變的更小。

（3）CoAPs請求-響應(yīng)：一旦CoAPs初始化過程完成了，例如已經(jīng)完成了握手，一個感知節(jié)點就可以通過DTLS記錄協(xié)議來發(fā)送/接收安全的CoAP消息。盡管與記錄協(xié)議相比握手協(xié)議的能量消耗更大，但它旨在初始化階段或接下來的預(yù)握手階段執(zhí)行。

為了測量記錄頭的壓縮性能，我們在CoAP請求-應(yīng)答消息過程中測量能量消耗和往返時間（RTT）。當客戶準備CoAP請求時我們開始測量，并在收到服務(wù)器應(yīng)答和處理后結(jié)束。相應(yīng)的CoAP響應(yīng)包含不同的負載長度。更精確來說，在0-48字節(jié)范圍中使用了8種不同的負載大小。我們選擇了48是因為在CoAPs情況下，48字節(jié)的CoAP負載 中6LoWPAN 片段發(fā)揮了作用。然而，Lithe不會導(dǎo)致碎片，因為通過壓縮減少了比特。可以在圖9a中看出這種作用，該圖表明了CoAP的客戶端，以及傳送壓縮和未壓縮的CoAPs的請求和應(yīng)答（不帶RDC且長度不一樣）的客戶機的平均內(nèi)部節(jié)點損耗。由于應(yīng)答消息總是一個常量，所以傳送CoAP GET應(yīng)答消息所需的能量一樣。因此，CoAP應(yīng)答的能量消耗可以通過壓縮來降低10%。因此，減少的能量范圍在4-26%，其中最大可以節(jié)省48字節(jié)的能量。

為了分析CoAPs請求—響應(yīng)的總體能量損耗，我們疊加了客戶端和服務(wù)器之間的能量損耗，并在圖9b中給出了描述。在該圖中我們觀察到平均節(jié)省了約7%的能量。然而，通過壓縮來避免碎片的情況下，節(jié)省的能量達到了20.6%。這是因在48字節(jié)的負載中，6LoWPAN在兩個碎片中傳送包，而經(jīng)過壓縮后包就不會在碎片中傳送。

減少的傳送時間也會影響將RTT應(yīng)用于CoAPs的請求—應(yīng)答消息，如圖10b所示，在沒有RDC的情況下，RTT平均減小1.5%，除了48字節(jié)的負載。在這種情況下，帶壓縮的RTT甚至能效77%，因為避免了碎片。為了評估由安全性引起的總體開銷，我們也在沒有安全性的CoAP中加了值。只要不需要碎片。沒有安全性的CoAP中的RTT占CoAPs的1/3。在圖10b中我們看有RDC的RTT，我們可以看到所有的三種情況：（1）沒有任何安全性的CoAP（2）CoAPs（3）帶有DTLS壓縮的DTLS（Lithe），RTT值都在同一范圍，處理CoAP應(yīng)答消息有48字節(jié)的負載。這是RDC的副作用。RDC通過把收音機加入大部分休眠狀態(tài)而節(jié)省了很多能量。然而這樣的代價是時延變大。RDC中的包并不直接傳輸。發(fā)送方必須等到接收方醒來，最壞的情況會將等待整個休眠期。結(jié)果表明，總體來說使用RTT的等待時間比未使用RTT長。我們在帶有RDC的網(wǎng)絡(luò)中觀察到了這一現(xiàn)象。例如，圖10b，帶偶48字節(jié)的負載，壓縮使得RTT縮小了50%。

七、結(jié)論

能夠應(yīng)用COAP的主機將會成為物聯(lián)網(wǎng)不可分割的一部分。此外，現(xiàn)實中使用COAP的裝置需要安全解決方案。為此，DTLS是使CoAP(CoAPs)安全的標準協(xié)議。在這篇論文中我們調(diào)查了通過 6LoWPAN頭壓縮來減少DTLS開銷的可能性，并且給出了6LoWPAN第一個DTLS報頭壓縮規(guī)范。結(jié)果定量的表明可以壓縮DTLS并且可以使用6LoWPAN標準壓縮機制來大大減少它的開銷。我們對壓縮的DTLS的實現(xiàn)結(jié)果和評估表明，與CoAPs相比，由于從能量消耗和網(wǎng)絡(luò)響應(yīng)時間方面來看，DTLS壓縮具有高效性，這使得可以減少CoAP的開銷。如果使用未壓縮的DTLS導(dǎo)致了6LoWPAN的碎片，那么壓縮的DTLS與未壓縮的DTLS有著顯著的不同。

在未來的工作中我們計劃在有真實的應(yīng)用場景的真實的物聯(lián)網(wǎng)系統(tǒng)中部署Lithe。這樣的物聯(lián)網(wǎng)設(shè)置由受限設(shè)備，標準的電腦和智能手機組成。在現(xiàn)實世界中部署幫助我們對一個異構(gòu)物聯(lián)網(wǎng)進行徹底評估，并最終證明Lithe在對安全敏感的應(yīng)用中的使用情況。

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

3、PCDP層服務(wù)

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

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

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

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

4、PDCP層功能

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

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

（5）下層重建時，RLC AM模式下的映射的無線承載的下層SDU重復(fù)消除（6）用戶面數(shù)據(jù)和控制面數(shù)據(jù)的加密和解密（7）控制面數(shù)據(jù)的完整性保護與完整性驗證（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。同時，進行發(fā)送相關(guān)的狀態(tài)變量更新及加密、完整性保護等，具體過程如圖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但尚未得到確認的)，因此，UE的PDCP實體收到的PDCP SDU可能是亂序并且有重復(fù)的，因此對于RLC AM模式，在重建情況下，PDCP接收實體需對接收的PDCP SDU進行重排序和重復(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)報告確認，UE丟棄PDCP SDU及相應(yīng)的PDCP PDU（5）頭壓縮與解壓縮：

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

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

（7）完整性保護及確認：該功能僅用于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：消息認證碼、未經(jīng)過完整性保護的控制面數(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是否被接收并正確的進行選擇性解壓

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值進行加密 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以及確認其完整性

（2）否則

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

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

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

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）否則，如果完整性確認適用，但失敗

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

5.2 重建過程

5.2.1 上行

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

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

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

（3）從第一個對應(yīng)的PDCP PDU成功傳遞但沒有被下層確認的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過程 當上層請求一次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認為此PDCP SDU是從上層接收而來

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

3、SRB過程

當上層請求一次PDCP重建時

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

5.2.2 下行

1、映射到RLC AM的DRB過程

當上層請求一次PDCP重建時

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

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

2、映射到RLC UM的DRB過程 當上層請求一次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)使用加密算法和上層提供的密鑰進行加密

3、SRB過程

當上層請求一次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)使用加密和完整性保護算法，以及使用上層提供的密鑰進行加密

5.3 PDCP狀態(tài)報告

5.3.1 傳輸

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

如果此RB被上層配置用于在上行鏈路發(fā)送一個PDCP狀態(tài)報告，在處理完因下層重建而從下層接收來的PDCP Data PCU以后，UE應(yīng)按下述指示進行狀態(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 接收

當在下行鏈路接收到一個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的成功傳輸將被確認，且UE應(yīng)按照PDCP丟棄過程的規(guī)定來處理此PDCP。

5.4 PDCP丟棄

當用于PDCP SDU的discardTimer終止，或PDCP SDU的成功傳輸被PDCP狀態(tài)報告確認，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ù)

壓縮與解壓縮端之間定義了必須有上層配置的強制配置參數(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）獨立數(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é)議進行解壓縮

5.6 加密和解密

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

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

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

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

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

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

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

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

5.7 完整性保護及確認

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第四篇：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實體進行配置，來使用頭壓縮。每個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）完整性保護 從下層得到的服務(wù)：（RLC層向PDCP層提供服務(wù)）

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

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

4、PDCP層功能

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

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

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

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

（7）控制面數(shù)據(jù)的完整性保護與完整性驗證(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。同時，進行發(fā)送相關(guān)的狀態(tài)變量更新及加密、完整性保護等，PDCP SDU的Discard_Timer超時或PDCP SDU的成功傳輸有PDCp狀態(tài)報告確認，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但尚未得到確認的)，因此，UE的PDCP實體收到的PDCP SDU可能是亂序并且有重復(fù)的，因此對于RLC AM模式，在重建情況下，PDCP接收實體需對接收的PDCP SDU進行重排序和重復(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)報告確認，UE丟棄PDCP SDU及相應(yīng)的PDCP PDU（5）頭壓縮與解壓縮：

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

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

（7）完整性保護及確認：該功能僅用于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ù)

壓縮與解壓縮端之間定義了必須有上層配置的強制配置參數(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）獨立數(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é)議進行解壓縮

5.6 加密和解密

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

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

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

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

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

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

（2）DIRECTION：標識傳輸?shù)姆较颍?用于上行、1用于下行

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

5.7 完整性保護及確認

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6、那個CRC怎么計算呢？

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