6LowPAN的適配層

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