Forums

Reasonable choice for BER during packet based simulations

Started by cogwsn 6 years ago4 replieslatest reply 6 years ago83 views

Hi,

I am performing some tests with WiFi and ZigBee. There are some situations when the header of the frame is lost and hence the receiver discards the packet. In such cases, is it a reasonable assumption to say that bit error rate was 100% ?

For example the receiver missed initial sync part of WiFi and hence dint bother to decode the rest samples. So even if the samples were not corrupt, nothing was decoded.

If I put BER as 100% for such situation, then it will degrade the overall stats of the experiment.

Could you suggest something reasonable.

Regards

Sumit 


[ - ]
Reply by motilitoMay 2, 2017

This is exactly why the 802.11 standard defines a requirement for PER and not BER. For packetized transmission it is more suitable to define the PER and not the BER. In some cases you may have some constant ratio between them but for WiFi it is not the case. The 802.11 standard defines PER to be %1. The MAC mechanisms like retransmission lower it to a more reasonable value.

For the simple case of BER, most of my past clients insisted on marking all the bits in the dropped packet as errors!

This simply implies that if you design the system preamble and header detection must be better to minimize packet loss.

[ - ]
Reply by cogwsnMay 2, 2017

Yes I am counting the PER for WiFi already, 

So with your suggestion, I think I have no option but to mark all the bits as error in the dropped packet !  

[ - ]
Reply by motilitoMay 2, 2017

From my point of view, since the communication is between computers even a single bit error renders the packet useless. There are some cases like some video and audio streams that can live with a few error bits but for most cases the packet must be dropped.

Good luck,

Moti

[ - ]
Reply by SlartibartfastMay 2, 2017

For bursty systems like WiFi or Zigbee, PER (Packet Error Rate) is usually used instead of BER, pretty much for the reason you illustrate.  Characterizing PER provides a good performance metric without having to guess or score what happened with a dropped packet.

A typical thing to do is send a test stream with equal-length packets and measure the number successfully received.  Even received packets that don't pass CRC (or fail for whatever reason) generally do not get counted.