Recently in Rich Mobile Applications Category

The purpose of this article is to provide a summary of my findings from Informa's IMS/SDP (IP Multimedia Subsystem) North America conference that ran from the 5-7 November in Dallas TX; I gave a preview of the event in this article.  I've also put a few slides together to give a flavor of the conference at the end of this entry.  Overall the conference has the key players in IMS/SDP for North America in attendance; has the latest insights and initiatives being presented; provides a very frank and honest status check on the industry; and I think we're starting to see some practical customer focused steps forward such as the Rich Communication Suite initiative described by Feza Buyukdura of AT&T.

Mark Kaish of Cox Communications presented on "The Business Case for IMS in the Cable World: What is Their Vision?"
He provided an update on Cox's IMS experiences from an IMS / Packet Cable 2.0 trial, in which 8 applications where tested.  The most significant challenge as they move from trial to initial deployment is BOSS (Business and Operational Support Systems) integration.
The business case has proven difficult.  In the end they took a 'cost neutral' approach.  A critical yardstick is the total cost per subscriber (including integration and BOSS) for IMS.  If this figure can be shown to be close to the revenue generated they can push through action based upon the potential of IMS.  Mark indicated a ballpark cost figure of about $4 per subscriber, which requires a 'light-weight IMS.'
Other interesting observations, which have also been reported other operators, were:
  • "IMS Compliant" means nothing, each vendor is an island;
  • Integration remains a challenge between network elements, BOSS and with clients;
  • Internally developed applications took the longest, a simple SDK (Software Development Kit) for developers is essential to stimulate service innovation;
  • Mark echoed Andre Moskal's (Telus) comments on the need to 'believe' in IMS as the business case is just not there; and
  • The importance of Tru2way in opening up the STB to open innovation.

Feza Buyukdura of AT&T presented on the "Rich Communication Suite"

RCS is a broad-based industry initiative that soups-up the address book with presence to drive advanced communication services such as video calling, video share, IM (Instant messaging), file share, etc.  Think of it like taking a best of breed IM client onto the address book, and enabling it to work across operators.  This breaks through the networking effect which currently limits mobile video-telephony as discussed in the "Internet's Gone Video" article, is a critical step in the industry.  RCS is a bridge between now and OMA Converged IP Messaging (CPM) that utilizes the existing IMS standards and guidelines (no new standards) and focuses on inter-carrier interoperability (the critical piece).  The service uses capabilities provided by IMS, and is sort-of being positioned as a driver for IMS, but the actual implementation within an operator does not mandated a 'full' IMS implementation.  I recommend people keep an eye on this as it has potential - as long as it focuses upon the service and not trying to push IMS - to dramatically change the everyday communications experience.

David Moro of Telefonica presented on WIMS 2.0: Mixing Web 2.0 and IMS to get the Best of Two Different Worlds
WIMS 2.0 (Web 2.0 and IMS) is an initiative promoted by Telefónica seeking convergence between Web 2.0 and the telecom new generation services based on IMS (IP Multimedia Subsystem), to create innovative, appealing and user-centric services and applications. The WIMS website contains much more information.   Where as RCS is focused on an operator provided application that can run on IMS; WIMS focused upon opening up IMS capabilities to the web.  I think it provides an important technical experiment to demonstrate service innovation to help break the dam to open innovation.  However, I think the main problem facing the industry is around the operational and commercial changes required within an operator to step out of the way and let application developers and customers create value.

Lucia Gradinariu of the TMForum presented Service Delivery Frameworks and their Role in the Rapid Assembly and Commercialization of New Services
Providing an overview of the SDF, an integrative layer across the SDPs an operator has in their network, e.g. IPTV, IN, Messaging, content.  Enabling mashed-up or combinatorial services to be managed, e.g. provisioned, fault reporting, etc.

I also gave a brief presentation as an introduction to one of the panel sessions reviewing the fundamental change operators must react to, that is customers now expect to be engaged in a dialog with their service providers, and for services to improve in weeks not 6-12 months.  Simply customers' experiences with web-based service providers has reached a point where operators must react.  The success of Apple's App Store, with 200 million applications downloaded in just over 100 days since launch shows customers want applications.  Operators provide the ideal channel to market for many applications, with control over their network and devices, a billing relationship with the customer, a nationally recognized and trusted brand, high-street store presence, and a strong position in the industry's ecosystem. I then reviewed a number of operator initiatives in fostering open innovation and set out an action plan.  The punch line is: "It's NOT the Technology: It's your PLAN!"

Other comments / insights:
  • On Ribbit, one panellist commented, "BT has bought themselves $105m of cool."  But with non-standard APIs; the limitation of Flex; and a relatively small UK market (fixed centric operator): its unclear if there's enough of a market to stimulate developers to join the BT party once the hype dies down and people look to how they can make money.
  • Several operators admitted to having IMS installed in their networks with no services running on top, or if they did have services running on IMS they've been closed down.
  • Is IMS too old?  Given IMS was created when Web 2.0 was not mainstream, mobile broadband was not ubiquitous, HSPA+ was not about to deliver 20+ Mbit/s to customers, and inter-operator issues were secondary to the "walled-garden."  Does the architecture need to be reconsidered?  Is such fine grain policy control required?  Is openness and web 2.0 compatibility now essential (c.f. the WIMS 2.0 initiative)?
  • General consensus on the lacking of an IMS business case.  Which, as I discussed in several articles in the weblog means the focus must change from the technology to the commercial plan; implement only what is necessary for open innovation plan, rather than the backwards thinking of "How do I build a business case for IMS?"

HomeCamera enables people to securely see what's going on at home without being an expert in geeky stuff like DDNS (Dynamic Domain Name System), NAT (Network Address Translation) and port forwarding, which are generally required for the home surveillance solutions on the market today.  HomeCamera aims to be an easy-to-use home surveillance system, with any webcam, any PC, and any Internet connection; targeting the average PC user.  The service is live and currently free because its in beta.  Once launched it will remain free with ad-support, there will also be subscription models that add capabilities and remove the advertising.  When I talk to operators about this simple proposition the common refrain is, "We thought about doing just that, we just never had the time."  HomeCamera is a spin-out from M1 (Singaporean mobile operator).

Google averages between 100k-200k relevant search terms per week on home security and monitoring, so there's definite customer demand.  The estimated number of global broadband homes with webcams in '06 was 60m according to Logitech.  IDC estimates 21m webcams will be sold in 2008 alone; average annual worldwide growth rate of 9%.  More importantly to the HomeCamera proposition there were roughly 600k network cameras sold to homes in 2006.  A network camera is a standalone unit that is used for surveillance not web chat.  For example, D-Link has added HomeCamera support into its 2120 WiFi network camera.

The use cases include monitoring one's home, kids, the elderly, pets, and domestic help.  I also think HomeCamera provides a great example of how third party applications can use the Telco API.  Take this use case as a simple example: Jim recently hired a nanny to look after his two young sons.  When he's on the road he can check-in from his mobile phone, just to make sure everything is OK.  He also shares access with his parents so they can check in from their TV.  The operator could expose capabilities such as Single Sign On (from Jim's mobile phone or his parent's STB (Set Top Box) they can access the camera directly without the hassle of entering usernames and passwords), service provisioning (Jim can set up the service for his parents, all they need to do it press the widget button on their remote), IPTV and mobile video streaming capabilities (to ensure quality delivery of video to both his mobile and parent's TV without HomeCamera dealing with the hassle of video clients and QoS (Quality of Service)).

As discussed in the article on the Telco API, the operator could use this service either own-branded, co-branded or as a third party application.  You could imagine a scenario where it's an option on the operator's Family Plan.  The more challenging part is the business model, but as discussed in the Telco API article there are a number of options which generally will be dependent upon the customer and how the operator chooses to charge for use of its network capabilities.  My recommendation is the model must be simple, common across many applications, and at this point in the commercialization of the Telco API its more important to get out there and experiment commercially (continuous beta) rather than spend time crafting complex models and agreements.

As part of the SDP (Service Delivery Platform) workshop a run, I have a section on the ODP (On Device Portal), where I run through the ODP landscape.  I maintain a table of companies I consider relevant to the ODP Landscape, if you see any gaps or errors let me know, thanks.  During the years '05-'07 it's been a table that was becoming shorter, as start-ups in this space either ran out of cash, merged, or where acquired.  However, over the passed 6 months the table has nearly doubled in size, and more importantly the number of operator deployments is about 140 (some operators use multiple ODP suppliers so there is some double counting in that number).  This is a technology that has achieved mainstream deployment by stealth when you consider how little analyst and press coverage it receives, yet it's in the customers' face much more than iPhone, Android, WiMax, femtocell, or UMA.

In building up this landscape there are a number of categories I include:
  • Traditional ODPs that sell or work with operators, e.g. Cibenix, Nokia (MOSH, Download! and Catalogs), Surf Kitchen and Yahoo! Go: a client and a back-end designed to streamline and improve the presentation of specific content services to address the '3 Ls' of Latency, Look and feel, and Lack of availability.
  • Media focused ODPs, e.g. Mippin (previously RefreshMobile) and WeComm, which target brands and content owners with a solution.
  • Technology providers, e.g. Adobe with its suite of Flashlite, Flashcast, Flex, and AIR (Adobe Integrated Runtime), and as the originator of the RIA (Rich Internet Application) concept which was coined by Macromedia back in '02, but more on that later.
  • Browser based ODPs, e.g. Openwave (Midas) and Opera.
  • Home screen replacements, e.g. Abaxia and Zi, that focus an just making the functions of the phone easier to use.  As an example VoiceSMS is possible today on most phones by sending voice notes over MMS without the need for a network based service.  Samsung have made the UI (User Interface) easy on most of their phones, but try sending and replying with voice notes using a Moto phone.  Its no wonder Samsung in now the #2 phone supplier worldwide, taking Moto's spot. But this difference in experience is the problem such clients solve.
  • Mobile Widgets, e.g. Plusmo and netBiscuits: a new area and rapidly growing category that has an interesting overlap with PC based widgets that create some innovative experiences and business models.

The ODP market has been slow to take off for a variety of reasons including:
  • Handset coverage, operators (excluding NTT DoCoMo, SKT and to a lesser extent Verizon Wireless) lack control on software build in the phone without incurring significant cost;
  • Confusion on ODP's role as it's a client-server architecture not just a client so it must be intrinsic to the portal architecture;
  • Lack of integrated end to end solutions; and
  • Lack of standards and implementation norms.  

However, the factors that are now driving deployment are:
  • On mobile phones MIDP2 (Mobile Information Device Profile) has become more prevalent, which is essential for creating slick experiences and enabling the application to run from start-up and not require the user to do something.
  • Operators realizing that not all phones need to have the ODP.  The classic mistake was to force fit the ODP onto all current portfolio phones, which generally ensured at the lower-end there was a poor experience on phones that did not have the horse-power, which further encouraged customers not to adopt mobile data services.  Three and its X-Series campaign, demonstrated the power of restricting premium experiences to premium phones, so the user experience was cool.
  • iPhone demonstrated to operators that user experience as well as look and feel are more important than price.  The "Cult of Apple" is a great example of where people pay a premium for the laptops, MP3 players, and now their phones (and it's a phone that does not have Flash so most of the cool sites do not work).

ODP is evolving, with the emergence of mobile widgets which are analogous to RIA (Rich Internet Applications), e.g. Google Earth, its becoming RMA (Rich Mobile Applications), which opens the mind to a vast array of potential applications, not just making the phone easier to use, or making purchasing content easier.  Over the next 3 years as feature phones get more horse-power we're likely to see the ODP/RMA market evolve into a standards based browser that is either AJAX-enabled browser, Flash-lite and/or script-based 'widget engines.'

In this emerging environment important operator considerations include: the software already being on the handset, client-based so the back-end is not closed; an open and large developer ecosystem using the technology; and focus upon cross-platform services, i.e. mobile is not an island RMAs must also inter-working with RIAs in Western markets.  In developing countries where most people will experience the internet through their mobile handset, then RMA/RIA inter-working is not as critical.

The term 'on-device portal' (ODP) describes 'thin client' software that provides a graphical user interface to improve the presentation of content on mobile devices,  addressing the '3 Ls:' Latency, Look-and-feel, and Lack of availability (not always connected).

The ODP market remains nascent.  However, we've seen this year some significant steps forward with the selection of a java-based ODP by a global mobile operator, and that same ODP vendor being used in the 3 X-Series devices that enable eBay, Skype, Orb, Sling Media, etc. to be used from the mobile phone.  And additional rounds of funding coming into some ODP companies such as Action Engine.

In 2004 there was successful ODP experimentation by One (Austria) and O2 (UK), both experiments demonstrated >100% increase in content sales.  However, this initial success did not kick-start the market for reasons such as handset coverage, portal integration, market confusion, lack of end-to-end solutions, and the ODP's location within the mobile phone's menu.  This left the suppliers, of which there are at least 23 (Abaxia, Action Engine, Adobe (Macromedia), Cibenix, Geniem, Handmark, Motion Bridge, Motorola (Screen 3), mPortal, MSX, Nellymoser, Nokia (Preminet), Onskreen, Opera, Openwave, Qualcomm, Refresh Mobile, Silk, Streamezzo, Surf Kitchen, V-Enable, weComm), searching for ways to 'cross the chasm.'

Over the intervening three years a number of paths have been explored:

  • The ODP was extended beyond embedded content consumption, home-screen and discovery; into search, personalization, back-up, lifecycle management and advertising;
  • Proprietary solutions (non-java) and handset vendor specific solutions have extended handset coverage;
  • The operator has been bypassed with a direct to consumer approach; and
  • Some suppliers with a portal platform (back-end) have focused upon providing content delivery as a managed service.

One of the challenges with ODP is it created a device focus, the analogy to RIA (Rich Internet Applications) is better, because the back-end is equally as important.  The term RMA (Rich Mobile Applications) may be more appropriate than ODP.  The RIA term was created by Macromedia back in '02; Google Maps is a good example.  In the longer-term it's likely the market will evolve into add-ons to a browser on the phone, e.g. AJAX-enabled browser, flash-lite, or script-based 'widget engines.'  However, start-ups such as Zenzui are attempting to go head-to-head with this model.

But what about the here and now?  Some suggestions are:

  • Move away from the term ODP, instead focus upon RIA/RMA, drawing analogies to Internet successes.
  • Position ODP more clearly in the value chain.  An ODP by itself is as much use as a cart with no wheels.  Cibenix's positioning within the SDP Alliance is a good example of demonstrating the total solution.
  • Focus on a specific application, e.g. Voice2.0/Web2.0 mobilization.  The market is highly fragmented beyond voice and messaging, there is no 'one-size-fits-all' RMA.  Some customers will want anytime-anywhere access to Facebook, some will want to play Second Life, some will want to use their office's unified comms services, and some will only want to talk.
  • Target retailers / ASPs (Application Service Providers) as operators open up their networks.  This is critical because customers' content relationships already exist beyond the mobile operator.

About this Archive

This page is a archive of recent entries in the Rich Mobile Applications category.

Mobile Industry General is the previous category.

Service Platforms is the next category.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.21-en