Amazon Tech Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Monday, 15 December 2008

Ericsson as handset API broker?

Posted on 02:23 by Unknown
According to this article, Ericsson is talking up a new developer initiative aimed at trying to establish a common API across a variety of different handset platforms.

At one level, this is a very sensible concept - I've been trying to convince network-side manufacturers that they take the phones for granted for years. Numerous network technologies - 3G, IMS, UMA and potentially femtocells - have been delayed or rendered useless because the infrastructure or standards folk thought that the phones "were the easy bit". And while implementing some of the "hard" nuts-and-bolts protocols is occasionally simple, that certainly can't be said for the "soft" user-facing applications and all-round experience. I wrote about delays in creating IMS-capable phones 2.5 years ago, and we're still waiting for things like RCS.

In an ideal world, the network would be "exposed" to handset-based apps, and the handset "exposed" to network-based apps. The network would know (for example) what the phone's battery level was like, or if it was on charge, set to "silent" or had limited available free memory - all valuable data for applications. And it could help guarantee security through certificates or other mechanisms. Conversely, a handset-resident app could query different networks' levels of congestion, speed, price and choose the best one (obviously a lot of server-side APIs are already standard, courtesy of the web).

My concern is that Ericsson may not be the best-positioned or most neutral broker - especially if its proposition is based on Java and IMS as this other article suggests. If there is to be a successful common API, it absolutely needs to work in BOTH operator-controlled and 3rd-party-controlled fashions.

As a baseline, it needs to be absolutely neutral towards the philosophies of "over the top" or "through the middle" application architecture. It's fine if its *implementation* can be skewed one way or another in different contexts, though. For a handset provided by and subsidised by an operator, you'd expect there to be optimised applications and control/billing suited to the carrier's preferred platform, whether it's IMS or something else. But for an handset provided through other channels - and especially if it is subsidised or provided by a non-operator player (maybe Apple, Google, Cisco etc), the converse should be true.

There's also an large open question about how this fits with initiatives like OMTP's BONDI, which is "addressing the problem that an application written for one phone must be rewritten again and again if it is to work on all phones" (sound familiar?), but which is using a web runtime and browser/widget world-view, rather than Java or IMS. That said, Ericsson's also a sponsor of OMTP, so presumably there's some alignment going on in the background somewhere.

I haven't heard full details yet, so I can't really give a comprehesive opinion. I'd love to be a fly on the wall in their meetings with Apple and Google, though...

EDIT:I just re-read the last paragraph of the EEtimes article, which talks about browser-based application environments, so I'm now a bit confused between the mentions of web, Java, and IMS involvement. I'll try to track this down.
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Quick musing on Cloud Computing
    I just heard the phrase "Everything as a Service" during a presentation on Cloud, SaaS and other forms of managed service offering...
  • Apple, embedded SIMs, NFC and mobile payments - some speculation
    I wonder if I've just managed to join up the dots on something rather important: - Recent reports suggest that Apple is intending to use...
  • New Cisco VNI traffic report out
    One of the broadband industry's "bibles" has been published in a 2010 edition . Cisco's "Visual Networking Index...
  • Is the MID a market?
    MIDs (Mobile Internet Devices) are being pushed by some notebook OEMs and silicon suppliers as the next big convergent handheld category. I...
  • "You can't use my eyeballs for free"
    Let's look forward 10 years. We've all got augmented reality browsers on our handsets, or perhaps our 4G-connected sunglasses. They ...
  • Mobile traffic management - the Inter-technology war begins
    I've been following the proliferation of mobile broadband traffic management technologies for some considerable time now, having publish...
  • Pre-MWC notes for analyst relations staff
    OK, it's the time of the year when I get bombarded by emails and phone calls from a million people inviting me to briefings and similar ...
  • Mobile operators' future voice strategies decoded
    Apologies in advance, but this blog post is deliberately a bit of a tease. I'm not going to spell out the answer here, as it's too v...
  • Hosted mobile services in the recession - Caveat Emptor
    I used to work as an equity analyst at an investment bank back in 2000-2001. I remember an unending stream of first generation Application S...
  • Challenges in measuring offload volumes
    I suspect we're going to get bombarded with statistics in the next year, along the lines of "Operator X deployed Vendor Y's off...

Blog Archive

  • ►  2013 (31)
    • ►  October (2)
    • ►  September (3)
    • ►  August (1)
    • ►  July (2)
    • ►  June (6)
    • ►  May (5)
    • ►  April (1)
    • ►  March (3)
    • ►  February (3)
    • ►  January (5)
  • ►  2012 (46)
    • ►  December (5)
    • ►  November (4)
    • ►  October (3)
    • ►  September (2)
    • ►  August (4)
    • ►  July (3)
    • ►  June (1)
    • ►  May (6)
    • ►  April (4)
    • ►  March (1)
    • ►  February (9)
    • ►  January (4)
  • ►  2011 (73)
    • ►  December (4)
    • ►  November (10)
    • ►  October (8)
    • ►  September (6)
    • ►  August (3)
    • ►  July (5)
    • ►  June (7)
    • ►  May (9)
    • ►  April (4)
    • ►  March (7)
    • ►  February (6)
    • ►  January (4)
  • ►  2010 (130)
    • ►  December (4)
    • ►  November (10)
    • ►  October (10)
    • ►  September (6)
    • ►  August (9)
    • ►  July (7)
    • ►  June (19)
    • ►  May (19)
    • ►  April (11)
    • ►  March (18)
    • ►  February (7)
    • ►  January (10)
  • ►  2009 (126)
    • ►  December (4)
    • ►  November (14)
    • ►  October (9)
    • ►  September (8)
    • ►  August (9)
    • ►  July (10)
    • ►  June (21)
    • ►  May (14)
    • ►  April (2)
    • ►  March (11)
    • ►  February (15)
    • ►  January (9)
  • ▼  2008 (94)
    • ▼  December (24)
      • Notifications and "keep-alives" from mobile apps -...
      • Disposable mobile broadband - my experience
      • My 2008 predictions - how did they turn out?
      • "Third-party pays" mobile data
      • Interesting FAQ about the Vodafone Dell netbook
      • Ericsson as handset API broker?
      • Handset brands moving into dongle market
      • Two famous places
      • Who pays for an unused 3G module in a laptop?
      • The danger of "cutting the cord" - where's the fem...
      • New Report:Mobile Broadband Computing - Device & B...
      • MIDs, netbooks, UMPCs, smartphones: some quick def...
      • Google's using my pipes for (almost) free! ... Whi...
      • Embedded-3G modules for notebooks still expensive
      • Downturn driving an increase in mobile payment def...
      • 2009 is going to be painful for device vendors
      • LTE+WiMAX dual-mode is inevitable
      • Truphone on iPod Touch.... cool, but...
      • Rant: I am not a blogger
      • Government remote access to data on PCs (and phones?)
      • The mobile industry buzzword of 2009 will be......
      • Inside-out deployment of LTE using femtocells
      • Mobile broadband business models: free dongles as ...
      • EU intervention in mobile - a double-edged sword
    • ►  November (26)
    • ►  October (25)
    • ►  September (19)
Powered by Blogger.

About Me

Unknown
View my complete profile