6LowPAN的適配層

適配層適配層是IPv6網(wǎng)絡(luò)和IEEE 802.15.4MAC層間的一個中間層，其向上提供IPv6對IEEE 802.15.4媒介訪問支持，向下則控制LowPAN網(wǎng)絡(luò)構(gòu)建、拓?fù)浼癕AC層路由。6LowPAN的基本功能，如鏈路層的分片和重組、頭部壓縮、組播支持、網(wǎng)絡(luò)拓?fù)錁?gòu)建和地址分配等均在適配層實(shí)現(xiàn)。1. 適配層基本功能由于最大MTU、組播及MAC層路由等原因，IPv6不能直接運(yùn)行在IEEE 802.15.4MAC層之上，適配層將起到中間層的作用，同時(shí)提供對上下兩層的支持，其主要功能如下：l 鏈路層的分片和重組：IPv6規(guī)定數(shù)據(jù)鏈路層最小MTU為1280字節(jié)，對于不支持該MTU的鏈路層，協(xié)議要求必須提供對IPv6透明的鏈路層的分片和重組。因此，適配層需要通過對 IP報(bào)文進(jìn)行分片和重組來傳輸超過IEEE 802.15.4MAC層最大幀長（127字節(jié)）的報(bào)文。l 組播支持：組播在IPv6中有非常重要的作用，IPv6特別是鄰居發(fā)現(xiàn)協(xié)議的很多功能都依賴于IP層組播。此外，WSN的一些應(yīng)用也需要MAC層廣播的功能。IEEE 802.15.4 MAC層不支持組播，但提供有限的廣播功能，適配層利用可控廣播共泛的方式來在整個WSN中傳播IP組播報(bào)文。l 頭部壓縮：在不使用安全功能的前提下，IEEE 802.15.4 MAC層的最大payload為102字節(jié)，而IPv6報(bào)文頭部為40字節(jié)，再除去適配層和傳輸層(如UDP)頭部，將只有50字節(jié)左右的應(yīng)用數(shù)據(jù)空間。為了滿足IPv6在IEEE 802.15.4 傳輸?shù)腗TU，一方面可以通過分片和重組來傳輸大于102字節(jié)的IPv6報(bào)文，另一方面也需要對IPv6報(bào)文進(jìn)行壓縮來提高傳輸效率和節(jié)省節(jié)點(diǎn)能量。為了實(shí)現(xiàn)壓縮，需要在適配層頭部后增加一個頭部壓縮編碼字段，該字段將指出IPv6頭部哪些可壓縮字段將被壓縮，例如，傳輸類型和流標(biāo)識符均為0時(shí)將在頭部壓縮編碼字段被指出并且在IPv6頭部中省去。除了對IPv6頭部以外，還可以對上層協(xié)議(UDP、TCP及ICMPv6)頭部進(jìn)行進(jìn)一步壓縮。l 網(wǎng)絡(luò)拓?fù)錁?gòu)建和地址分配：IEEE 發(fā)布的標(biāo)準(zhǔn)文檔IEEE Std 802.15.4-2003對802.15.4協(xié)議物理層和MAC層做了詳盡地描述，其中MAC層提供了功能豐富的各種原語，包括信道掃描、網(wǎng)絡(luò)維護(hù)等。但MAC層并不負(fù)責(zé)調(diào)用這些原語來形成網(wǎng)絡(luò)拓?fù)洳ν負(fù)溥M(jìn)行維護(hù)，因此調(diào)用原語進(jìn)行拓?fù)渚S護(hù)的工作將由適配層來完成。另外，6LowPAN中每個節(jié)點(diǎn)都是使用EUI-64地址標(biāo)識符，但是一般的LowPAN網(wǎng)絡(luò)節(jié)點(diǎn)能力非常有限，而且通常會有大量的部署節(jié)點(diǎn)，若采用64-bits地址將占用大量的存儲空間并增加報(bào)文長度，因此，更適合的方案是在PAN內(nèi)部采用16-bits短地址來標(biāo)識一個節(jié)點(diǎn)，這就需要在適配層來實(shí)現(xiàn)動態(tài)的16-bits短地址分配機(jī)制。l MAC層路由：現(xiàn)網(wǎng)絡(luò)拓?fù)錁?gòu)建和地址分配相同，IEEE 802.15.4標(biāo)準(zhǔn)并沒有定義MAC層的多跳路由。適配層將在地址分配方案的基礎(chǔ)上提供兩種基本的路由機(jī)制樹狀路由和網(wǎng)狀路由。適配層是整個6LowPAN的基礎(chǔ)框架，6LowPAN的其它一些功能也是基于該框架實(shí)現(xiàn)的。整個適配層功能模塊的示意圖：2. 適配層幀格式由于LowPAN網(wǎng)絡(luò)有報(bào)文長度小、低帶寬、低功耗的特點(diǎn)，為了減小報(bào)文長度，適配層幀頭部分為兩種格式，即不分片和分片，分別用于數(shù)據(jù)部分小于MAC層MTU(102字節(jié))的報(bào)文和大于MAC層MTU的報(bào)文。當(dāng)IPv6報(bào)文要在802.15.4鏈路上傳輸時(shí)，IPv6報(bào)文需要封裝在這兩種格式的適配層報(bào)文中，即IPV6報(bào)文作為適配層的負(fù)載緊跟在適配層頭部后面。特別地，若”M”或“B”bit被置為1時(shí)，適配層頭部后面將首先出現(xiàn)MB或Broadcast字段，IPv6報(bào)文則出現(xiàn)在這兩個字段之后。1） 不分片報(bào)文格式不分片頭部格式的各個字段含義如下：l LF：鏈路分片(Link Fragment)，占2bits。此處應(yīng)為00，表示使用不分片頭部格式。l prot_type：協(xié)議類型，占8bits。指出緊隨在頭部后的報(bào)文類型。1表示IPv6報(bào)文，2表示頭部壓縮編碼字段。4表示路由錯誤報(bào)文。l M：Mesh Delivery字段標(biāo)志位，占1 bit。若此位置為1，則適配層頭部后緊隨著的是”Mesh Delivery”字段。l B：Broadcast標(biāo)志位，占1 bit。若此位置為1，則適配層頭部后緊隨著的是”Broadcast”字段。l rsv：保留字段，全部置為0。2） 分片報(bào)文格式若一個包括適配層頭部在內(nèi)的完整負(fù)載報(bào)文不能夠在一個單獨(dú)的 IEEE 802.15.4幀中傳輸時(shí)，需要對負(fù)載報(bào)文進(jìn)行分片，此時(shí)適配層使用分片頭部格式封裝數(shù)據(jù)。分片頭部格式如下：分片頭部格式的各個字段含義如下：l LF：鏈路分片(Link Fragment)，占2bits。當(dāng)該字段不為0時(shí)，指出鏈路分片在整個報(bào)文中的相對位置，其中具體定義如下表所示。LF鏈路分片位置00不分片01第一個分片10最后一個分片11中間分片l prot_type：協(xié)議類型，占8 bits，該字段只在第一個鏈路分片中出現(xiàn)。l M： Mesh Delivery字段標(biāo)志位，占1 bit。若此位置為1，則適配層頭部后緊隨著的是”Mesh Delivery”字段。若需要在Mesh拓?fù)渲新酚?，每個分片中都應(yīng)該有該字段。l B：Broadcast標(biāo)志位，占1 bit。若此位置為1，則適配層頭部后緊隨著的是”Broadcast”。若是廣播幀，每個分片中都應(yīng)該有該字段。l datagram_size：負(fù)載報(bào)文的長度，占11 bits，所以支持的最大負(fù)載報(bào)文長度為2048字節(jié)，可以滿足IPv6報(bào)文在IEEE 802.15.4上傳輸?shù)?280字節(jié)MTU的要求。另外，在每個適配層分片中都需要攜帶該字段，這樣能夠使目的節(jié)點(diǎn)能在收到任何一個分片后(目的節(jié)點(diǎn)不一定首先收到第一個分片)確定重裝后報(bào)文的大小而作一些有用的預(yù)處理，如預(yù)先分配緩沖區(qū)或者丟棄超過本節(jié)點(diǎn)能處理 最大字節(jié)數(shù)的報(bào)文。l datagram_tag：分片標(biāo)識符，占9 bits，同一個負(fù)載報(bào)文的所有分片的datagram_tag字段應(yīng)該相同。每個節(jié)點(diǎn)都需要維護(hù)一個變更來記錄當(dāng)前的datagram_tag值，在節(jié)點(diǎn)初始化時(shí)應(yīng)該將該值初始化為一個隨機(jī)值(0511)，每發(fā)送一個完整的負(fù)載報(bào)文(而不是一個分片)該值加1，當(dāng)該值達(dá)到511后翻轉(zhuǎn)為0。l fragment_offset：報(bào)文分片偏移，8 bits。該字段只出現(xiàn)在第二個以及后繼分片中，指出后繼分片中的payload相對于原負(fù)載報(bào)文的頭部的偏移。該字段以8字節(jié)為單位，因此分片報(bào)文的payload必須以8字節(jié)為邊界對齊。另外，由于負(fù)載報(bào)文的第一個字節(jié)偏移一定為0，所以第一個分片的fragment_offset值默認(rèn)為0。3） Mesh Delivery字段4） 若適配層頭部(分片或不分片格式)M字段為1，則Mesh Delivery字段緊隨在分片或不分片的適配層頭部之后，其格式如下圖所示。Mesh Delivery字段的各個字段含義如下：l O：源地址類型標(biāo)志位, 占1 bit，指出源地址（MAC地址）字段使用的地址是EUI-64長地址還是16-bits短地址。若此位為0表示EUI-64地址；為1表示16-bits短地址。l F：最終目的地址類型標(biāo)志位, 占1 bit，指出最終目的地址字段使用的地址是EUI-64長地址還是16-bits短地址。若此位為0表示EUI-64地址；為1表示16-bits短地址。l Hops Left：剩余跳數(shù)，占6 bits。每經(jīng)過一個轉(zhuǎn)發(fā)節(jié)點(diǎn)該值減1。若該字段值減小到0轉(zhuǎn)發(fā)節(jié)點(diǎn)就丟棄該幀。l Originator Address：源鏈路層地址，可以為EUI-64地址，也可以為16-bits短地址。l Final Destination Address：最終目的鏈路層地址，可以為EUI-64地址，也可以為16-bits短地址。5） Broadcast字段若適配層頭部B字段為1，則Broadcast字段緊隨在適配層頭部之后，其格式如下所示。Broadcast字段的各個字段含義如下：l S：廣播源地址類型標(biāo)志位，占1 bit。指出使用源地址是EUI-64長地址還是16-bits短地址。若此位為0表示EUI-64地址；為1表示16-bits短地址。l Broadcast Radius：廣播范圍，7 bits。適配層廣播幀每經(jīng)過一個轉(zhuǎn)發(fā)節(jié)點(diǎn)中繼該字段值減1，若該字段減小到0轉(zhuǎn)發(fā)節(jié)點(diǎn)停止繼續(xù)轉(zhuǎn)發(fā)該幀，但是本節(jié)點(diǎn)要將已經(jīng)收到的廣播幀提交給上層處理。l Sequence Number：廣播幀序號，8 bits。每個節(jié)點(diǎn)需要維護(hù)一個變量來記錄當(dāng)前的廣播序號值，在節(jié)點(diǎn)初始化時(shí)將該值設(shè)為一個隨機(jī)值(0255)，每發(fā)送一個廣播幀時(shí)將=當(dāng)前變量值填入Sequence Number字段并將該值加1，當(dāng)達(dá)到255后翻轉(zhuǎn)為0。l Source Address：廣播幀源鏈路層地址，可以為EUI-64地址，也可以為16-bits短地址。3.分片和重組當(dāng)一個負(fù)載報(bào)文不能在一個單獨(dú)的IEEE 802.15.4幀中傳輸時(shí)，需要對負(fù)載報(bào)文進(jìn)行適配層分片。此時(shí)，適配層幀使用4字節(jié)的分片頭部格式而不是2字節(jié)的不分片頭部格式。另外，適配層需要維護(hù)當(dāng)前的fragment_tag值并在節(jié)點(diǎn)初始化時(shí)將其置為一個隨機(jī)值。1) 分片當(dāng)上層下傳一個超過適配層最大payload長度的報(bào)文給適配層后，適配層需要對該IP報(bào)文分片進(jìn)行發(fā)送。適配層分片的判斷條件為：負(fù)載報(bào)文長度+不分片頭部長+Mesh Delivery(或Broadcast)字段長度 IEEE 802.15.4 MAC層的最大payload長度。在使用16-bits短地址并且不使用IEEE 802.15.4安全機(jī)制的情況下，負(fù)載報(bào)文的最大長度為95(127-25(MAC頭部)-2(不分片頭部)-5（MD的長度）)字節(jié)。適配層分片的具體過程如下所示：對于第一個分片：l 將分片頭部的LF字段設(shè)置為01表示是第一個分片。l Prot_type字段置為上層協(xié)議的類型。若是IPv6協(xié)議該字段置為1。另外，由于是第一個分片，offset必定為0，所以在在該分片中不需要fragment_offset字段。l 用當(dāng)前維護(hù)的datagram_tag值來設(shè)置datagram_tag字段；datagram_size字段填寫原始負(fù)載報(bào)文的總長度。l 若需要在Mesh網(wǎng)絡(luò)中路由，Mesh Delivery字段應(yīng)該緊隨在分片頭部之后并在負(fù)載報(bào)文小分片之前。對于后繼分片：l 分片頭部的LF字段設(shè)置為11或10，表示中間分片或最后一分片。l fragment_offset 字段則設(shè)置為當(dāng)前報(bào)文小分片相對于原負(fù)載報(bào)文起始字節(jié)的偏移，需要注意的是這里的偏移是以8字節(jié)為單位的，因此每個分片的最大負(fù)載報(bào)文小分片長度也必須是8字節(jié)邊界對齊的，也就是說負(fù)載報(bào)文小分片的最大長度實(shí)際上只有88字節(jié)。當(dāng)一個被分片報(bào)文的所有小分片都發(fā)送完成后datagram_tag加，當(dāng)該值超過511后應(yīng)該翻轉(zhuǎn)為0。對于適配層廣播幀，由于節(jié)點(diǎn)能量和資源方面的限制，對于一個較大的負(fù)載報(bào)文的多個分片的廣播給整個LowPAN網(wǎng)絡(luò)帶來嚴(yán)重的負(fù)擔(dān)。因此，適配層可以選擇禁止對需要進(jìn)行適配層廣播報(bào)文(如IPv6組播報(bào)文)進(jìn)行分片操作，適配層將丟棄超過其最大payload長度并且需要進(jìn)行廣播的負(fù)載報(bào)文。2) 重組當(dāng)適配層收到一個分片后，根據(jù)以下兩個字段判斷該分片是屬于哪個負(fù)載報(bào)文的：l 源MAC地址l 適配層分片頭部的datagram_tag字段對于同一個負(fù)載報(bào)文的多個分片，適配層使用如下算法進(jìn)行重組，其重組過程如下所示。a. 如果是第一次收到某負(fù)載報(bào)文的分片，節(jié)點(diǎn)記錄下該被分片的源MAC地址和datagram_tag字段以供后繼重組使用。需要注意的是，這里的源MAC地址應(yīng)該是適配層分片幀源發(fā)地址，若分片幀有Mesh Delivery字段的話，源MAC地址應(yīng)該是Mesh Delivery字段中的Originator Address字段。b. 若已經(jīng)收到該報(bào)文的其它分片，則根據(jù)當(dāng)前分片幀的fragment_offset字段進(jìn)行重組。若發(fā)現(xiàn)收到的是一個重復(fù)但不重疊的分片，應(yīng)該使用新收到的分片進(jìn)行替換。若本分片和前后分片有重疊，則應(yīng)該丟棄當(dāng)前分片，這樣的目的主要是簡化處理，認(rèn)為若出現(xiàn)這種情況一定是發(fā)送方出現(xiàn)了錯誤，不應(yīng)該繼續(xù)接收。c. 若成功收到所有分片，將所有分片按offset進(jìn)行重組，并將重組好的原始負(fù)載報(bào)文遞交給上層。同時(shí)，還需要刪除在步驟(a)中記錄源MAC地址和datagram_tag字段信息。重組一個分片的負(fù)載報(bào)文時(shí)需要使用一個重組隊(duì)列來維護(hù)已經(jīng)收到的分片以及其他一些信息(源MAC地址和datagram_tag字段)。同時(shí)，為了避免長時(shí)間等待未達(dá)到的分片，節(jié)點(diǎn)還應(yīng)該在收到第一個分片后啟動一個重組定時(shí)器，重組超時(shí)時(shí)間為15s，定時(shí)器超時(shí)后節(jié)點(diǎn)應(yīng)該刪除該重組隊(duì)列中的所有分片及相關(guān)信息。3. 組播支持IPv6組播對IPv6協(xié)議特別是鄰居發(fā)現(xiàn)協(xié)議有非常重要的作用。此外，WSN的一些應(yīng)用也需要MAC層的廣播功能。然而，IEEE 802.15.4 MAC層不支持組播僅提供有限的廣播功能，這就需要適配層利用受控廣播泛洪的方式來在整個LowPAN網(wǎng)絡(luò)中傳播IPv6組播報(bào)文。1） 適配層廣播幀6LowPAN使用適配層廣播幀來封裝IPv6組播報(bào)文或其它廣播負(fù)載，格式如下所示。在適配層廣播幀中，適配層頭部的B字段需要被置為1，并在適配層頭部后添加一個Broadcast字段。其中Broadcast字段的S標(biāo)志位指出Source Address字段使用的是EUI-64地址還是16-bits短地址，Broadcast Radius字段設(shè)置為本網(wǎng)絡(luò)指定的最大廣播跳數(shù)，Sequence Number字段設(shè)置為節(jié)點(diǎn)當(dāng)前的廣播序號計(jì)數(shù)值，Source Address設(shè)置為本源節(jié)點(diǎn)的MAC地址，負(fù)載報(bào)文將緊隨在Broadcast字段之后。2） 受控廣播泛洪算法在介紹受控廣播泛洪算法之前，需要先給出6LowPAN邏輯節(jié)點(diǎn)的概念。運(yùn)行IEEE 802.15.4 MAC協(xié)議的無線節(jié)點(diǎn)可以從硬件功能上分成全功能節(jié)點(diǎn)FFD(Full Function Device)和部分功能節(jié)點(diǎn)RFD(Reduce Function Device)兩類。為了從邏輯上劃分各節(jié)點(diǎn)的不同協(xié)議行為，在適配層上將節(jié)點(diǎn)分為PAN Coordinator、Common Coordinator以及End Device三類邏輯節(jié)點(diǎn)。l PANCoordinator：只能是全功能節(jié)點(diǎn)（FFD），在硬件上有著較為豐富的資源，可以承擔(dān)較為復(fù)雜的任務(wù)，是整個LowPAN網(wǎng)絡(luò)的根節(jié)點(diǎn)。l Common Coordinator：也只能是全功能節(jié)點(diǎn)(FFD),同PAN Coordinator相似，有著較為豐富的資源，可作為PAN內(nèi)部在MAC層上的路由器，為其鄰居節(jié)點(diǎn)轉(zhuǎn)發(fā)數(shù)據(jù)。l EndDevice：可以使用全功能節(jié)點(diǎn)(FFD)也可以使用部分功能節(jié)點(diǎn)(RFD)，但是一般考慮到End Device節(jié)點(diǎn)通常不需要太多的計(jì)算資源，因此通常從節(jié)點(diǎn)能耗方面考慮采用部分功能節(jié)點(diǎn)(RFD)。適配層使用的受控廣播泛洪算法來發(fā)送適配層廣播幀，其算法描述如下：源發(fā)節(jié)點(diǎn)或者中繼節(jié)點(diǎn)轉(zhuǎn)發(fā)適配層廣播幀時(shí)，應(yīng)該首先檢查其適配層鄰居緩存，并根據(jù)鄰居緩存信息處理：（1） 若該節(jié)點(diǎn)的所有鄰居均為PAN Coordinator或者Common Coordinator，且均為該節(jié)點(diǎn)的子節(jié)點(diǎn)時(shí)，直接用IEEE 802.15.4 MAC層廣播該適配層廣播幀。特別的，若只有一個PAN Coordinator或者Common Coordinator的鄰居且其為適配層廣播幀的入口節(jié)點(diǎn)，不斷轉(zhuǎn)發(fā)適配層廣播幀。（2） 若該節(jié)點(diǎn)的部分鄰居為End Device或者為該節(jié)點(diǎn)的父節(jié)點(diǎn)，并且不為適配層廣播幀的入口節(jié)點(diǎn)時(shí)，除了執(zhí)行(1)中的IEEE 802.15.4 MAC層廣播以外，還要通過IEEE 802.15.4 MAC層廣單播向該鄰居發(fā)送該幀。（3） 若該節(jié)點(diǎn)的鄰居均為End Device或該節(jié)點(diǎn)的父節(jié)點(diǎn)，并且不為適配層廣播幀的入口節(jié)點(diǎn)時(shí)，只通過IEEE 802.15.4 MAC層單播向其每個鄰居發(fā)送該幀。下圖即為使用受控廣播泛洪算法時(shí)適配層廣播幀在LowPAN網(wǎng)絡(luò)中的傳播過程。需要注意的是該過程需要和廣播風(fēng)暴控制配合使用才能完成。圖 受控廣播泛洪（1）圖 受控廣播泛洪（2）3） 廣播風(fēng)暴控制6LowPAN使用受控廣播泛洪算法可以大大減少需要發(fā)送的適配層廣播幀數(shù)量，但是若使用Mesh拓?fù)鋾r(shí)，整個LowPAN網(wǎng)絡(luò)拓?fù)渲袝嬖诖罅凯h(huán)路。在這種存在環(huán)路的網(wǎng)絡(luò)中，中繼節(jié)點(diǎn)對廣播幀的重復(fù)轉(zhuǎn)發(fā)將會造成嚴(yán)重的廣播風(fēng)暴。為了避免廣播風(fēng)暴，每個節(jié)點(diǎn)需要記錄已經(jīng)轉(zhuǎn)發(fā)過和適配層廣播幀。具體做法是節(jié)點(diǎn)維護(hù)一張廣播記錄表(BRT)，每張廣播記錄表中有若干個廣播記錄項(xiàng)(BRE)，每個廣播記錄項(xiàng)至少有Source Address、Sequence Number和Broadcast Valid Time(廣播有效時(shí)間，BVT)三個字段，廣播記錄表的結(jié)構(gòu)如下圖所示。圖 廣播記錄表(BRT)當(dāng)節(jié)點(diǎn)收到一個適配層廣播幀后，首先檢查Broadcast字段中的Source Address：l 若是本地節(jié)點(diǎn)地址，直接丟棄；l 若不是本地節(jié)點(diǎn)，根據(jù)Broadcast字段中的Source Address和Sequence Number來檢查本節(jié)點(diǎn)維護(hù)的BRT：n 若在BRT中找到匹配并且BVT不為0的BRE，則認(rèn)為該幀已經(jīng)被本地節(jié)點(diǎn)收到或者轉(zhuǎn)發(fā)過，丟棄該廣播幀；n 若沒有找到，則認(rèn)為是第一次收到該廣播幀。節(jié)點(diǎn)需要為其新建一個BRE(源發(fā)節(jié)點(diǎn)發(fā)送適配層廣播幀時(shí)不需要在BRT中添加一個新的BRE)，并根據(jù)Broadcast字段初始化BRE的Source Address和Sequence Number兩個字段，Broadcast Valid Time設(shè)置為本網(wǎng)絡(luò)指定的廣播有效時(shí)間值。同時(shí)，將Broadcast字段中的Broadcast Radius減1，若該值減到0則停止轉(zhuǎn)發(fā)，否則使用受控廣播泛洪算法繼續(xù)轉(zhuǎn)發(fā)該廣播幀。最后，將新收到的適配層廣播幀遞交給上層是。特別的，對于End Device，可以選擇不對收到的廣播幀進(jìn)行轉(zhuǎn)發(fā)。每個BRE中有一個Broadcast Valid Time字段，該值表示現(xiàn)一個適配層廣播幀在網(wǎng)絡(luò)中傳播的有效時(shí)間。協(xié)議棧定時(shí)減小該值，若該值減小到0，則認(rèn)為適配層廣播幀已經(jīng)過期并刪除對應(yīng)的BRE。若此后再收到Source Address和Sequence Number均相同的廣播幀，節(jié)點(diǎn)將不再認(rèn)為是重復(fù)的適配層廣播幀，仍然需要為其新建BRE并進(jìn)行比較。4. 頭部壓縮格式由于LowPAN網(wǎng)絡(luò)的特性，在實(shí)現(xiàn)IPv6在IEEE 802.15.4上的頭部壓縮時(shí)應(yīng)當(dāng)考慮最少的預(yù)建上下文需求，也要求壓縮方案盡量的簡單直接。目前適配層支持3種壓縮格式，分別是LOWPAN_HC1格式，用于IPv6頭部壓縮；HC_UDP格式，用于UDP頭部壓縮;HC_ICMP壓縮格式，用于ICMPv6壓縮。在對IPv6、UDP以及ICMP進(jìn)行壓縮時(shí)需要使用這3種特定的壓縮格式以及編碼字段，同時(shí)，適配層頭部的prot_type字段應(yīng)該設(shè)置為2，表示適配層頭部后出現(xiàn)的是HC1編碼字段。1） LOWPAN_HC1格式LOWPAN_HC1格式使用8-bits的HC1編碼字段來對IPv6頭部進(jìn)行編碼，其具體形式如下圖所示。由于IPv6頭部中源地址和目的地址占了很大的空間，所以需要對地址域?qū)ｉT進(jìn)行編碼。IPv6地址由前綴和接口標(biāo)識兩部分組成，如果是Link-local地址的話，則前綴默認(rèn)是FE80:/64并可以在頭部中省去；而對于接口標(biāo)識來說，由于IID是從MAC地址生成的，所以可以從IEEE 802.15.4MAC幀頭部或者M(jìn)eshDelivery字段中的源、目的地址重新組成IID，因此在這種情況下接口標(biāo)識也是可以省去的。這樣，就有如下四種可能的地址字段編碼方式：PI：前綴在鏈路上傳輸(in-line)PC：前綴被壓縮(默認(rèn)是link_local前綴)II：接口標(biāo)識符在鏈路上傳輸(in-line)IC：接口標(biāo)識符被壓縮(從相應(yīng)的鏈路層地址獲得)對于IPv6頭部的非壓縮字段，將出現(xiàn)在HC1，編碼字段 (可能包括后繼的HC2編碼字段)之后，首先是不被壓縮的Hop Limit代字段，其它的未被壓縮字段按HC1，編碼字段中的順序出現(xiàn)。各個非壓縮字段的出現(xiàn)順序如下:Hop Limit(8 bits)、Source Address Prefix(64bts) 節(jié)and/or Interface Identifier(64 bits)、Destination Address Prefix(64 bits) and/or Interface Identifier(64 bits)、Version(4 bits)、TrafficClass(8 bits)、Flow Label(20 bits)、Next Header(8 bits)。2） HC_UDPHC_UDP格式使用 8 bits的HC_UDP編碼字段來對UDP頭部進(jìn)行編碼，其具體格式如下圖所示。HC_UDP編碼字段的具體格式如下：l UDPSourcePort(bit 0)0:不