0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

丟包問題如何解決?方法在這里

億佰特物聯(lián)網(wǎng)應(yīng)用專家 ? 2022-10-14 10:23 ? 次閱讀

關(guān)于丟包的問題

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

所以任何一種普遍使用的無線通信協(xié)議,都要分成若干邏輯層,每一個邏輯層。例如常見的Wi-Fi、ZigBee、藍(lán)牙,它們都具備兩個共同的邏輯層——PHY物理層,MAC鏈路層。其中PHY層定義了頻段、調(diào)制方式以及傳輸方式。MAC層則定義了誰來發(fā)信號,誰來收信號,什么時候發(fā)信號?;镜腜HY層和MAC層解決了常見的物理丟包問題,但是無線設(shè)備的應(yīng)用場景十分復(fù)雜,因此各種通信協(xié)議之上還增加了諸如網(wǎng)絡(luò)層這些邏輯層用于保證通信的穩(wěn)定性,如Wi-Fi協(xié)議上 的TCP協(xié)議就是為了保證傳輸穩(wěn)定而設(shè)計(jì)的。例如ZigBee的PHY層和MAC層就為了減少丟包做了一些處理機(jī)制。

減少丟包處理機(jī)制

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

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

無線應(yīng)用中丟包解決方法

以ZigBee傳輸為例,PHY層、MAC層、NWK層做了很多處理機(jī)制,丟包率幾乎達(dá)到0.1%~0.01%。但是如果應(yīng)用設(shè)計(jì)沒考慮到僅剩的0.1%~0.01%丟包問題,對應(yīng)用自身的影響就是致命的。在應(yīng)用中常見的對丟包的容錯,有如下解決辦法。4050ae0a-4b31-11ed-b116-dac502259ad0.jpg①合理重傳:重傳是大家都能想到的方法,ZigBee就提供了CSMA失敗檢測和ACK失敗檢測。通常遇到以上兩種情況大家的常見做法就是數(shù)據(jù)重傳。但是重傳也要講究合理性,例如CSMA失敗,這個時候有可能是很多個節(jié)點(diǎn)同時在發(fā)射信號;例如設(shè)備上電的時候會把上電時的信息上報給網(wǎng)關(guān),多個設(shè)備一起上電肯定會有很大的沖突率,CSMA失敗是很常見的事。因此,這時候遇到CSMA失敗不要立即重傳,可以隨機(jī)延時100毫秒~1秒再重傳,如果再次失敗說明同時傳輸?shù)脑O(shè)備確實(shí)太多,再隨機(jī)延時2~4秒,失敗再隨機(jī)延時4~8秒……。如果是ACK失敗則可以根據(jù)該次發(fā)射數(shù)據(jù)的實(shí)時性,延遲一個固定時間再重傳,一般在1秒以上5秒以下,因?yàn)橛锌赡苌洗蝹鬏斒∈悄繕?biāo)節(jié)點(diǎn)“不在狀態(tài)”,下次傳輸可能就自動好了。②設(shè)計(jì)時序規(guī)則:應(yīng)用數(shù)據(jù)傳輸時需要考慮出現(xiàn)丟包時該如何處理,例如OTA升級,文件傳輸。每一幀數(shù)據(jù)都是必不可少的,而且順序還要正確。所以這類無線傳輸應(yīng)用中,應(yīng)該對每一幀數(shù)據(jù)包都標(biāo)注上序號。發(fā)送端一旦檢測到丟包,可能會重傳數(shù)據(jù)幀。而接收端有可能是因?yàn)锳CK沒有發(fā)送到發(fā)送端導(dǎo)致發(fā)送端誤判。如果接收端收到多一幀或少一幀數(shù)據(jù),都可以從每一幀的序號判斷出來。③該放棄時要放棄:類似接收端不存在,或者信道遇到干擾的問題,通過MAC層都可以偵測到。例如出現(xiàn)連續(xù)長時間的ACK失敗,可能就是接收端不存在;連續(xù)長時間的CSMA失敗,可能就是遇到了干擾。接收端不存在的情況下完全可以放棄對這個接收端發(fā)送消息。信道被干擾的情況下可以做整體信道切換,也可以暫停全網(wǎng)絡(luò)的運(yùn)行,保存當(dāng)前狀態(tài),等待干擾消失后再恢復(fù)全部的傳輸。

不算丟包的“丟包”

無線通信上除了無線信號導(dǎo)致的丟包,還有軟件邏輯上的丟包。典型的就是通信的數(shù)據(jù)量超過了發(fā)送端或接收端的處理能力。比如ZigBee的傳輸速率只有250kbps,加上CSMA延遲,路由轉(zhuǎn)發(fā),實(shí)際數(shù)據(jù)傳輸速率能夠達(dá)到5kbps~10kbps就很不錯了。發(fā)射端的應(yīng)用程序如果向發(fā)射端寫入數(shù)據(jù)的速度超過了發(fā)射端的傳輸速度,也會導(dǎo)致軟件丟包。通常各家芯片廠商的IEEE802.15.4的協(xié)議棧都會提供一個Send Confirm的回調(diào)接口,應(yīng)用程序向傳輸接口寫入需要傳輸?shù)南⒑螅s在幾毫秒到幾十毫秒內(nèi)收到Send Confirm回調(diào)觸發(fā)。同時一般射頻芯片SoC也會提供緩存來存儲寫入的數(shù)據(jù)幀,有可能應(yīng)用程序一次向射頻芯片寫入多個數(shù)據(jù)幀都被芯片SOC緩存起來,再慢慢的一幀一幀發(fā)射出去,然后Send Confirm回調(diào)被陸陸續(xù)續(xù)地觸發(fā)。如果應(yīng)用程序在發(fā)送消息的時候,每次向射頻SoC寫入傳輸消息,待Send Confirm觸發(fā)后再寫入下一條消息,就可以很好地規(guī)避軟件丟包的問題。4081abae-4b31-11ed-b116-dac502259ad0.png

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

總結(jié)

對于丟包的容錯處理是無線通信設(shè)計(jì)的關(guān)鍵,現(xiàn)有成熟的通信協(xié)議雖然做了很多措施來降低丟包率,如果丟包一旦發(fā)生一定要有容錯機(jī)制來應(yīng)對,否則就算是千分之一或萬分之一的丟包,都會為整個無線系統(tǒng)帶來災(zāi)難性的后果。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 通信
    +關(guān)注

    關(guān)注

    18

    文章

    5880

    瀏覽量

    135313
收藏 人收藏

    評論

    相關(guān)推薦

    LM258在這個電路里是電壓跟隨器嗎?R4在這里不影響輸出電壓嗎?

    我想問一下LM258在這個電路里是電壓跟隨器嗎?R4在這里不影響輸出電壓嗎?根據(jù)虛短的原理,V-是等于Vref。 那么Vo和V-的關(guān)系怎么分析呢,是相等嗎?怎么根據(jù)虛斷的原理分析Vo和V-的關(guān)系?這里是怎么得到Vo=V-的呢?
    發(fā)表于 08-13 06:05

    esp32 udp broadcast怎么避免?

    esp32 udp broadcast
    發(fā)表于 06-17 06:05

    BACKUP_PRIMASK和RESTORE_PRIMASK在這里主要作用是什么?

    ); } 請問,BACKUP_PRIMASK和RESTORE_PRIMASK在這里主要作用是什么?像是對中斷某些掩碼的壓棧出棧,具體在這里什么意思呢?感謝
    發(fā)表于 04-29 07:10

    網(wǎng)絡(luò)率正常范圍及其影響因素

    網(wǎng)絡(luò)率正常范圍及其影響因素 網(wǎng)絡(luò)率是評估網(wǎng)絡(luò)性能和穩(wěn)定性的重要指標(biāo)之一。 一、網(wǎng)絡(luò)
    的頭像 發(fā)表于 12-29 14:45 ?4432次閱讀

    連接相機(jī)怎么辦?如何設(shè)置網(wǎng)卡屬性?

    連接相機(jī)怎么辦?如何設(shè)置網(wǎng)卡屬性?
    的頭像 發(fā)表于 12-12 16:26 ?520次閱讀
    連接相機(jī)<b class='flag-5'>丟</b><b class='flag-5'>包</b>怎么辦?如何設(shè)置網(wǎng)卡屬性?

    常見的網(wǎng)絡(luò)故障定位?法

    本期分享一個比較常見的?絡(luò)問題--。例如我們?nèi)ing?個?站,如果能ping通,且?站返回信息全?,則說明與?站服務(wù)器的通信是暢通的,如果ping不通,或者?站返回的信息不全等,則很可能是數(shù)據(jù)
    的頭像 發(fā)表于 12-07 09:48 ?1174次閱讀
    常見的網(wǎng)絡(luò)<b class='flag-5'>丟</b><b class='flag-5'>包</b>故障定位?法

    48V電源系統(tǒng)可恢復(fù)eFuse的設(shè)計(jì)秘訣,在這里

    48V電源系統(tǒng)可恢復(fù)eFuse的設(shè)計(jì)秘訣,在這里!
    的頭像 發(fā)表于 12-05 10:09 ?605次閱讀
    48V電源系統(tǒng)可恢復(fù)eFuse的設(shè)計(jì)秘訣,<b class='flag-5'>在這里</b>!

    有關(guān)eFuse電子保險絲,你應(yīng)該了解的技術(shù)干貨,都在這里

    有關(guān)eFuse電子保險絲,你應(yīng)該了解的技術(shù)干貨,都在這里!
    的頭像 發(fā)表于 12-04 10:20 ?1274次閱讀
    有關(guān)eFuse電子保險絲,你應(yīng)該了解的技術(shù)干貨,都<b class='flag-5'>在這里</b>!

    J-Link 中的JTAG 接口:正確使用需要了解的注意事項(xiàng),在這里!

    J-Link 中的JTAG 接口:正確使用需要了解的注意事項(xiàng),在這里!
    的頭像 發(fā)表于 12-01 16:01 ?1179次閱讀
    J-Link 中的JTAG 接口:正確使用需要了解的注意事項(xiàng),<b class='flag-5'>在這里</b>!

    網(wǎng)絡(luò)問題分析

    所謂,是指在網(wǎng)絡(luò)數(shù)據(jù)的收發(fā)過程中,由于種種原因,數(shù)據(jù)還沒傳輸?shù)綉?yīng)用程序中,就被丟棄了。這些被丟棄的數(shù)量,除以總的傳輸數(shù),也就是我們
    的頭像 發(fā)表于 11-13 11:24 ?794次閱讀
    網(wǎng)絡(luò)<b class='flag-5'>丟</b><b class='flag-5'>包</b>問題分析

    網(wǎng)絡(luò)故障如何定位

    是數(shù)據(jù)被包了,類似情況想必大家都不陌生。針對網(wǎng)絡(luò),本人提供一些常見的故障定位方法,希望
    的頭像 發(fā)表于 11-10 11:27 ?1022次閱讀
    網(wǎng)絡(luò)<b class='flag-5'>丟</b><b class='flag-5'>包</b>故障如何定位

    網(wǎng)絡(luò)問題解析

    什么是 數(shù)據(jù)在Internet上是以數(shù)據(jù)為單位傳輸?shù)模瑔挝粸樽止?jié),數(shù)據(jù)在網(wǎng)絡(luò)上傳輸,受網(wǎng)絡(luò)設(shè)備,網(wǎng)絡(luò)質(zhì)量等原因的影響,使得接收到的數(shù)據(jù)少于發(fā)送出去的數(shù)據(jù),造成
    的頭像 發(fā)表于 11-09 15:10 ?760次閱讀
    網(wǎng)絡(luò)<b class='flag-5'>丟</b><b class='flag-5'>包</b>問題解析

    基于V682-SONiC交換機(jī)的實(shí)現(xiàn)網(wǎng)絡(luò)檢測的可視化

    網(wǎng)絡(luò)是網(wǎng)絡(luò)通信中較為常見的故障,越早獲取到信息和原因才可能越早進(jìn)行排障。SONiC的
    發(fā)表于 11-09 09:27 ?978次閱讀
    基于V682-SONiC交換機(jī)的實(shí)現(xiàn)網(wǎng)絡(luò)<b class='flag-5'>丟</b><b class='flag-5'>包</b>檢測的可視化

    RTT平臺zephyr_polling軟件SPI Bluenrg2問題排查

    在對協(xié)議棧在 Bluenrg2 芯片上采用 SPI 作為 HCI 的數(shù)據(jù)傳輸進(jìn)行測試的時候,發(fā)現(xiàn)存在問題。
    的頭像 發(fā)表于 10-23 15:41 ?436次閱讀
    RTT平臺zephyr_polling軟件<b class='flag-5'>包</b>SPI Bluenrg2<b class='flag-5'>丟</b><b class='flag-5'>包</b>問題排查

    [HPM雜談]你想要了解的先楫hpm_sdk開發(fā)都在這里系列 (二)

    一、概述在上一篇雜談文章《[HPM雜談]你想要了解的先楫hpm_sdk開發(fā)都在這里系列(一)》,大概分析了先楫通用單片機(jī)開發(fā)與其他國產(chǎn)單片機(jī)的開發(fā)差異,以及開發(fā)優(yōu)劣勢。剛好在這個月底,先楫官方發(fā)布了
    的頭像 發(fā)表于 10-12 08:18 ?1426次閱讀
    [HPM雜談]你想要了解的先楫hpm_sdk開發(fā)都<b class='flag-5'>在這里</b>系列 (二)