關于丟包的問題

無線通信最常見的問題就是丟包，無論是簡單原始的433MHz通信，還是高精尖的5G信號，都會有丟包問題。解決丟包問題也是無線工程師的必要工作，丟包不可避免，但是遇到丟包了應該怎么辦才是本文要談的。無線通信最重要的就是設計一套能夠解決應用需求的通信協議，而通信協議包含這些要素：無線信號使用什么頻段、什么調制方式不被干擾、無線信號發給誰、如何保證無線信號送達目標、多個相同的設備同時使用該怎么辦、接收端如何判斷收到的信號是否重復收或漏收……其實這些都是圍繞解決一個問題——丟包。

所以任何一種普遍使用的無線通信協議，都要分成若干邏輯層，每一個邏輯層。例如常見的Wi-Fi、ZigBee、藍牙，它們都具備兩個共同的邏輯層——PHY物理層，MAC鏈路層。其中PHY層定義了頻段、調制方式以及傳輸方式。MAC層則定義了誰來發信號，誰來收信號，什么時候發信號。基本的PHY層和MAC層解決了常見的物理丟包問題，但是無線設備的應用場景十分復雜，因此各種通信協議之上還增加了諸如網絡層這些邏輯層用于保證通信的穩定性，如Wi-Fi協議上 的TCP協議就是為了保證傳輸穩定而設計的。例如ZigBee的PHY層和MAC層就為了減少丟包做了一些處理機制。

減少丟包處理機制

①PHY層的減少丟包機制：
物理層的丟包，就是發送端發送了信號，但是接收端沒有接收到信號。這也是最簡單也是最常見的原因，通常就是發射端的功率低了，發射端距離接收端太遠。遇到這種情況，通常會想到的辦法就是提高發射功率，信號能發射得更遠。但是根據香農定律，在相同信道帶寬下，信號攜帶的信息量越少，對信噪比的需求越低，對信噪比需求越低就意味著對功率的需求越低。這時除了提高功率，還有一種方式就是擴頻。比如典型的ZigBee上使用的DSSS擴頻，原本ZigBee的信道帶寬有2MHz，也就是能在1秒鐘內輸出2M個0或1的信號。通常我們使用8個0或1的信號表示一個字節，但是DSSS的作用下，需要64個0或1的信號來表示一個字節。這樣使用無線信號傳輸一個字節需要64個0或1，即使信號在傳輸過程中發生了失真，接收端也能對信號進行糾錯。這也就是為什么ZigBee的傳輸穩定性優于433MHz通信。正常情況下，ZigBee在20dBm發射功率的情況下，傳輸距離可達1公里。還有一種情況，就是天線的問題。任何一種天線都有天線增益系數以及方向性。通常外置天線的增益就優于PCB天線，在設備空間充足的情況下盡量選擇外置天線。而天線的方向性也是要考慮的因素，例如棒狀天線的信號覆蓋范圍就是一個扁球體，平行天線的位置信號非常好，而天線軸線延長線位置信號差得多。
②MAC層減少丟包的機制：以ZigBee的IEEE802.15.4系列協議為例，該協議的MAC層具有一下幾個重要的功能。載波偵聽和CSMA機制：IEEE802.15.4具備基于載波偵聽的CSMA機制。設備在每次發射信號前，會偵聽當前信道是否繁忙，并在信道空閑的時候發射信號。很多sub-G芯片也帶有載波偵聽功能的，但是缺少類似CSMA這樣的協議機制。CSMA則規定了信道偵聽的方法：發射前在一個隨機時間內持續偵聽信道，這樣就能適當避免兩個相同的設備同時發射信號；隨機時間到達后嘗試發送信號，如果發送失敗就再偵聽一次，并且下一次隨機時間范圍繼續擴大（2倍），這樣就能避免更多的設備同時發射信號；如果多次嘗試都失敗，而且達到了最大次數限制，那么這個信號就算丟包了。自動應答機制：IEEE802.15.4-MAC層有兩種主要通信方式：廣播和點播。點播到目標時，目標節點會返回ACK幀。發送端沒有收到ACK幀，會嘗試重傳信號，如果多次重傳都沒收到ACK就算丟包。另外接收端回復MAC-ACK的時候是不受CSMA機制可以強行發送的，發送端在CSMA機制下成功將點播信號送出去后，只需要0.2~0.5毫秒就能收到ACK。

因此，導致MAC層丟包常見的現象就是CSMA失敗丟包和MAC-ACK失敗丟包，和物理層的丟包不同的是這兩種丟包都可以被發送端自己檢測到。通常遇到這種丟包，應用上的處理就是重傳。但是重傳也是要講究科學性的，比如惡意信號干擾導致CSMA失敗重傳就沒法解決；接收目標不存在導致的 MAC-ACK失敗重傳也是沒法解決的。PHY層和MAC層的一系列處理機制都是為了減少丟包而設計的，但是無法保證絕對沒有丟包，因此無線應用設計中，最關鍵的就是遇到丟包了該怎么辦。

無線應用中丟包解決方法

以ZigBee傳輸為例，PHY層、MAC層、NWK層做了很多處理機制，丟包率幾乎達到0.1%~0.01%。但是如果應用設計沒考慮到僅剩的0.1%~0.01%丟包問題，對應用自身的影響就是致命的。在應用中常見的對丟包的容錯，有如下解決辦法。①合理重傳：重傳是大家都能想到的方法，ZigBee就提供了CSMA失敗檢測和ACK失敗檢測。通常遇到以上兩種情況大家的常見做法就是數據重傳。但是重傳也要講究合理性，例如CSMA失敗，這個時候有可能是很多個節點同時在發射信號；例如設備上電的時候會把上電時的信息上報給網關，多個設備一起上電肯定會有很大的沖突率，CSMA失敗是很常見的事。因此，這時候遇到CSMA失敗不要立即重傳，可以隨機延時100毫秒~1秒再重傳，如果再次失敗說明同時傳輸的設備確實太多，再隨機延時2~4秒，失敗再隨機延時4~8秒……。如果是ACK失敗則可以根據該次發射數據的實時性，延遲一個固定時間再重傳，一般在1秒以上5秒以下，因為有可能上次傳輸失敗是目標節點“不在狀態”，下次傳輸可能就自動好了。②設計時序規則：應用數據傳輸時需要考慮出現丟包時該如何處理，例如OTA升級，文件傳輸。每一幀數據都是必不可少的，而且順序還要正確。所以這類無線傳輸應用中，應該對每一幀數據包都標注上序號。發送端一旦檢測到丟包，可能會重傳數據幀。而接收端有可能是因為ACK沒有發送到發送端導致發送端誤判。如果接收端收到多一幀或少一幀數據，都可以從每一幀的序號判斷出來。③該放棄時要放棄：類似接收端不存在，或者信道遇到干擾的問題，通過MAC層都可以偵測到。例如出現連續長時間的ACK失敗，可能就是接收端不存在；連續長時間的CSMA失敗，可能就是遇到了干擾。接收端不存在的情況下完全可以放棄對這個接收端發送消息。信道被干擾的情況下可以做整體信道切換，也可以暫停全網絡的運行，保存當前狀態，等待干擾消失后再恢復全部的傳輸。

不算丟包的“丟包”

無線通信上除了無線信號導致的丟包，還有軟件邏輯上的丟包。典型的就是通信的數據量超過了發送端或接收端的處理能力。比如ZigBee的傳輸速率只有250kbps，加上CSMA延遲，路由轉發，實際數據傳輸速率能夠達到5kbps~10kbps就很不錯了。發射端的應用程序如果向發射端寫入數據的速度超過了發射端的傳輸速度，也會導致軟件丟包。通常各家芯片廠商的IEEE802.15.4的協議棧都會提供一個Send Confirm的回調接口，應用程序向傳輸接口寫入需要傳輸的消息后，約在幾毫秒到幾十毫秒內收到Send Confirm回調觸發。同時一般射頻芯片SoC也會提供緩存來存儲寫入的數據幀，有可能應用程序一次向射頻芯片寫入多個數據幀都被芯片SOC緩存起來，再慢慢的一幀一幀發射出去，然后Send Confirm回調被陸陸續續地觸發。如果應用程序在發送消息的時候，每次向射頻SoC寫入傳輸消息，待Send Confirm觸發后再寫入下一條消息，就可以很好地規避軟件丟包的問題。

對于接收端也是如此，多個發送端向同一個接收端發送消息，CSMA很好的規避了沖突，發送端收到了各自的ACK，但是發送端發送的消息在接收端沒有得到正確的響應。那么就有可能是接收端的處理能力有限，各個發送端累計發送的消息全部堆在接收端正在處理，這種情況就要考慮系統設計問題，減少接收端的處理壓力。

總結

對于丟包的容錯處理是無線通信設計的關鍵，現有成熟的通信協議雖然做了很多措施來降低丟包率，如果丟包一旦發生一定要有容錯機制來應對，否則就算是千分之一或萬分之一的丟包，都會為整個無線系統帶來災難性的后果。