動態虛擬映射方法在提高SCHC機制壓縮效率中的應用

朱 博，雙 煒，喻竹希，王 璇，呂佳歡

(航天行云科技有限公司，湖北 武漢 430048)

0 引言

低功耗廣域網是一種資源受限型網絡，其主要特點包括低速率、低功耗和海量連接[1]。較長的數據報頭會對傳輸效率造成不可忽略的影響，如果使用IPv6作為網絡層協議，雖然在地址空間分配和組網效率方面比IPv4有了大幅度的提升，但是IPv6長達40字節的報頭對于物聯網應用而言顯得過于冗長，從而使得該協議的實際效率低下[2]。IEEE802.15.4曾經嘗試使用IPv6作為網絡層協議，稱之為6LoWPAN(IPv6 over LPWPAN)適配層[3]。相比于IEEE802.15.4而言，LPWAN受到的限制更多，所以6LoWPAN無法直接用于LPWAN。為此，IETF成立了LPWAN工作組，提出了靜態上下文報頭壓縮(Static Context Header Compression，SCHC)機制[4]，這種機制利用了LPWAN網絡拓撲簡單、易于建立靜態的上下文關系等特點，很好地解決了長報頭壓縮和數據分段傳輸等問題。

物聯網發展的最終愿景是與Internet進行無縫連接，尤其是在IPv6普及之后，每個終端都可擁有全網唯一的IP地址，LPWAN終端可隨時被Internet上任意一臺應用服務器直接訪問[5]。因此從網關→終端的下行流量將無法事先預知，從而難以維持網關與終端間的靜態上下文關系。

本文提出了一種可提高未知流量報頭壓縮成功率的方法，稱為動態虛擬映射(Dynamic Virtual Mapping，DVM)，該方法的設計思想是利用可重用的DVM單元來封裝流量報頭中的未知字段，通過屏蔽掉未知流量動態性的方式提高SCHC的壓縮效率。因此，本方法實現了一種動態的上下文構建機制，能夠減少網關和LPWAN終端之間的同步次數，從而提高SCHC的壓縮成功率并降低網絡資源的消耗。

1 LPWAN中的SCHC機制

支持SCHC機制的LPWAN網絡架構如圖1所示，它提供了LPWAN終端與應用服務器之間的雙向連接，網關在轉發數據包到LPWAN網絡之前先使用網關側壓縮/解壓縮(Compress/Decompress，SCHC C/D)操作對報頭進行壓縮，同樣，在終端側壓縮后發送的數據包也需要在網關處進行解壓處理，恢復出原始數據報頭后再轉發給服務器。

圖1 支持SCHC的LPWAN網絡架構

SCHC中的上下文信息由一些包含字段描述和壓縮/解壓縮操作的規則項組成。本地規則庫中每一條規則都由對應的標識號(Rules ID)表示，SCHC壓縮規則中字段的定義如表1所示。

表1 SCHC壓縮規則

SCHC處理數據包時首先在本地規則庫中通過輪詢方式選中匹配項最多的一條規則，然后將當前字段值與對應的目標值進行匹配運算，如果所有字段都滿足匹配規則，則根據對應的C/D操作進行處理，產生一個壓縮報頭，否則繼續檢測下一條規則。如果同時有多條規則與報頭字段匹配，則選擇開銷最小的那一條。壓縮完成后，按照規則ID、壓縮殘留信息(未能完全匹配的字段)、Payload(有效負載)的順序重新封裝數據包。在接收端，解壓縮器首先通過查看規則ID來識別壓縮數據包中使用的規則。然后在規則庫中查找，并根據對應的C/D操作來解壓縮，恢復出原始報頭后進行下一步處理。

圖2 DVM映射方法解壓縮流程

2 DVM動態虛擬映射方法

DVM(動態虛擬映射)方法是在SCHC基礎之上進行的擴展，使用一組可復用的DVM單元來存儲SCHC機制無法識別的報頭字段，例如那些無法找到可匹配壓縮規則的字段或隨時間而變的字段。從而提高SCHC的壓縮效率。該方法的使用需滿足3個條件：(1)報頭中存在某些終端不關心其取值(可忽略)的字段。(2)在交互過程中字段的值始終不變(比如請求標志符)。(3)在DVM單元的生存時間內，報頭字段的實際值與DVM單元中的值所建立的映射始終有效。

DVM方法在SCHC的基礎上增加了一種稱為DVM的匹配運算符(Matching Operator)。并在目標值字段(Target Value)中添加了一組DVM單元列表，[(DVM1),(DVM2)……]，列表中的單元包含3部分：(1)DVM索引值。DVM單元的唯一ID，可自定義；(2)實際值。待壓縮字段的實際值；(3)DVM單元的生存時間(TTL)。該值非零時，DVM單元表示被占用，TTL到期后對應單元將被釋放。DVM索引值不隨時間而變，而其實際值和生存時間則會在執行過程中被更新。

DVM方法的執行流程如圖2所示，首先判斷數據的流向，即在進行匹配操作時判斷是否應該在網關側(見圖3)或終端側(見圖4)執行相應操作。如果壓縮操作在網關側已經完成，則判斷是否報頭字段已經與某個DVM值建立了映射關系，如果這個報頭字段值已經存在，表示DVM操作已對此報頭生效。如果該報頭字段不存在，壓縮器會將這個值映射到列表中第一個空閑的DVM單元里或者已經過期失效的單元中。如果報頭字段匹配成功，則與SCHC機制一樣，執行規則中對應的C/D操作進行壓縮。如果DVM列表中存在多個可用單元，則C/D Action的選項中應該使用mapping-sent(TTL)，同時壓縮器發送用于與報頭字段建立映射關系的DVM索引值，索引值的編碼取決于DVM映射表中的單元總數。TTL值表示該DVM單元的最大生存時間，如果列表中僅有一個DVM映射單元，那么C/D Action選項應該使用not-sent(TTL)，此時壓縮器不會發送任何內容。

DVM方法的解壓縮流程如圖2所示，首先，需要從DVM列表中恢復出使用過的DVM單元，可依據索引值的發送順序來確定，除非這是列表中的唯一的DVM單元。如果解壓縮需要在網關側完成，則解壓縮器使用該單元對應的真實值來還原報頭，如果在終端側執行解壓縮，報頭字段則使用相應的DVM值進行重構即可，同時更新其生存時間。

圖3 網關側發起的DVM壓縮流程

圖4 終端側發起的DVM壓縮流程

由此可見，DVM值與真實值之間的映射關系在網關側表現出了動態性，終端在處理時并不需要知道其真實值。基于此特點，DVM映射技術并不適用于處理那些必須在終端側完整恢復的字段(比如IPv6的目的地址)，更適合于那些取值對于終端而言可忽略的報頭字段。

3 實驗與性能評估

3.1 場景介紹

本文以一臺LoRaWAN終端使用CoAP[6]向Internet上一臺應用服務器發起請求并接收應答消息的過程為實驗場景。由于終端請求的服務器地址沒有存儲在本地規則庫中，因此服務器返回的應答消息沒有與終端事先建立起靜態的上下文關系，此時便可使用DVM方法來進行壓縮處理。

存儲在本地的SCHC壓縮規則庫如表2所示，其包含了完整的網絡層、傳輸層和應用層。在本示例中，終端的IPv6前綴(IPv6DEVprefix)是alpha::/64，設備ID部分(IPv6DEViid)可以依據其MAC地址而定。終端中CoAP運行在UDP5678端口。CoAP的指令碼為(0.02)和(0.00)。此外，因為解壓縮器可重新計算UDP長度(UDPLength)和校驗(UDPchksum)，所以它們的取值可以忽略。

本場景下的DVM映射方法可用于IPv6地址的前綴部分(IPv6APPprefix)以及它的ID部分(IPv6APPid)、UDP報頭中的端口號(UDPAPPort)以及CoAP報頭中的消息ID段(CoAPMID)。因為這些字段的值會在不同流量中發生變化，原生SCHC機制無法處理。此外，這些值對于終端而言可忽略，但是在終端和網關之間傳輸時保持不變。因此，這些字段非常適合使用DVM方法進行壓縮。如表2所示，規則庫在每個DVM列表中定義了兩個DVM單元(DVM1，DVM2)，此時每個列表中的DVM值必須是唯一的，并使用一個比特來標識單元是否被占用。本場景中的TTL值被設置為20(s)，使用以上配置，本規則庫已經可以滿足實驗場景的需求。

3.2 評價模型

筆者以報文壓縮率來衡量DVM方法的執行效率，為此構建分析和評價模型。在該模型中，DVM方法在執行操作時，TTL值需要滿足公式(1)的約束。這里的RTTL表示網關側到終端側的最長往返時間。

表2 DVM方法的壓縮規則庫

滿足公式(1)可以確保使用的DVM單元在生存時間內，網關側有足夠的時間接收到響應報文。在理想的信道環境下，RTTL被定義為將要發送的最長請求消息所需的時間TLreq與將要被接收的最長響應消息所需的時間TLres之和。同時，還需要考慮真實信道環境中可能引起消息的重傳，因此，公式(1)中RTTL在計算時考慮了最大的MAC層重傳次數Rmax，這就意味著任何的傳輸在被有效接收前都需要傳輸最多Rmax次，我們可依據該原則設置TTL的初始值。

TTL≥RTTL

(1)

RTTL=Rmax(TLreq+TLres)+TLpre

本實驗以M/D/N隊列[7]的形式為DVM映射列表進行建模，在這種排隊模型中，到達網關側的請求消息分布服從泊松過程，到達速率λ和平均間隔時間為1/λ，服務接收率μ=1/TTL。N表示DVM列表中參與壓縮操作的單元數量。公式(2)表示新請求達到時，所有DVM單元都不可用的概率。相應的[1-P(ρ,N)]表示新到來的請求消息中發現有一個單元可用的概率。依據給定的N和λ，計算P(ρ,N)便得出能夠被DVM壓縮的概率，計算方法如公式(2)所示，對公式(2)進行化簡并令初始值P(ρ,0)=1后得到公式(3)。

(2)

(3)

我們使用可壓縮率CRDVM來評價DVM方法的處理效率，其被定義未壓縮流量與已壓縮流量的比值。因此，對于一個長度為FL的報頭字段，如果在使用DVM方法的情況下，可使用公式(4)來計算其壓縮率。

(4)

3.3 實驗結果分析

如表3所示，LoRAWAN支持7擋速率的自適應功能，此外還為每種不同速率指定了最大MAC幀長。為便于設置TTL的值，這里使用最大幀長和最大重傳次數Rmax=3來計算最差情況下的RTTL。在本場景中，可認為響應報文發出時的TLpre=0。根據公式(1)可知，RTTL等于使用最低速率傳輸最大幀長所需的時間TLreq加上使用當前設備使用比特率發送最大幀長時所需的傳輸時間TLres之和的3倍。我們使用Semtech官方提供的計算工具[8]得出了不同Rb下對應的RTTL值(如表3所示)，可以根據這些值來設置合適的TTL值以滿足公式(1)的約束條件。

表3 LoRaWAN傳輸速率

本實驗的仿真結果表明如果不使用DVM方法，根據公式(4)計算得出請求消息和響應消息的壓縮率分別是3.85和4。在使用DVM方法時，當列表中存在1個、2個、4個和8個空閑單元可用時，請求和響應消息的壓縮率變化曲線如圖5所示。其中對于每個不同的N值，隨著請求消息到達速率λ的增加，4種情況下的壓縮率均表現為從最高值逐漸降低到最低值。當P(ρ,n)=0(表明請求消息總是能找到至少一個可用的DVM單元)和當P(ρ,N)增加時壓縮率降低到最小值。當P(ρ,n)=1時就意味著報頭字段沒有被執行壓縮。如圖4所示，壓縮率會隨著N的增加而減少，這是因為用于對N進行編碼所需要的比特位在增加，從而降低了壓縮率。需要注意的是，最好將N的取值設置為2的整數次冪，假如設置N=3，則會與取N=4時得到相同的壓縮率，而N=4時可在更高的請求速率下維持更高的壓縮率。綜上所述，在相同的請求速率下，更小的TTL值可以得到更高的壓縮率，主要因為減少TTL的同時增加了找到生存時間到期的DVM單元的概率。

圖4 不同配置下的壓縮效率對比

目前LoRAWAN網絡只能運行在非授權ISM頻段上，其發送占空比通常會被限制在一個很低的值[9-10]，比如歐洲要求在863～870 MHz頻段內發送占空比僅為1%。在這種低占空比的情況下，LoRAWAN應用的平均請求到達時間通常在數十分鐘以上。因此，如果能實現如圖4所示的壓縮率，對于LoRAWAN應用來說已經足夠。在N=1時兩次請求和響應的平均時間間隔分別為27和52 min。意味著在本場景下，相比于原生SCHC，DVM方法的請求和響應消息壓縮率分別提高了600%和1 200%，這對于網絡資源和設備功耗的控制都是非常有利的，同時也反映出DVM方法在壓縮效率方面具有明顯的優勢。

4 結語

在LPWAN與Internet深度融合的長期愿景下，隨著IPv6的普及以及終端移動性需求的增加，SCHC機制所倡導的靜態上下文關系變得越來越難以維護，針對一些無法建立穩定上下文關系的場景，如何有效地提高報頭壓縮效率是值得研究的問題。本文在原生SCHC的基礎上進行改進，提出了動態虛擬映射方法。該方法使用一組固定大小的DVM存儲單元，將一些無法處理的字段動態的映射到這些單元中，并在SCHC添加對應的處理規則，同時建立復用方式。該方法相比于SCHC建立了一種動態的上下文映射機制，避免由于上下文關系發生變化而導致終端與網關之間的重新同步。實驗證明本方法在適用條件滿足時，相比于SCHC能夠大幅度提高報頭的壓縮效率，同時縮短響應時間。