I just finished testing the Ascom i62 a/b/g/n VoFi phone
Last Post: April 3, 2014:
Happy Presidents Day! I just finished evaluating a trio of Ascom i62 handsets and thought I would share some tidbits of my results. First off, overall the voice quality was good, probably the best I've heard on a Wi-Fi phone. The i62 it is an a/b/g/n handset with MCS0-7 capabilities. That's all good and well, because I never actually observed the phone transmit a clause 20 PHY rate. It received then really only used 54 Mbps and very rarely 48. The phone usually began probing for a new AP at -62dBm per the in-call RSSI report. The transmission intervals were at 19-20 ms as one would hope. Each voice frame is 250 Bytes using G.711 uLaw. The roam times I measured averaged 40 ms and jitter was 1.33 ms. The majority of the roam time was from the derivation and transmission of key 2 and 4 totalling about 15ms. The probing delay also contributed about 15 ms on average. Something that I started thinking about during this test was the cost of PHY rate changes and what would you put into a PHY rate algorithm. I noticed that the phone used clause 16 802.11a PHY rates. Meanwhile my AP's were only using MCS4 (39 Mbps). However, the PHY rate never changed. Retransmissions are the enemy of VoWiFi and they have an ally named High PHY rates. Perhaps it would be better, IN SOME CASES, to set the max PHY rate on a handset to say 36 or 24. I don't know if all PHY rate algorithms use retransmission or not. I would suspect that they would probably use an SNR first. I love getting my hands dirty with a protocol analyzer. It generally leads me to asking a lot of questions. I'd love to hear some responses regarding roaming and PHY rate experiences.
I imagine that any properly designed algorithm must incorporate retries. What kind of retry rates were you seeing? An AP using MCS4 seems very odd to me. In fact, now that I think of it, an 11n AP using MCS 0-6 seems odd to me unless you have a completely clean 11n environment with no 802.11a/b/g.
One edit, I noticed that I put clause 16 instead of 17, I suppose I should proof read posts. :). As far as the data rates, I am going to take some more captures on AP's with newer code. It would seem that you need to have retries trigger a PHY rate decrease unless a PHY rate decrease was not necessary and thus retries would not occur. I would expect retries to reduce battery life and cause voice "artifacts" or interuptions. This makes me think avoiding retries would be the first line of defense. What I mean is that instead of using the highest PHY rate available it may make sense to use the lowest PHY rate that it can afford. So, an AP with only two phones connected could afford to use a lower PHY rate such as 24 or 36 Mbps as there would be plenty of bandwidth available for each phone. On the other hand if the AP had 12 phones connected then it would be prudent to use the highest PHY rate available it could and then use retries as a trigger to lower the PHY rate. It is a balancing act of capacity versus quality.
If you have a phone/wlan controller, I would assume it is controlling all those details.
I am not that familiar with phones, and although I know they do not have that high a bandwidth requirement, I do know that many devices don't use retry rates in their roaming algorithms - still to tis day some only use RSSI or other simple measures.
Assuming this is 5Ghz? ?phone used 802.11a PHY rates? what where your mandatory and available data rates set in the AP profile? Were there any other devices connected to this AP? I agree with Marcus about there not being much since in using MCS0-6 unless you are using 40MHz. Is the Ascom i62 capable of 40MHz?
Also to do with your rate shifting conundrum, a colleague and I were discussing the same thing. What if you only permitted every other PHY rate? This way with most mobile devices, it is not tempted to rate shift as much. ??? Just a thought.
Supported rates: 18, 24, 36, 54
Extended supported rates: 6, 9, 12, 48
MCS Set: bits 0-7 are set
*interesting the phone uses the extended supported rates element
Supported rates: 6, 9, 12, 18, 24, 36, 48, 54
Basic rates: 6, 12, 24
MCS Set: bits 0-7 are set
Regarding rate shifting, it's probably not as big of a deal as I'm making it out to be. I doubt that you would even notice a retry.
You may want to do a calculation of the total packet size for 54 Mbit/s Clause 17 and 19 and compare with MCS7 for a Voice Packet of 250 bytes and the airtime. If you have time do it for all speeds MCS0-7 and the similar speeds for a/g without /n.