Separation of Application and Transport

16 Oct 2006

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?