Separation of Application and Transport
Today I was helping to set up a lab to do UMA–unlicensed mobile access, a.k.a. the ability to make a call over GSM and "roam" to WiFi and continue the call. Or make the call over WiFi and roam to GSM. I actually had very little to do with the overall process of setting it all up, but I did get to do a lot of observing and to provide some clarity in terms of how to troubleshoot. (What amazes me is that even though I knew very little about how it all worked, I understood enough basic troubleshooting to provide guidance.)
From what little I understand about both mobile and telecom networks, they appear to be designed with a whole lot of complexity–complexity that seems antiquated in an IP-based world. It's a wonder this stuff works as well as it does. And it's a wonder we still use this stuff daily.
One thing I have learned through the school of hard knocks is that unnecessary complexity ultimately creates problems that are difficult to troubleshoot and fix. UMA adds a whole new layer of complexity on top of an already complex system. Each component interacts in different ways. Errors in those interactions can be difficult to isolate and troubleshoot, and there is likely more than one interaction responsible for the issues you might be having.
It occurred to me during this process that the very thing that UMA tries to accomplish would be much easier if both voice paths traveled over IP. In the case of UMA, you have to account for the fact the GSM network has to be aware of this "other" IP path the call might travel over, potentially tearing down and bringing up different networks. In the case of two IP networks, you still have to worry about which path a call might take, but the act of "handing off" is as simple as rerouting the packet. There's nothing from the voice point of view that needs to be "torn down," the packets are just routed over a different path. The "voice" portion of the sysytem doesn't even need to know this has happened, or care.
It goes deeper. Again, from my limited understanding of telecom networks, the application ("voice") and the transport mechanism seem inexorably tied together. Perhaps someone with real experience in this area like Ken Camp can confirm this supposition, but let's assume I am right for the moment. That, in my mind, creates unnecessary complexity that makes it much more difficult to troubleshoot effectively. IP is built on the 7-layer OSI model, thus demanding separation between application and transport. While the application does depends on transport, transport does not depend on the application. You simply work your way up the OSI model to help you zero in on your issue. You can also replace any component of that stack as needed without having to redesign the entire application.
So when will the telcos realize that it is in their best interest to move everything to IP as quickly as possible, including "basic" phone calls?
Bookmark with: del.icio.us Digg it Furl iFeedReaders ma.gnolia Maple.nu RawSugar reddit Simpy StumbleUpon
Comment by Anonymous
Not likely, Phoneboy
It’s hard to control consumers in an all-IP environment, Phoneboyeeeee. Hence the time-division hijinks and UMA. The cell carriers are in no hurry to move to IP.
Comment by Anonymous
The following may be out of
The following may be out of context in which you state that, “[in telecom networks] the application (”voice”) and the transport mechanism seem inexorably tied together”. For a long while now, this seems to be the conventional wisdom, thanks to the “Stupid Network” paper. I am of the contrary view. If this is indeed true then how come we are able to use the telecom network for a Fax application or a data (modem) application? The Stupid Network paper claimed that one can not change the codec in the old telecom network. Of course it is factually erroneous. The STU III telephone uses a different codec and that predates the paper. With the current advances in the technology, one can run a wideband codec end-to-end, all without making any changes to the “Middle”. Just grant intelligent devices at the end.
Comment by Anonymous
Another approach?
While I understand you are dealing with GSM in Europe,
I thought this info regarding CDMA2000 1xEV-DO Rev. A was worth mentioning.
Taken from this Qualcomm announcement (June 07, 2006) -
Sprint planned to begin rolling CDMA2000 EV-DO Rev. A out in 4th QTR of 2006/early 2007,
but I believe they have already started at this time.
Comment by Anonymous
Ahem. Economics…
“IP is built on the 7-layer OSI model, thus demanding separation between application and transport.”
SS7 has never followed the ISO model as most of the protocol predates it. ISUP for example isn’t even nicely conformant with the rest of the SS7 protocols — it covers several SS7 levels. Anyway, TCP/IP just isn’t good enough for telephony signalling protocols that demand 911/111/000/112 levels of service — SCTP/IP is but not well adopted.
“So when will the telcos realize that it is in their best interest to move everything to IP as quickly as possible, including “basic” phone calls? ”
I’d love it if my network ripped out all their 1000’s of basestations, routers, MUXs, and all the MSCs. But how is it going to pay for it? If the cost of wireless data continues to decay but users demand more bandwidth, coverage, and services I can’t see how this is going to work. For these businesses to succeed on an ongoing basis the customer base has to end up paying at least the cost+margin, and “internet” model retail prices are never allowed to go up.
Ripping out all this equipment and replacing it with more complicated equipment to provide basically the same service isn’t economic.
We can debate the “more complicated equipment” another time…certainly they are less mature and don’t inter-op well.
UMA is overly complicated. The CDMA equiv. will be too. I’d love to do this on CDMA/GSM/UMTS with fast MobileIP switching like WiMax is planning, but…I’m not even sure fast MobileIP handoff is a current reality.