GSM Asia Macau November 18-20 20008

Just finished two days at the Exhibition of the GSM Asia conference in Macau. After ten years or so of attending the major European event for the mobile industry, I thought I should checkout the Asian equivalent. I wrote a list of what I wanted to see before I got there and hoped to find ideas to help me to point my business Dialogue Communications further in the right direction.

So what did I find? 

The first thing which can't be ignored is that the show is tiny compared to the 3GSM show in Barcelona which is almost too big to do any business. There ware around 180 exhibitors according to the publicity, but I felt there were even fewer. They  split broadly as follows:

1. A few major telcos: China Mobile, CTN, Orange, Telenor.

2. A couple of handset providers, none of the big ones and no new handset announcements. I was hoping to see the HTC Android phone, but no luck.

3. A few infrastructure companies, particularly ones selling into China.

4. Most of the rest were application companies in various states of maturity. I will concentrate on these as they were the most interesting.

Application Companies

The application companies were mostly European and looking to sell their wares to the Asia Pacific market. As one would expect they were mainly trying to sell to the mobile carrier community (the GSM shows are really a beauty pageant for the mobile carriers to see what is around).  What I found interesting was that whilst there were a few client only or server only application companies (e.g. serving mobile sites, delivery content or providing ringback tones), the majority had a client and server strategy. Typically it would work like this:

Java client on the handset.

There would be a J2ME client on the handset which would do to something cooler than a normal handset. In some cases this was display full screen advertising whenever there was an inbound call or SMS. In other cases it was form filling to construct SMS and then encrypt it to get to the server. There were also several mobile banking applications which did typical banking type activities.

Smart server either inside our outside the carrier's own IT environment.

In the case of Broca this would be some server which could decode the encrypted SMS forms. In the case of Frog2Frog it was a server which would provide the adserving and reporting. In the case of GIgafone's 'Ringmate' it would provide the advertising to be passed to the client.

The think which to me was facinating about these systems was the difficulty of providing a credible solution in a cost effective way. Here are the challenges:

Challenges to Client/Server application providers.

1. Supporting multiple client platforms. In order to have a 'whole market offering' one must support the following environments: Symbian (various flavours for different Nokia series and Sony Ericsson), J2ME for the non-symbian phones from the far east (e.g. Samsung), Blackberry (increasing its market share at the expense of Nokia at the moment), iPhone (again increasing market share at the expense of Nokia), Windows Mobile (big in the states), Android (will be big and has Motorola support). Plus there are many carrier specific implementations of these environments. It is almost impossible to keep up with the demands of providing applications for all these handsets unless you are very well funded and/or can sell a huge number of applications. Therefore we have to consider how happy the carriers will be when the real world fact of patchy market coverage hits home. I may be very wrong about this. I do remember that in 1997 I thought ringtones wouldn't take off because they sounded rubbish and only worked on Nokia phones. So beware my advice!
2. Servers that must be bought and hosted by carriers. Admittedly not all are in this camp, but several are. At the present time carriers are not too keen to find CAPEX so this is a bit of a challenge. 
3. Servers that must be populated with information from the carriers closely guarded databases. This is a bit of a challenge too, but if you want to do the best job of ad-serving then you want to get hold of this sort of thing.  

So faced with these challenges I ask myself why these companies would not simplify things a little in order to help things along?

Simplifying the product set.

1. The first thing I would do is to do away with the handset application. The iPhone webapps style of working is the way I'd go. Build a mobile web site which is very optimised to different handsets. In the case of the iPhone it is difficult to know which is a webapp and which is an iPhone app in some cases. The advantages of this is that it is easy to develop, deploy, maintain and delete. The disadvantage is that it needs mobile web access and may not look as good as an 'on device application'. But I can live with that.
2. The second thing I would do is to remove the need for CAPEX and installation at the carriers premises. These are two things which will ensure there are no quick sales. So I'd either work with 3rd parties who are already well embedded with the carrier, or have a standalone operating model of the server side which can give the carrier 75% of the functionality out of the box. 
3. The third thing I'd do is to come up with some very flexible pricing models to suit the carriers view of the world. I won't go into too much of the detail here, but if you get it right you'll make sales and then make money.   

Back to my list of what I wanted to see at the show. I've just looked through again and have ticked about 10%. I did actually see that many of the companies exhibiting were clever but not resourced well enough to take their products overseas. I felt that there were good opportunities for Dialogue to strengthen its own proposition and to help to promote some of these companies into our increasing range of territories. This wasn't on my list of what to see at the show, but it is nice to be surprised.

Summary

So to summarise how things looked to me. GSM Asia was a bit disappointing in the number and depth of companies exhibiting, however there were some interesting gems amongst those I saw. I like the client/server application model but worry that it is too ambitious to really get traction in the real world market we are working in. I wish the creators of these systems well however and will be happy to be proved wrong.

Comments

[Hugh Sheehy]

Hi,

An interesting blog. I'm happy to hear your ideas.

You've raised some questions, so let me address your thoughts in a couple of areas...

(1) We have ways of deploying the service without needing a client. Email info@frog2frog.com and you can get into more detail. In any case, the target market for ad supported services - the MASS market - don't use Blackberrys, and iPhone penetration is still quite low. It sells well, but it's not hugely penetrated into the market yet. Meantime, J2ME works well enough on most Symbian phones...at least for the initial services that we wish to deploy. Symbian offers some nice "Phase 2" features but they're not needed on day 1.
(2) Operators do not need to pay CAPEX for deployment. They often choose to, but they don't need to.
(3) The way that we work, the operator's data remains the operators data, or rather the user's data remains the user's data. The system can use the data to serve ads, but we are VERY serious about NEVER letting any operator or user data go anywhere except where it's supposed to be.
(4) We have several different pricing models, depending on how operators want to work.

Thanks for mentioning us. I hope you met Hans-Peter while you were in Macau!

Regards

Hugh