The i730 and Beyond

I've been writing about the Samsung i730 because it's at the crossroads of telephony and computing. For now it's still a phone. In this essay I try to explore why and why not. It's about more then Verizon trying to maintain control and Microsoft missing the new face of personal computing.

12-Jul-2005 Bob's other writings. Version 2: 2023-05-28 17:09:26

PDAs, Verizon, Microsoft, Users and Personal Computing

I am using the Samsung i730 as a starting place to explore industry issues and market forces while still being interested in the i730 as a device that I now use. It is indeed a significant improvement over the i700. Now that I've had the phone for a few days I want to explore the issues in more details. It's unfortunate that the i730 is still a telephone because it can be so much more.

The i730 is the high end of personal computing – it's far more powerful than the early personal computers. Today's so-called personal computers are more like desktop mainframes – powerful but too expensive, cumbersome, complex, immobile and risky to support experimenting with new applications.

When I first commented on the i730 I thought that I “understood” the phone. OK, not really, but even so the story is a tad more complicated with regard to the Bluetooth aspect. There's a chart on Verizon's site (currently http://dts.vzw.com/images/faqs/bluetooth_chart.jpg but I expect it to change so I'm including it below (after OCRing it to turn it into a more usable form). It's also a bit strange in that it's an image rather than text and is at dts.vzw.com which their Data Technical Support site. That in itself is encouraging. I've found the data technical support people to be reasonably knowledgeable though often as puzzled as I am about Verizon policy issues.

It's that inscrutability which is at the heart of my concern and is also the essential difference between the traditional consumer products industries and the computer industry that I am used to. I look at the Samsung i730 and its ilk and see a computer with a radio. That's not very different from my desktop DIY PC that is connected to my LAN. DIY is “do-it-yourself”. Instead of having Mike Dell assemble the machine for me I do it myself. The resulting machine isn't very different. In fact, that's how he beat out Compaq – instead of doing his own engineering he just assembled machines out of commodity parts. While Dell has some advantages in buying in large quantities and the ability to do some custom engineering I find the ability to pick and choose and modify my machine to be a significant advantage and, as I have written in other essays, there is a large DIY marketplace.

The landline phones themselves had a strong DIY aspect because the simple two-wire interface made it easy to mix and match phones with lines even as TPC (The Phone Company, mostly ATT) tried to say that it was too risky – an argument that even the US Supreme Court rejected. A phone company doesn't sell telephones; it sells telephone calls – a service. The ability to connect our own telephones didn't really threaten that model. The computer modem was a very different device but it still didn't threaten the service model because the phone companies didn't offer computer services and, in fact, the courts eventually prohibited them from doing so because that would have turned computing into a service! Yet today the courts are calling the Internet a service – hmm … an interesting topic that I will pursue in another essay.

The real threat came from the answering machine which started to take control over a “telephone call” away from the phone company. As I am wont to point out with Voice over IP (VoIP) that landline game is pretty much over and the battle is now over control of cellular telephony. With EVDO I don't need cellular telephony either – I can use Skype to do all my telephony. As another aside I don't want Skype to become another phone company and am glad to see some competition appearing but saying “Skype” is simpler than saying “simple just works voice over IP”.

Actually, Skype over EVDO does have a problem with delays because of QoS – Quality of Services. This is why QoS is such a terrible idea! It gives absolute priority to a particular kind of telephony and severely disadvantages innovations. Skype does telephony even better than the CellCos do but the QoS policies discriminate against it. EVDO isn't “QoS” as such because the policies are embedded in the architecture which makes it more than just a matter of priority. Over the long term it's the architecture and hence cellular telephony that must be abandoned in order to fix this implicit QoS model.

Before we get too far-a-field back to the Bluetooth chart. I was surprised to find that DUN (the dialup networking) profile is in fact supported on the Audiovox XV-6600 which is also a PPC (Pocket PC) or “Smart Phone” with EVDO. Either the policy changed or there is another reason for eliminating DUN from the i730. My wont is to assume that it's still a policy decision until I hear another explanation. After all, why can't I use Wi-Fi and the cellular radio at the same time like I can with the HP-6315? Given that I can receive calls while using Wi-Fi there doesn't seem to be a technical reason for disabling that combination.

I don't want to get too conspiratorial since there needn't be a single policy at work here. There is a bigger issue which I call the PLH problem or “don't worry your Pretty Little head”. The paternalistic dependency implicit in such policies can be indistinguishable from policies that try to prevent the user from getting control. After all, if you are making a product you want to make sure it works and if you let the user open the box and fiddle with it you'll have problems assuring the product works.

The complexities of cellular telephony and the problem of fitting all the functionality into a little phone make it “obvious” that the user shouldn't be able to do damage. The complexities of cellular telephony are due to an outmoded model of “wireless” (the word stood by itself before “radio”) and is a separate topic. For the moment I'll accept that we have to assure the device behave well lest they damage the fragile cellular system. As another aside, that's why you aren't supposed to use your cellular phone in an airplane – the old analog cellular systems were confused by phones in the sky rather than on the ground. This is no longer a problem but the policy persists because folk theories made the ban seem to be due to safety concerns.

Bluetooth is at the intersection of many issues. It was originally developed to meet marketing requirements which focus on end-user scenarios. This is normal in creating consumer products but is also creeping into the PC world in the guise of task-oriented scenarios. As people complain about how difficult it is to perform a particular task on a PC there is a tendency to make that case work.

The idea is that if you collect the scenarios you can greatly improve the user experience. It turns out that this strategy seems to work and then hits a wall because of the tendency to view the scenarios as “products” rather than “constraints”. Instead of using the scenarios to test the underlying architecture they are viewed as problems to be solved and functionality that is at odds with the scenarios may be removed or made difficult to access. Often the problem is solved by using wizards that do that one thing correctly but don't leave the user with the ability to tweak the solution. A far more effective approach makes the familiar scenario a starting point for learning. Once the system does what you want you should be able to learn how to take advantage of the additional capabilities rather than being limited to what you first asked for.

There is also the tendency to try to solve a problem in isolation. If wireless links, as in 802.11 expose a security problem it gets fixed as if it were peculiar to 802.11 (Wi-Fi for those confused by branding) rather than recognizing that the real problem is with the network connection in its entirety – form one end point to another. So we find a tangled mess of hacks for the wireless link (WEP, WPA or whatever) rather than a simple end-to-end security model.

IrDA, Bluetooth's infrared ancestor (which I sometimes call Redclaw) essentially failed because each application was a special case and required pair-wise setup. IP connectivity is simpler because you can deal with browsing, for example, without worrying about whether it is IR browsing or 802.11 browsing. (Yet another aside, the concept of the intra-LAN breaks this model but that is yet another topic, YAA and YAT)

Bluetooth is not really a conspiracy to keep cellular phones locked down. It's simply another protocol in a long tradition of consumer electronics protocols and telephony protocols. It is an attempt to meet a number of complex constraints while assuring that it's easy to do something like using a headset with your cell phone.

The big constraint is that the whole set of protocols from the support for the user experience to managing the radio has to be baked into silicon years before there is wide usage. It has to assure long battery life, interoperability, security, and reliability while be certified to be part of a cell phone. Since you can't simply replace a hundred million cell phones you have to essentially get it right the first time.

The 802.11 approach is much easier – just make a general purpose radio that doesn't care about the contents of the packets or overall network capabilities. It doesn't do a good job at power management and its access point vs computer-computer model is awkward. (YAA is IP itself but that's YAT). 802.11 also benefited from years of experience with networking that yielded standard interfaces to a generic packet layer and a while suite of applications that worked above that layer using TCP (and UDP) so you could just swap out the LAN packet layer and replace it with an 802.11 packet layer.

With Bluetooth you can find books that present the whole protocol suite from the radio to the application. You won't find such a book for 802.11. OK, maybe you will but the elements are far more decoupled. In theory the Bluetooth approach has the advantage for the scenarios because the designer of the headset protocol, for example, is cognizant of the need to preserve battery life. In practice it creates stifling interdependencies and complexity and each solution has a low ROI in that it is optimized for the particular environment.

So, back to Bluetooth … pause for a few hours … I decided to drill down and understand Bluetooth better rather than just complaining and guessing. I did manage to install the Bluetooth SDK from Microsoft and also have a few books on Bluetooth. The short answer is that almost everything is about either the user's view of Bluetooth applications or programming specific connections. I'm still not sure if I can add my own profile implementations to the phone. I presume that I can eventually figure it out and that's the point. “That” being ambiguous.

One point is that Bluetooth is in the embedded systems mold. Embedded is aimed at manufacturers and doesn't benefit the user directly. It's underneath the device and inaccessible. It's still computer software using the same programming techniques but it's locked away. Bluetooth is considered part of the low level guts of the cell phone – I can read the documentation but it's a “given”. This is also closely related to the assumption that you must define solutions rather than just provide users with capabilities.

The other point is that the users are getting increasingly skilled at being able to pry control away and make the devices open even if the manufacturers didn't intend them to be.

In many cases manufacturers and industries fight this. Sony keeps trying to prevent people from turning their PSP machines into general purpose computers. More important is the battle over “Digital Rights Management”. While it is typically portrayed as a fight over piracy it's really about innovation. Right now, for example, I have two 1920x1200 monitors that are far better than any HD TV I can buy but Tellywood is determined to thwart my attempt to improve their content. They will only allow me to watch their video streams on approved monitors – they want to get inside any device in order to make sure their restrictions are honored. This is why HDTV is moribund and generating a lot of press but very little forward movement for the last decade.

Cellular telephony has one advantage over Tellywood – it already has complete control. This control is sustained by the complexity and fragility of cellular protocols. Cellular phones are devices built for a very specific purpose and all the design decisions are locked into silicon. This is the norm for consumer electronics – design the product for a purpose and then replace it with a new model rather than upgrading.

The devices are typically assemblages of standard parts connected using standard protocols. Because the form is the mechanical aspects make it difficult for individuals to build ones themselves. In the case of the cell phone there's the additional protection of the Regulatorium – the rules that require that the device be certified and make mucking with the phone illegal.

A cell phone consists of software as well as hardware components. In a standard cell phone these components are embedded in the device so there is little distinction between hardware and software capabilities though, increasingly, the devices can be upgraded to fix problems. Verizon suggests dialing *228 to update your cell phone on a regular bases. (YAA – why don't they do this automatically or at least offer to?)

My first PDA phone was a Handspring Visor – the “phone” was an add-on component separate from the phone itself but did communicate with main computer so it could dial and change settings. The division between the computer and the “phone” obvious. When I had a 1xRTT PCMCIA card from Sierra Wireless I was able to plug it into my PC or my PDA and place calls but I had to use a separate jack for a voice call. The successor EVDO card doesn't even support voice at all.

For PDA phones like the Treo and the Pocket PC Smartphones the division is less obvious. It's hard to figure out what is going on because I am not the customer for the Bluetooth stacks. They are sold to companies building embedded system which want to add Bluetooth capabilities. The APIs are typically above the level of the profiles. That said I'm assuming there is a way for a user to supply a profile because they are layered and there is access to the lower layer. For now this issue is open. (YAA – I really want to get to the native location capabilities also even if they don't provide high resolution GPS information) (YAA – one reason for wanting to have Wi-Fi available is that I can scout nearby access points to guess where I am)

These “Smartphones' (SPs) are somewhat open already. For example, I can just drop a Window's WAV (sound file) into the \Windows\Ringtones directory and use it. When the phone is connected to the PC it shows up in the Windows file explorer on my desktop and I can just copy the file over. I plan to write more about the relationship between the PC and these devices and the problems and limitations but from the point of view of a phone carrier they are already quite open – maybe too open. I can just use Skype to make phone calls and not use their voice services at all.

More telling is that the picture messaging and other services are typically not available but since, underneath, it's done by email I can do it myself. I don't need to figure out Verizon's wireless “sync” because I can just query the POP server on my desktop from the phone. I can even implement my own “push” using SMS and trapping the SMS message in my own software. Push to talk can be done in the same way. In fact, if I implement it myself I can do far better and implement various group Ptt (Push to talk, not Postal Telephone Telegraph!) implementations using the packet data path.

Once I start thinking about it there's so much I can do with a connected computing device. The only mystery is why more people aren't doing such projects. Personally I'm partial to Microsoft's Compact Framework because it makes it easy. There are other programming tools but many are typically sold to corporate developers with slow programming a tool of discovery.

One lesson is that the generic devices win out over special purpose devices. It used to be “obvious” that a general purpose computer was more expensive than a word processor but that's no longer true. The ability to manufacture a standard device in very large quantities is one factor but more important is the ability for developers to add and share value. Remember that it's not just cost but value – that's why you can't even find a phone with a monochrome screen anymore.

EVDO is a weak proxy for native Internet connectivity but it's a start. The latency is noticeable during a conversation but tolerable if there are other benefits. Non voice applications are less sensitive to latency. It wouldn't take too many native applications to make such a device a necessity.

The PDA phone itself is not a new device – the Handspring Visor phone is now an antique. The Samsung i700 and HP-6315 are quite capable. The reason I'm so interested in the i730 is that EVDO does bring connectivity over a critical threshold and there is sufficient EVDO coverage to assume its availability. The i730 is also “cool”, at least according to my in house staff (AKA, my style-aware son).

There are also Linux-based Smartphones but, unfortunately they do not appear to be available in the United States because the carriers, AKA, The Orifices, decide what is available and what features we are allowed to have. Too bad because GSM/CDMA Linux-based phones already exist.

The other big issue that I will be writing about separately is the nature of the Internet itself. The current protocols don't work well in dynamic mobile environments. The Internet is a network of local area networks. It was not designed to maintain relationships between mobile devices and the lack of protocols, such ubiquitous encryption make it difficult to casually share ones connectivity (though many access points are open anyway). Improving these protocols is important though applications like Skype do work around them.

Skype could do more to make the cell phones work better with their network by adding the code to explicitly connect to the network to place calls and it could use SMS to broadcast a “please connect” message to phones. For now the market is too small to warrant such efforts. As the market grows the platforms themselves will provide solutions or the applications can work around them.

And that's the key – the carriers can slow the process down but the hackers, those users who experiment and learn about how to make the devices work for them have the advantage. The term “hackers” is associated with disruption and piracy but that's marketing hype. Think of them as explorers even if some may be sociopathic. The vast majority are excited by what they can discover and are thrilled to share their discoveries with others.

It's easy to demonize the carriers such as Verizon. It's also necessary because we need a simple message. They are the orifices we must pass through in order to take advantage of connectivity. Bluetooth is bad because it gives us rigid solutions rather than opportunity.

The real story is more complex. It's about a collision between business models and world views. From experience the more open approach will triumph because of the number of those who can add value but progress is slow and difficult because the carriers have a very high degree of control. Some of this is explicit policy but much of it is implicit in an infrastructure built on complex and interdependent protocols and relationships within the context of a regulatory model based on century-old assumptions about wireless communications.

Incremental policy changes do help. The programmable phones, AKA, connected computers, allow us to experiment and explore the ideas and possibilities. Each generation gives us access to a new level of capabilities. I'm particular enamored with the Samsung i730 because of its capabilities and it looks like a phone. But it's just a step along the way.

Once we reach critical mass, the tipping point, wireless connectivity, like landline connectivity will escape the carriers control and we'll all be richer for it.