Wireless Wonders

No news, just comment about mobile phones and services, from a veteran practitioner...3G, GPRS, WAP, Bluetooth, WiFi, etc...

Saturday, June 11, 2005

Cell Spotting...

In my post about Always On GPS, I suggested sharing the location tables for WiFi between users. This would enhance the database and improve coverage and accuracy for this hybrid-location technique.

Besides sniffing for WiFi access points, an alternative is cellular cellsite detection, which, of course, is how mobile operator solutions work (in various forms).

Thank you Chris Peterson for pointing out Cell Spotting, which does exactly both: it detects cells and allows users to update a central database of cellsite information. Cell Spotting is an open project outside of operator control.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Mobile network as OS or intelligent bit-pipe? ...

In an email exchange with David Gumbrell, I was explaining how location-based services were evolving only slowly because of lack of serious support from operators to open up their location platforms. This is only part of the story. For dynamic (i.e. proximity-sensing) location to work and to get high-accuracy, almost certainly means a lot of investment.

David's comment about the whole approach to open mobile networks is worthy of reflection:

"Seems to me that the operators would make a lot more money if they followed the Microsoft model: create the eco-system and provide the tools for 3rd party development. Spot the best emerging solutions and borg-ify them. Certainly more successful than the original "we control everything, you don't get to blow your nose without permission" IBM model they are currently following. As someone has pointed out -- it's not actually about killer apps, it's about recruiting the individuals that invent killer-apps."

In particular, I like the point about recruiting the individuals to invent killer-apps, although that term is problematic (e.g. see earlier point about "compelling applications").

It isn't about recruiting them into the operator world, because, as we all know, interesting stuff in technology happens on the outskirts. Attracting developers and entrepreneurs to the "mobile network operating system" almost certainly means it needs to be highly accessible and - if we follow recent Internet trends - open source.

What is an open source "mobile network operating system"? I have ideas, as do others. But just asking the question itself is useful. The latest answer might be "IMS", but I don't agree. IMS is only a partial solution.

Wherever you go with the "opening the network" discussion, it almost always leads back to a view that operators must eventually become bit-pipe operators, which currently they aggressively resist.

With David's point about the OS model, might we slightly re-align that statement to say that eventually they must become "mobile networked OS" providers, or - more subtle - "intelligent bit-pipe providers".

The usual assumption is that the "on-ramp" model of flat-rate dumb broadband provision in the ISP world is what mobile operators want to avoid. However, this assumes that mobile and fixed access are essentially the same except for the access technology itself.

I don't buy that.

The mobile environment is different. The email versus texting "debate" highlights the difference, despite many instincts (misplaced) to view these environments as being the same, or convergent on the same end-point.

If the intelligent bit-pipe or mobile OS model has a future, then what attributes would such "platforms" have that make them sufficiently sticky that users would stick and providers would reap sizeable revenues, at least better than what is otherwise assumed for commodity bit-pipe provision?

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Friday, June 10, 2005

BIG screens - who wants them?

Mobile phones have got smaller and smaller. They fit nicely in shirt pockets, handbag sleeve pockets and so on.

For some mobile data services to work well, we need bigger screens. The common argument is that no one wants to carry around a big device. We have become spoilt with tiny clam-shell jewels in our pockets.

However, I'm not sure I agree.

The kids on my street regularly walk aroung carrying Nintendo DS and other such portable gaming machines - hardly small!! If the need and desire is there, carrying something larger than a dinky phone is not such a big deal.

Will these kids find the transition to mobile entertainment devices that problematic? I don't think so.

Also...we just need bigger shirt pockets and it's about time trousers (pants), including formal trousers, came with device-friendly pockets! Are we stuck on size here?

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Thursday, June 09, 2005

Always On GPS...

James Parsons contacted me to let me know about Always On GPS. This is a Pocket PC application that enables constant GPS operation even within GPS shadows where ordinarily GPS stops working, like urban canyons and indoors.

It works by constantly scanning for WiFi spots and then correlating these to GPS co-ordinates whenever GPS coverage allows.

Clearly, the effectiveness of this technique is highly dependent on the geographical coincidence of WiFi radiation with GPS coverage in the margins. A table of WiFi-GPS coincidence needs to be built. Hence, performance is going to be variable from one area to another because of the reliance upon WiFi radiation to fill the gaps, which is going to be highly location dependent.

The solution also requires training in order to build up an internal coincidence table. I don't know if the designers have thought about a networked version that enables users to share tables. Theoretically, this would improve accuracy and the training process. It would also enable users to move to new areas that would not otherwise be in their device training table.

This is an interesting variant of a hybrid location-finding system and one that circumvents mobile operator involvement. I'd love to see a WiFi coverage map for a city area in order to understand better the potential effectiveness of this approach.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Wednesday, June 08, 2005

Offline content distribution...

There is an increasing interest in allowing mobile users to access content offline. I posted earlier about SurfKitchen, which is a customisable user interface client for mobiles, but with an offline capability via some form of "push".

Other players include Silk, whose customisable client also includes the ability to work with Flash Lite. The Silk content delivery solution allows content to be pushed continually to handsets over-the-air (OTA), although this is essentially implemented via a polling channel.

Another player in the market is Austrian 2K Development with their jbag.net solution, also allowing data content to be pushed for subsequent offline viewing.

These developments are interesting from a number of perspectives. Firstly, the richer user experience is a key driver. The aim here is to exploit the now well-established principle that usability can drive usage, which drives conversion rates (hits to money). Clearly, the usability of WAP-based presentations is not cutting it.

Secondly, we have the emergence of an offline model for mobiles. I intend to discuss this with some of the offline players, because it would be interesting to know exactly what the key drivers are. Offline access to content was once considered important back when data coverage was deemed problematic. In other words, if I could only access my emails via a live connection, then being out of coverage is potentially a problem.

Ubiquitous and improved data coverage has lessened this problem, although not entirely. With 3G it should only get better and the improved data speeds lessens the problems of having to re-fetch data.

However, there are other advantages to offline content that are appealing. Firstly, and probably most important, the mere fact that content can be pushed to a device means that it can brought to the user's attention. This is the interrupt-driven model, which via other means (such as Cellticks cell-broadcast solution) has been shown to work.

Pushing the content is not enough. Richness improves the likelihood that the content will be viewed - and, more importantly - acted upon. The other advantage to pushed content is improved responsiveness. If the top 10 news stories or gossip snippets can be reviewed just by rapid clicking through, as opposed to waiting for each item to load from a distant server, then the usability experience is improved. Again, this can convert more easily to cash.

I guess what's worrying to me about all this is that these solutions aren't compatible and they are potentially closed (although that's always a possibility for any operator-deployed solution). If the offline content paradigm is valuable, which it seems to be, then we need a standard approach, which we currently don't have.

MIDP 3.0 are discussing the inclusion of a background communications mode, which could potentially support a push model for offline content aggregation. However, a background communications channel is only one part of the solution.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Tuesday, June 07, 2005

Common help format for mobiles...idea #63/100...

The mobile operator cartels should make using mobiles far easier. Full marks to T-Mobile UK for their online manuals for each device. However, I suggest that operators consider imposing a common online format for all device suppliers so that a central repository of phone manuals can be maintained by each operator.

The repository should be freely accessible (i.e. without registration) and easily located (i.e. not some buried link in the back streets of the web). Users should be able to locate their handset(s), or their friends' (e.g. parents') handset(s) and quickly discover how to use feature x, y or z.

Furthermore, the repository should also be usable as a resource for developers to allow them to compare phone features and specifications easily, which means that it should be searchable. Simple enquiries like "tell me all phones with tri-band support" should be possible, or "tell me all phones with MIDP 2.0"...all those questions that developers frequently post to various fora.

Would it be too much to ask that operators also give a clue as to which phones are currently being sold by them, which phones are the most popular, and how many of each (at least in percentage terms) are in circulation on their networks?

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

SIP and HTTP - the problematic comparison (hype)...

There's a lot of excitement in the 3G world about SIP - Session Initiation Protocol. In fact, a whole new approach to the core of a 3G network is being built around this protocol. The new approach is embodied in something called the IP Multimedia Subsystem (IMS). In my 100 ideas series of postings, I have posted some mobile application ideas based on SIP, such as Push-to-Taxi (for the others, search for SIP in my blog).

However, it seems that claims for SIP and the "SIP revolution" are often overstated, or at least problematic. The problem comes when the inevitable comparison is made with HTTP. A common theme in whitepapers and sales presentations is that just as the Web was built on HTTP, thus SIP will be the catalyst of the new "3G services world" (there's no neat name for it like 'web' - perhaps we need one).

This may well be true, sort of. But, the Web was not built on HTTP alone. The equally critical and symbiotic components were the browser ("universal client") and HTML. How many of us, way way back, were coding HTML and watching our grey-background pages magically appear in the browser without a clue about HTTP? It was almost incidental to the plot, except for that "http://" bit that did all the magic.

Even today, many website makers are blissfully HTTP ignorant ("HTTP - isn't that something to do with Apache?"). Plus, HTML coding has just got easier and easier with those wonderful things called tools, like Dreamweaver and its stable mates. Great stuff!

Of course, I know what SIP does. It initiates sessions and it does it well. And, granted, it is HTTP-like as protocol hacks will tell us. But that's it.

I also know that "rapid" might be true, which in telecoms terms means less than years to develop a service. "Low cost" is also true, which probably means a less than a few million. Whereas, in the Web world, working services can be created in months and at the cost of a few rupees per offshore coder - none of that ugly and expensive integration to worry about.

The real slight of hand though is the notion that IMS might be like the World Wide Web. IMS is an enclosed enclave in the cartels' networks whereas WWW is a million or so openly accessible servers.

However, I digress a little. What's the key point here?

HTTP + HTML + Installable desktop browser = genuine rapid service creation environment (just add creativity)

SIP + Other IMS bits I dare not mention = a bunch of interfaces

And...for completeness...

WSP + WML + Fixed WAP Browser = pain!

Believe me, I've worked with all these (still do) and I know the difference between an apple and an orange. Don't be fooled by the hype.




Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book