Forum

Issues in VoWLAN Designs
about that unuseful acknowledgments in VoWLAN system

you all know that wifi uses acknowledgments for every transmitted frame, but this can be an issue in voip conversation retransmitting former voip packets while talking (in live streaming this is not desirable you know)

but new 802.11n EDFC function makes things better using acknowledgments for group of transmitted packets but:
how to override using these acknowledgments in VoWLAN deployment? are they necessary?

-is there still exchange of these unuseful acknowledgments for voice traffic?
-is there any mechanisms to avoid using acknowledgments for voice traffic and let is flow freely without any retransmissions?
-is not it seen better for telephone call listeners to tolerate some dump delays or because of retransmissions have some kind noise and discomfort during the conversation?

I think I understand what you are saying: that once a VOIP packet goes out of sequence, it is essentially useless.

The problem is that Wi-Fi uses ACK ???¡é?¡é?????¡­?¡°messages???¡é?¡é???????? for many purposes. One of them is to act as a rough indicator of ???¡é?¡é?????¡­?¡°how the link is doing???¡é?¡é????????. In other words, are we missing a lot of ACK???¡é?¡é?????¡é???¡és ? This could be due to many factors, including range etc. This ???¡é?¡é?????¡­?¡°feedback???¡é?¡é???????? is very important to 802.11n and all of Wi-Fi. Some rate changing algorithms take the number of lost ACK???¡é?¡é?????¡é???¡és into condsideration. Although it takes up a ???¡é?¡é?????¡­?¡°bit of space???¡é?¡é???????? ACK???¡é?¡é?????¡é???¡és are extremely useful.

In some cases, block acknowledgements can be used to make the system more efficient. These can occur at either the MSDU level or MPDU level.

The RTP protocol header [ at a higher layer above 802.11n ] contains a sequence number which it uses to ???¡é?¡é?????¡­?¡°piece together???¡é?¡é???????? the various voice ???¡é?¡é?????¡­?¡°packets???¡é?¡é????????.

Dave

One other issue is that in order for Vo-Wi-Fi to work properly, a large number of parameters such as packet loss, delay and a bunch of others all have to be kept "within specification". The feedback mechanisms of 802.11n etc help with this.

Adding voice to an existing Wi-Fi system can be a very involved process [ in order to get a really good functioning system ].

Dave

I don't agree that ACKs in wlan for VoIP are useless. While we have an udp voice packet each 20ms (usually) the retry mechanism for wifi makes new packets in micro seconds order.

If we have a 10% packet loss in wifi it does not mean necessarily that you will have 10% voice packets loss.[/u]

yes, you understand right, and it is to you to optimize wireless network parameters for voice functionality, implement QoS and made such brain ache steps.

if any of you know are topics such of this covered in any CWNP books?

As well as books, I'd contact the manufacturers of various Voice over Wi-Fi pieces of kit [ gear ].

If you establish a good relationship with them and get friendly, they can send you all sorts of "goodies" including documents that you don't see on the tech support pages as well as DVD's etc. A wee bit of "social engineering" goes a long way. I've got boxes full of all sorts of stuff from ATM to Multicasting from various manufacturers from over the years.

Best off starting with a sales guy. Just send a mail introducing yourself. In my expereience, forget about tech support if it is based on a call center.


After my initial training in telephone switching many moons ago, I had to become self taught on just about everything, and some of these documents can really help.

Dave

Also remeber that the Jitter buffer in the handset have to be able to accept a queeue size of several packets, to be able to sort packets arriving in the wrong order. So it should be possible to accepr 50 to 100mS delay of a retransmitted packet. So those 20 mS transmit window may be stretched a lot more.

Use the Jitter buffer stats to see how big buffer the phone is/were using.

Martin

You mention transmit delays, but what is important to the listener is the [b]audio[/b] delay. If the packet gets there when, or before, it is meant to be heard, the listener will be happy.

In my experience, most people will put up with a few 40 msec delays - which is the length of an intra-word silence (sorry I don't remember its real name). Few people can detect a 28 msec gap, and only professional voice recording people can audibly detect something as short as 11 msec - and they may not be able to identify what was wrong with the audio (11 msec was my limit when I worked in Telephony).

When you see requirements like 140 or 150 msec, they are not talking about the gaps in the audio - if you heard this all the time you would throw out the system as a piece of junk.

You can play all sorts of games with audio - throwing out silence periods longer than a certain amount, truncating the length of every word, or a sentence - and humans will still understand it just fine. Start throwing in too many long silence gaps though, and people will think your system sucks.

Better to throw away a short audio segment than to garble it.

What is your experience with dynamic jitter buffers? Are they using the techniques you listed when they shrink in size or do they stay in size at the once maximum needed size?

There are the block-ack and no-ack options out there that may improve the Ack overhead problem.