Given I assume that it's a satellite-based connection, I would expect the latency to be high. Sattelite connections vary greatly in terms of their latency, but they're generally much higher than fixed broadband or even terrestrial wireless connections.
Why do you say its a satellite-based connection? According to a previous post in this thread by
dot:
dot said:
I agree that latency will be relatively high, but I wouldnt expect it to be much worse than a current 3G (UMTS) connection as the link from the aircraft is directly to the ground rather than via a satellite like Connexions by Boeing was. Hopefully, the Aircell groundstations and network connections have been well designed to minimise latency for pax.
If this is true, then wouldn't latency basically be the radio transmission time from the aircraft to the ground receiver (basically the speed of light over say 40,000 feet vertical component and up to several hundred miles lateral component), plus modulation/demodulation delay? Then assume they trunk all the traffic back to one central gateway which could be at the opposite side of the continent in the worst case. So based on these assumptions I see the following:
Radio transmission distance = 500km maximum
Radio transmission speed = speed of light = 300,000,000 m/s
Radio transmission delay = 500,000/300,000,000 = 1.7ms
Round-trip latency due to radio link = 2 x 1.7ms = 3.4ms
Radio Modulation/demodulation Delay = 5ms
Ground station trunk to internet gateway (round trip time) = 30ms
total latency from aircraft to internet gateway = <40ms
Now we do also need to consider the serialisation delay at each point, which is dependent on the individual interface speeds in the path. Assuming we are only considering VoIP and save G.729 CODEC and a sample rate of 10ms and packet rate of 50pps, we have 20 bytes of data in each packet, plus 20 bytes of IP header, 8 bytes of UDP header and 12 bytes of uncompressed RTP header, so packet transmission will be padded to 64 byte minimum for IP (i.e. minimum size packets). Hence serialisation delay is low, even for low bandwidth interfaces.
So it would seem that latency is not going to be a major concern for such a connection. I regularly use G.729 with well in excess of 350ms round-trip delay.
The biggest issue I would expect, as related to VoIP call quality, will be packet lossdue to congestion. If packet queuing delay exceeds the jitter buffer (typically around 40ms) then late arriving packets are seen as lost packets. G.729 (and G.711) treats out-of-sequence packets as lost packets since its only got UDP for delivery. So assuming they do not limit MTU size (i.e. carry 1500 byte packets) or implement any form of QoS on the link, congestion or contention will likely result in VoIP packet loss either from tail-drops at the congestion point or jitter buffer over-run at the receiving station.
It does depend a little on the codec that you and your VSP (Voice Service Provider) use, however. The most common codecs used in Australia are g.711 (a-law and u-law), which is what the standard voice network now uses, and g.729, which is a slightly more compressed codec. g.711 is highly latency sensitive, and likely would fail outright. g.729 might work a little, but would likely suffer dropouts.
The network characteristics of G.711 and G.729 are similar. Both generally operate with a sample interval of 10ms and combine two samples into each packet for a packet rate of 50pps. G.711 carries 160 bytes of data in each RTP packet, while G.729 only carries 20 bytes. I don't understand why you suggest G.711 is highly latency sensitive. G.729 introduces slightly more latency due to the compression overhead, being about 10ms for G.729 and <1ms for G.711.
There is a little known codec called iLBC (internet low bitrate codec) which is designed for high latency connections, however, it's not well supported (I only know of MyNetFone supporting it at the moment, although I understand that Pennytel will do so shortly), which degrades much better over higher latency connections (it's more tolerant of voice packets arriving out of order over a data connection), but even if it works well, you will find that there's a long delay (you say hello, and you have to wait for them to receive it and then say hello back - and you may find that you end up talking over each other as the delay from you to them and them to you means that the conversation doesn't flow smoothly.
iLBC is decribed in RFC3951. As iLBC still uses RTP for its transport, it will still consider out-of-sequence packets as lost packets. Its just that due to its use of linear predictive coding the voice quality degrades gracefully with packet loss, hence being considered more tolerant of out-of-sequence packets. But its not an option for most corporate VoIP implementation based on iPBX technology from the major IPT vendors today.
In other words, it's possible, but there are some unique challenges, and some pretty major compromises. If you're determined to have voice calls on an international flight and not mortgage your house, though, this would be doable.
I don't see it as any more challenging than operating over a hotel WiFi internet service or an airline lounge, and I have used my G.729 connection many times under such conditions - with mixed success depending on the congestion of the internet gateway.
Not that I'm advocating it - a plane full of chattering people would be painful!
Agree totally, and even if I could do it, I would not.
) from a company called Aircell. This short video from the Wall Street Journal explains it well.
