前文講解了是什么是無線通信應用中的網(wǎng)絡丟包率和無線傳輸應用有哪些處理機制減少網(wǎng)絡丟包率？，本文根據(jù)前文整理的文件，整理了以下幾點可以解決無線傳輸中網(wǎng)絡丟包問題的辦法：
以ZigBee傳輸協(xié)議為例，PHY層、MAC層、NWK層做了很多處理機制，網(wǎng)絡丟包率幾乎達到0.1%~0.01%。但是如果應用設計沒考慮到僅剩的0.1%~0.01%丟包問題，對應用自身的影響就是致命的。在物聯(lián)網(wǎng)應用中常見的對無線通信網(wǎng)絡丟包的容錯，有如下解決辦法。
重傳是大家都能想到的方法，ZigBee模塊就提供了CSMA失敗檢測和ACK失敗檢測。通常遇到以上兩種情況大家的常見做法就是數(shù)據(jù)重傳。但是重傳也要講究合理性，例如CSMA失敗，這個時候有可能是很多個節(jié)點同時在發(fā)射信號；例如設備上電的時候會把上電時的信息上報給DTU無線網(wǎng)關設備，多個設備一起上電肯定會有很大的沖突率，CSMA失敗是很常見的事。因此，這時候遇到CSMA失敗不要立即重傳，可以隨機延時100毫秒~1秒再重傳，如果再次失敗說明同時傳輸?shù)脑O備確實太多，再隨機延時2~4秒，失敗再隨機延時4~8秒……。如果是ACK失敗則可以根據(jù)該次發(fā)射數(shù)據(jù)的實時性，延遲一個固定時間再重傳，一般在1秒以上5秒以下，因為有可能上次傳輸失敗是目標節(jié)點“不在狀態(tài)”，下次傳輸可能就自動好了。
應用數(shù)據(jù)無線傳輸時需要考慮出現(xiàn)丟包時該如何處理，例如OTA升級，文件傳輸。每一幀數(shù)據(jù)都是必不可少的，而且順序還要正確。所以這類無線傳輸應用中，應該對每一幀數(shù)據(jù)包都標注上序號。發(fā)送端一旦檢測到丟包，可能會重傳數(shù)據(jù)幀。而接收端有可能是因為ACK沒有發(fā)送到發(fā)送端導致發(fā)送端誤判。如果接收端收到多一幀或少一幀數(shù)據(jù)，都可以從每一幀的序號判斷出來。
類似接收端不存在，或者信道遇到干擾的問題，通過MAC層都可以偵測到。例如出現(xiàn)連續(xù)長時間的ACK失敗，可能就是接收端不存在；連續(xù)長時間的CSMA失敗，可能就是遇到了干擾。接收端不存在的情況下完全可以放棄對這個接收端發(fā)送消息。信道被干擾的情況下可以做整體信道切換，也可以暫停全網(wǎng)絡的運行，保存當前狀態(tài)，等待干擾消失后再恢復全部的傳輸。
無線通信上除了無線信號導致的丟包，還有軟件邏輯上的丟包，所以首選需要了解如何檢測數(shù)據(jù)丟包重傳。典型的就是通信的數(shù)據(jù)量超過了發(fā)送端或接收端的處理能力。比如ZigBee的傳輸速率只有250kbps，加上CSMA延遲，路由轉發(fā)，實際數(shù)據(jù)傳輸速率能夠達到5kbps~10kbps就很不錯了。發(fā)射端的應用程序如果向發(fā)射端寫入數(shù)據(jù)的速度超過了發(fā)射端的傳輸速度，也會導致軟件丟包。
通常各家MCU芯片廠商的IEEE 802.15.4的通信協(xié)議棧都會提供一個Send Confirm的回調接口，應用程序向傳輸接口寫入需要傳輸?shù)南⒑?，約在幾毫秒到幾十毫秒內收到Send Confirm回調觸發(fā)。同時一般射頻芯片SoC也會提供緩存來存儲寫入的數(shù)據(jù)幀，有可能應用程序一次向射頻芯片寫入多個數(shù)據(jù)幀都被芯片SOC緩存起來，再慢慢的一幀一幀發(fā)射出去，然后Send Confirm回調被陸陸續(xù)續(xù)地觸發(fā)。如果應用程序在發(fā)送消息的時候，每次向射頻SoC寫入傳輸消息，待Send Confirm觸發(fā)后再寫入下一條消息，就可以很好地規(guī)避軟件丟包的問題。
對于接收端也是如此，多個發(fā)送端向同一個接收端發(fā)送消息，CSMA很好地規(guī)避了沖突，發(fā)送端收到了各自的ACK，但是發(fā)送端發(fā)送的消息在接收端沒有得到正確的響應。那么就有可能是接收端的處理能力有限，各個發(fā)送端累計發(fā)送的消息全部堆在接收端正在處理，這種情況就要考慮系統(tǒng)設計問題，減少接收端的處理壓力。
相關文章推薦：
什么是網(wǎng)絡丟包和怎么解決無線通信網(wǎng)絡數(shù)據(jù)包丟失？
今天的分享就到這里啦，EBYTE每一天都致力于更好的助力物聯(lián)化、智能化、自動化的發(fā)展，提升資源利用率，更多產品更多資料，感興趣的小伙伴可以登錄我們的億佰特官網(wǎng)進行了解，還有客服小姐姐在線答疑哦！
