Tell me more ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.
up vote 0 down vote favorite

Is there a formula describing the relationship between bit error rate, frame size, and normalised effective throughput?

to clarify, normalised effective throughput is the same as channel utilisation.

so far I have "throughput = 1/(1+2a)" where "a = tprop*R/L" (tprop=propagation time or delay,R = bit rate), however I am unsure how bit error rate fits into this - does bit error rate have much to do with bit rate.

Any help/pointers/where to get help would be appreciated. are there any other forums that I should post this on?

EDIT: Just to give some more background info: basically this is for a project(topic: analysis of optimal frame size and bit error rate relationship on lossy links), where we have to write a MATLAB GUI (graphical user interface) and the inputs are bit error range (ie max and min bit error rates) and frame size range (max and min frame/packet sizes). We have to calculate the normalised effective throughput of the link from those inputs, and make a 3d graph.(x:BER, y:FSR, Z:throughput)

@clabacchio i was talking about general parameters - L stands for number of bits in a frame.

@kellenjb we haven't been given any info on how errors are handled, so i suppose we just make an assumption. (and i deleted the other posts, sry about that)

share|improve this question
What are you talking about? A protocol? General parameters? What is L? – clabacchio♦ May 14 '12 at 13:10
Can you give us some background of why you are asking this as well as how you have come up with what you have so far? to answer one of your questions... "does bit error rate have much to do with bit rate" - Yes, a faster bit rate causes the energy per bit to decrease resulting in a higher signal to noise ratio. – Kellenjb May 14 '12 at 13:18
You'd have to define things rather more tightly before you could get a useful formula. eg the data getting through is D_sent x (1-BER) (BER fractional rate eg 1 in 10^6 = 0.000001). BUT ANY error either needs a resend or has forward correction overhead. If any BEr at all needs a resend then throughput drops to D_sent x (1 - (packets with error(s) in them = pweit)) [ 0 < pweit <1]. To convert BER to pweit you either assume every single error destroys a packet or need to know statistical grouping of errors. If you lose sync due to errors and must resynchronise that is a rate rduction and you .. – Russell McMahon May 14 '12 at 13:18
... need to know how resync varies wih error rate and types of error hit. And much more. SO the answer is yes, a formula can be derived which is as useful as the assumptions that you make and which will hav a ststaistical component due to effects of stat variation of noise and resync and ... om results. I guess this is an answer ;-). I'll make it one. – Russell McMahon May 14 '12 at 13:20
Frame size is another one that you will have to have more detail for. A single bit error in a packet can cause the whole packet to fail, but as russell mentioned, you can add FEC to correct the error. In some cases a larger packet allows for FEC to be performed more efficiently, thus improving overall error rate, but you haven't specified any of this. – Kellenjb May 14 '12 at 13:28
show 2 more comments

1 Answer

up vote 0 down vote accepted

Yes, you will be able to arrive at a formula which will at best be as useful as the accuracy of the assumptions that you make, and which will have a statistical component due to effects of stat variation of noise and resync and ... on the results.

You'd have to define things rather more tightly before you could get a useful formula.
eg the data getting through is D_sent x (1-BER)
(BER fractional rate eg 1 in 10^6 = 0.000001).

BUT ANY error either needs a resend or has forward correction overhead.
If any error occur at all then you need a resend and
throughput drops to D_sent - (packets with error(s) in them per second = pweitps) x (packet data content length )
And you also have the back channel overhead which may be part of your total bandwidth budget or may not.

To convert BER to pweitps you either assume every single error destroys a packet (as above), or you need to know statistical grouping of errors.

If each error bit loses one packet and if net error free data rate is D and if packet length is P then you lose BER x P bits/second due to errors so rate simplistically reduces to ~= (D - BER x P)/ D of previously.

If you lose synchronisation due to errors and must resynchronise that is a rate reduction and you need to know how resync varies wih error rate and types of error hit.

And much more.

SO the answer is yes, a formula can be derived which is as useful as the assumptions that you make and which will hav a ststaistical component due to effects of stat variation of noise and resync and ... on results.

share|improve this answer
thanks for taking the time to reply with an answer! :) means a lot. i'm struggling with what assumptions to make from here as we have not been given any info about how errors are handled. whats the best assumption to make in a situation such as this? by the way i have updated the question with some more background information. – user1393689 May 15 '12 at 9:07
Wet finger in air simplistic assumptions / first cut: Frame size and BER are allowed variables in your problem. Define a (data as % of frame) variable, assume any single bit error trashes the frame and that all single errors trash one frame each OR make up some distribution that seems good. Assign mean resync time as a variable, assume no Fwd Error Correction (FEC) and that lost packet is always resent. Low BER menas few to no resent packets are lost again. Model if desired. If you need anything else make it a variable and assign a semi-constant value to it and come back to it if ... – Russell McMahon May 15 '12 at 9:19
... needs be or time allows. Some major tradeoffs that your formula or simulation is trying to identify are - If frame size is large then frame overhead is small and rate gets good. BUT if a frame is lost you must resend whole frame and lose that much data. As BER rises the increasing loss of packets make losses too high and by reducing frame size you lose less when error strikes. – Russell McMahon May 15 '12 at 9:24
... Frame size has some effect on size of packet overhead. For CRC to work you need N bits of CRC per data block size and large blocks with poor BER and too short CRC may give unspotted errors. Parity etc may be lower cost that CRC but lead to unspotted errors for >1 bit errors per packet. FEC allows no resend in many cases at the cost of extra FEC bits. etc – Russell McMahon May 15 '12 at 9:25
thanks for your help, in the end we decided to go with "thr = (D - BER x P)/ D" – user1393689 May 17 '12 at 12:49
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.