I left off Part 6 in this series with a promise to delve deeper inside the smart phone to see how the idea of a demarcation point is becoming distributed, and therefore more complex. Simple cell phones, as I have shown, have a fairly-clear demarcation point: the SIM card. With the new generation of smart phones we must go beyond the SIM card. In keeping with my broad theme, I will focus on how smart phone presents new challenges for telco control of the phone.
A smart phone is a general-purpose computer, just like your PC but with outer constraints determined by its size, both physical and in its components, and with its dependence on the network. Perhaps a closer comparison can be made with an appliance exemplified by Microsoft's Xbox game console since it is a general-purpose PC wrapped inside a box that makes it seem like a special-purpose appliance. If you can somehow unwrap that box you will find that computer in there. Many hackers have done just that, much to Microsoft's dismay. This type of game is not restricted to the Xbox, since you can do it with Apple's iPhone and phones utilizing Google's Android, among a growing list of others.
That computer wrapper is very important to telco, permitting them to control your use of the device. However, before we go further let's take apart the smart phone into the component blocks that I believe are most relevant to my topic. These are, roughly:
The network is of course not part of the physical device, yet since it cannot be avoided in this discussion I include it as one component among the rest. We'll start in the middle of my list and work outward from there.
The hardware platform is the real enabler of the smart phone. There is some wonderful technology in there that I am going to almost entirely as irrelevant to this article. The important part is its interfaces to the software platform and the radio transceiver. The interface to the software drives the partnerships between phone manufacturers and software platform vendors. Sometimes these partnerships are manufacturer driven (Nokia in the case of Symbian), sometimes they are software platform driven (Microsoft and Google), and can also take the shape of broader associations (Open Handset Alliance). We also must add to this mix the telcos, since they greatly influence the business dynamics among the players by leveraging their control of the distribution channel to consumers.
The interface between hardware and software is a focal point since it determines, through the facilities it makes available, what the software platform can and can't do, which then determines the same for 3rd-party applications. The interface is little more than a series of drivers, much like those on your PC, that by abstracting low-level functionality, frees the software from having to know too much about the hardware. By planting a durable stake in the ground, the interface guides hardware vendors in cases, as with Android, where Google is trying to encourage participation by more phone manufacturers. The telcos can try to have the interface include or exclude functionality, or put in a mechanism to control access, in order to maximize their control over the consumer.
More often the access control (security, if you prefer) is in the software platform itself. App develops know there exist inaccessible APIs (application program interfaces). Getting knowledge of the most interesting of those is not possible for a true outsider. Disclosure and access tends to come like the layers of an onion, where you get to peel away more and more layers as the manufacturer and telco benefit from the app developer's involvement, and can establish trust by means of enforcable legal instruments. This has long been true of Symbian, and is much the same with Windows Mobile. Even Google's Android has its secretive bits despite being more open than any of the others.
All of this control is necessary to the business interests of phone manufacturers and the telcos through which they sell their products. Like the Xbox example, strip away the box and potential revenue from captive services can vanish in a puff of smoke. Perhaps the most protected part of the hardware platform is the phone itself. App developers simply can't get the APIs that control access to the set of primitive functions that manage the phone. They may allow an app to initiate a phone call (after all, that generates revenue), but not to answer calls, tap into the speech path, or control all aspect of phone state. If apps could get those, expect to see some fierce competitive offers to compete with high-profits features like voice mail, long distance, call screening, and so on.
This is one reason why some app developers are excited about Android (including myself) since it has more open APIs for interacting with the phone and persistent services, and there is promise of more to come. For now at least, despite being open source, Android mostly locks down the phone. It is true that you could take the source, add your own phone app (that's not open source, and not strictly-speaking part of Android), and if you can somehow by nefarious means (there is no way for a non-OHA member to do so legitimately, as far as I am aware) get the specs for the needed hardware platform interfaces, and build a complete platform that would run on an Android-capable device. It turns out that is insufficient - you now have the telco to deal with if you want to use their network. You will not get your garage-built phone to connect to their network without their authorization, and inclusion of their keys in the phone. At least it would work fine on any Wi-Fi network, including VoIP with a suitable app, so it's not a total loss.
It is now time to move in the other direction to look at the radio transceiver. This may seem an odd place to talk about control since this is the segment of the phone that contains the least amount of intelligence, and any security the telco might want can be better placed elsewhere. Even so, there are a couple of points to make. First, the transceiver in almost every case can do voice or data, but never both at the same time. If you are browsing the web and a call comes in, the voice communication takes control of the radio and your browsing is temporarily suspended. Some phones and platforms go further than this to prevent any app other than the phone app from running during a call, but that is a platform issue (protected APIs), and not due to the radio. There are some good, practical reasons for this, not least of which is personal safety (do you want a misbehaving app preventing use of the phone in an emergency?). There are also technology constraints in the radio hardware and the network radio protocol to be considered. When this changes, as it likely will, there will remain reasons to continue with the present restriction.
Consider a trivial service like Calling Name, where the Caller Id is used to pull a name out of a database. If the phone did both voice and data, an app could use the Caller Id (commonly available via an API) to launch a query over the internet. Like other services, this one is quite profitable to the telco (even if not yet universally available for unrelated reasons) and they do not want competition. They provide the name by doing the query from within the network, and then deliver it along with the call. It is still possible to get around this, at least on Android. There exists an Android app that does the Caller Id look-up, but only if you have Wi-Fi access. It uses that path rather than the cellular radio transceiver to access the internet. That's one reason I like Android!
Now we come to the last segment in my list: the network. I am going to address the data network since the voice network doesn't do much more than what we've already seen since, apart from the fancy radio technology, the network behind the radio towers is merely a legacy circuit-switched telephone network. The consequent limitation of features on the voice side is relevant since data enables so much more. Therefore the telco wants to controls how you use the data connection, and their revenue.
They use application and volume filters like many broadband ISPs, since they are an ISP. There are some differences that are particular to wireless carriers. First, they vehemently oppose VoIP. Although they have the ability to prevent many VoIP apps through their influence on the manufacturers' and platform vendors' app stores, it is still possible for some to get through the screening process or to circumvent the stores entirely by those who jailbreak their phones. For this reason it is no surprise to learn that the telcos use some fairly aggressive DPI (deep packet inspection) on wireless data.
The second is that, unlike your home broadband service, the network provides the firewall functionality. This is done for your protection, which is a good thing, but also to control the range of applications you can use. This is a more subtle point that is less obvious in its negative consequences, but is nonetheless important. It's big enough as a subject area that I will cover it in a separate article in this series.
This is already a very long article so I'm not going to cover more technical detail; I've covered enough of it for my present purpose. I will finish with what I believe this all means in regard to telco control of the smart phone.
Because of their sophistication, raw capability, and standard computing core, the smart phone is a big risk to the telco's business. They know this and are doing what they can to build in control points before outsiders start their counter-offensive. They are most concerned with the software platform vendors, not the consumers and app developers. At least not directly. This is why it was so newsworthy when Apple brought out the iPhone and their iTunes app store, and were able to dictate much of the terms to AT&T and then to other telcos. The telcos can't stop smart phones, nor do they want to, provided they can claim as large a piece of the action as they can. Each telco by themselves, big as they are, cannot control the development, manufacturing and distribution of the smart phone since the brand (Apple, Google, RIM, and perhaps Nokia) and the eco-system of apps they create are a more powerful force in the market.
The smart phone platform vendors still need the telcos so this is far from being a one-sided struggle: the telcos can still dictate some terms. So far these include locking down the cell phone app, blocking competitive phone apps, and, to my surprise, sometimes even gating use of the Wi-Fi capability of the phone (AT&T and iPhone). As already mentioned there is also the control they exert from within the network, and which is separate from their relationship with the smart phone makers.
This struggle for control seems to me workable only in the short term. Because of the distributed intelligence in and associated with smart phones there is a whiff of the divide and conquer maxim at work. With an increasing body of phone manufacturers, app developers and consumers eager to get their internet, there are too many fronts to this battle for the telco to prevail against. There is also the spectre of increasing wireless competition: when one telco blinks and lowers the wall just a bit, the others will have to respond. Carried to the limit this will reduce the telcos to little more than wireless access providers. I think they will eventually have to climb in the pool with the rest of us instead of standing guard at a fence so low that they will be overwhelmed and therefore superfluous in their role as gate-keeper.
As with most things, this will not happen overnight and it won't travel a smooth trajectory. Along they way there are bound to be some big winners who will profit from the loss of telco control and the march of technology. Some of the likely winners are already well-known names, and may include those I've mentioned.
In my next article I will look more closely at VoIP on the wireless phone and what it promises in the telco's continuing attempts to control the phone.
Monday, February 9, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment