Weird GPRS and UMTS latency
Bad designer sent me an interesting comment: 2G and 3G networks have huge latency issues. GPRS is intolerable, UMTS is awful and HSPDA is reasonable but still not what one would hope for.
The latency does not seem to be associated with serialization delay. UMTS gives you reasonable transfer rates and significant latency and GPRS gives you an order of magnitude higher latency than ISDN with comparable transfer rate. If anyone knows enough about the mobile technologies to explain this phenomenon (or at least give me useful pointers) I’d really appreciate your comments.
Anyway, here are a couple of links discussing the issues. Its very much to do with the radio states and channels. (The air interface)
both start up latency and your regular latency are discussed.
1. (Read the comments, more of an business analysis on mobile blog)
http://disruptivewireless.blogspot.com/2008/07/latency-in-mobile-more-needs-to-be-done.html
2. (Read his articles he links too -- This is a great blog for watching the 3gpp standards evolving and he explains them too.)
http://mobilesociety.typepad.com/mobile_life/2010/01/solutions-in-the-pipe-for-faster-3g-browsing-startup.html
3. (Not to do with latency but in depth descriptions of the standards..)
http://wired-n-wireless.blogspot.com/2009/10/lte-whitepaper-from-wired-n-wireless.html
An interesting aspect is everyone saying LTE having an all flat architecture with less devices etc in the path will help.. I dont buy it. Even in 2000 there was no congestion (1gig edge 2.5 gig backbone) and as such from the packet core entry point just propagation latency. That firmly lays the blame downstream to Radio Area Network (RAN) and the Air interface (Radio)
That used to be mobile--air--3g--nodeb--atm--rnc--atm--sgsn--gige--ggsn--gige--mpls_backbone (Pos).
Now is air-hsdpa-nodeb-(Vpls)-rnc--gige--sgsn---10gige--ggsn--10gige--mpls_backbone (Pos/10GE)
LTE will be air--OFDM/LTE--enhanced_nodeb--ethernet_backhaul--enhanced_Serving Gateway---etherent--enhanced_packet_gateway---MPLS_backbone (40gig) (Here you see the devices collapsed)
apologies for any mistakes in the above but i did this quick :-).
When discussing the latency in 2000/1 (Yes I noticed immediately and raised it) with my colleague Vendor Radio guys, they said "You IP guys will just never get a handle on how radio is working"... I said then it was unacceptable. Glad to see they learned.
I don´t how a phone handles the video...but i assume that the same SGSN/GGSN and so on combo is used as for data ?
afaik, Voice and data use different radio channels (Logical/Physical). Voice is continuous and data is bursty so switches channels.
whole chains of errors or missing stuff in a radio type link than the single bit errors
you get in most other contexts, one approach (also used on CDs) is to send one bit
each of a bunch of codewords, then another bit of each, then another, and so on. so if you lose multiple bits in a row all that happens is you've slighting damaged each of several different codewords and can recover them all. However, this approach massively increases serialization of any single codeword.
As I say, this may have nothing whatever to do with the problem you are seeing.
a quick google search turned this up
http://disruptivewireless.blogspot.com/2008/07/latency-in-mobile-more-needs-to-be-done.html
I've worked with GGSNs and other parts of the mobile data network, and the delay is not in the network (between GGSN and NodeB). I would think it's due to the encoding/decoding of the radio signal what with the spread spectrum and signal bouncing. It would be interesting to know in which direction the signal is slowest.
Also, it's good to keep in mind that the uplink speed is much slower than the downlink speed.
But I never worked with the radio parts, so I don't know any details.