一、關于丢包的問題
無線通信最常見的問題就是丢包，無論是簡單原始的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，但是發送端發送的消息在接收端沒有得到正确的響應。那麼就有可能是接收端的處理能力有限，各個發送端累計發送的消息全部堆在接收端正在處理，這種情況就要考慮系統設計問題，減少接收端的處理壓力。
總結
對于丢包的容錯處理是無線通信設計的關鍵，現有成熟的通信協定雖然做了很多措施來降低丢包率，如果丢包一旦發生一定要有容錯機制來應對，否則就算是千分之一或萬分之一的丢包，都會為整個無線系統帶來災難性的後果。