Monday, April 30, 2007
My view that there might be something clever in the air interface bit (although most people I've spoken to have dismissed it as snake-oil), but even so, there was no way that a small RF company was going to be able to put together the whole value-chain including handsets, software, backhaul, authentication, application layer, network security and all the other 2000 "moving parts" that make up a working system.
Since then quite a lot has changed. Firstly, it has floated on the London Stock Exchange's AIM market. It has a scarcely believable £1.8bn market capitalisation [correction, the mkt cap should be US$1.8bn not £, even thought it's quoted in London the price is in $], given that it's had virtually zero revenues and clearly has a lot of risk attached, even if it's viewed as a potential future Qualcomm clone. For some reason it raised cash as "convertible preferred equity agreements of $120 million", although my financial knowledge isn't good enough to know if that's a good thing or not. It's missed its original end-2006 goal for launch of VoIP phones, which surprises me not at all. And it's claiming today to have shipped its first commercial base stations. (It's using 900MHz initially, so not usable in most of the world where that's used for GSM).
... but then I find this announcement. "The first system launch will occur in March, 2007 in Volusia County, Florida. The additional launches will take place in the second quarter of 2007. Far Reach’s deployment has been funded with $100 million by the multi-billion dollar US based Phoenix Foundation and underwritten by a major UK based bank. Far Reach will initially offer the first ever metropolitan area mobile VoIP, with internet access and data services to follow in November of 2007. In 2008 the service offering will expand to IP Television". The only Phoenix Foundations I can find are a New Zealand rock band, a Canadian charity foundation, and this rather weird one. Now it's possible that this is some shadowy hedge fund that stays well out of the limelight, but again, this is all raises lots of questions.
Bottom line: I'm still extremely skeptical.
Saturday, April 28, 2007
Ironically I'm possibly one of the very few people who could ever see positive ROI on metro WiFi, as I live in central London, which has the world's fiercest traffic wardens, and could therefore probably generate an extra £2 in parking fine profit for every £1 wasted on local WiFi.
Friday, April 27, 2007
Regular readers of this blog will know that I am broadly supportive of 3rd-party applications running on smartphones that enable innovative communications experiences. I coined the term "Naked SIP" to refer to phones with an open OS or Java plus a developer-accessible SIP stack, and I've also been a fan of both consumer and enterprise VoIP innovators. I regard it as folly for mobile operators to attempt to "block" things in phones or network, rather than compete head-on (with the exception of things like P2P that could break the network).
On the other hand, I also believe that operators can (and should) take sensible commercial precautions which make it difficult for others to eat their lunch, as long as it doesn't impact materially on the customer's reasonable expectations. So if they want to compete on which of them has the most "open" terms & conditions, or want to explicitly prohibit things like VoIP if you take their bribe of a free phone, that's fine. Things get a little bit more grey where they insist that use of Skype or Truphone or other third party services need you to sign up to the "over 18s adults only" content policy on the rather spurious grounds of child protection because of the messaging component. And adopting a stance of "well, you didn't ask the salesman if XYZ feature works on our version" is also not really reasonable when there's 100+ features, and when the typical mobile salesman doesn't know how to do his own shoelaces, let alone comment knowledgeably on VoIP.
So, inevitably, problems occur where these reasonable expectations conflict. Most phone users in the UK "expect" to have phones subsidised. High-end phone users "expect" to have access to a wide range of 3rd-party applications. Operators "expect" to have more control over the look-and-feel of their subsidised devices. Developers "expect" that phones will work fairly consistently across operator & vanilla variants with regards to APIs and certain embedded features. Hence the N95 debacle over recent weeks.
So, after a bit more research, some further thoughts on the N95 thing:
- To be fair to the operators, Nokia hasn't actually made a big deal over the native VoIP capabilities of the N95 (unlike some of its other devices), focusing more on the 5MP camera & GPS. VoIP isn't mentioned in the original launch press release , the UK full tech specs of the N95, or even the developers' main page about the phone. It does however feature on this developers' page listing VoIP-capable phones.
- However, to even a casual observer, the N95 has "geektastic" written all over it, so it's clearly going to be bought by people who like to download the coolest app they've read about on their favourite blogs. And who are the leading VoIP adopters & enthusiasts. And who like to complain vociferously about the operators' hegemony. You don't have to have been to many telecom events to see that E- and N-series WiFi-enabled devices are the VoIPistas favourites. So taking out or hobbling one of these customers' probable favourite features is asking for trouble, even if the subsidy notionally gives you reasonable moral grounds for doing it.
- My understanding is that Nokia & other handset vendors offer operators a "menu" of which applications/functions can be included at the factory in their specific variants of phones. The operators also have a bunch of their own applications they want added in, plus a range of modifications according to their inhouse UI template. Some (eg Orange Signature, Vodafone Live) are much more detailed than other specs, and go into a lot of detail about menu structures, what happens with phonebook & connectivity between apps. Now in some cases, there isn't enough memory to fit everything possible in, or enough display space to display all the icons without scrolling down for 27 screens-full. So some things get removed or at least hidden.
- Speaking to WDS Global the other day (which does outsourced technical customer support for the mobile industry), they commented that the biggest sources of helpline costs for operators are handset features that create configuration nightmares. Email is top of the list, along with setting up the phone as a modem, Bluetooth pairing and so on. VoIP/SIP/WiFi is probably going to appear on that list over the next year or so, I'd guess, so you can forgive operators who want to minimise their exposure to this. That said, the "techiest" users will probably fix things themselves anyway, and over time certain groups of consumers will mandate these features so removing them may be a false economy.
- There will be some interesting user experience issues that occur when phones have 2+ VoIP clients running simultaneously, especially if one is the operator's own or a close partner's. A lot of operators are looking at this, perhaps developing own-brand services (especially if they also have a fixed-line VoIP strategy) or are considering partnering with the likes of Skype, Truphone, Cisco, Fring or assorted others. In theory multiple VoIP services can work fine in parallel, but I'm sure that won't be universally true, in which case an operator might want to optimise for its own.
- Different VoIP applications use different bits of the underlying OS of the phone. Some use Nokia's own VoIP app as an engine (eg Truphone, Cisco) while others just use the SIP stack (Fring, I think) and others do virtually everything themselves (Yeigo, Skype). Some are intended as "primary line replacement" and so everything is done to integrate well with phonebook, call register etc, while others are more about embedding VoIP into an app like IM or gaming or conferencing. I have to say I was originally pretty surprised by Nokia doing their own VoIP - I thought they'd leave it up to 3rd parties, but clearly this is part of their "N-series is the future of the Internet" pitch.
So taking everything together, I don't think this is specifically some dark anti-Truphone strategic conspiracy, although it's clearly one of the key VoIP players that's ruffling a few feathers at the moment.
I think this is what happened here - "VoIP? Nah, we can't get any money from that, so ditch it or hide it, so we can fit the ringtones store icon on the menu" or maybe "no. that menu entry doesn't conform to specification section 18.104.22.168 subsection q and we don't have a testing plan detailed in volume 17 of the user experience manual". There's also possibly a near-term angle of "the out-of-the-box VoIP experience is going to be our own"
My advice to operators:
- Be sensible about what usage cases will be expected of particular new devices. If it's obviously going to be a techies' favourite, think about how they'll probably want to use it and work with them, not against them. It's not worth the grief.
- Feel free to be more draconian about your own "exclusive" versions of devices than you are with mildly-tuned generic ones. You don't really want to be competing with your rivals, or Carphone Warehouse or Expansys or Nokia's online store about "whose N95 is the best" . But if it's in a different plastic shell, and called an N96 or V95 or whatever, then there's no spec sheet up on Forum Nokia and developers have to call & ask you what apps and APIs there are available.
- Think about the knock-on effects elsewhere. You want people to buy your HSPA-embedded laptops at some point, right? Am I going to trust you not to have monkeyed around with it, if I perceive you as having "crippled" a high end "multimedia computer"[Nokia's phrase] in the past?
- Train your (and partners') sales & customer service staff. Put full spec sheets up on the web. Highlight any changes that impact on your customers' reasonable expectations. Ask your customers want they expect from different types of devices, and how they expect to use them. Bear in mind that those expectations are partly set by the manufacturer's initial press release, reviews & tech specs etc.
- Think about how multiple VoIP clients (or IM, or whatever) can coexist peacefully on devices. It's going to happen, so don't pull the blanket over your head & pretend the problem will go away. It won't.
- Have respect for popular 3rd-party developers, even if they compete with you. Especially if they're clever at using the blogosphere, Web 2.0 things like YouTube & PR in general. Bear in mind that you may want to partner them in future.
- Consider selling two versions of some devices, subsidised & unsubsidised.
Tuesday, April 24, 2007
... and some of them are supporting "2-in-1" multiplicity capability as well. 2 numbers & "virtual phones" in one physical handset.
Monday, April 23, 2007
The book is written by four people from the Swedish & Finnish arms of Ericsson Research, who are deeply involved with the 3GPP's new Multimedia Telephony standard, which is intended to underpin the long-term shift from circuit-switched voice to VoIP within IMS.
Lets leave aside for the minute the continued lack of a business case for IMS for cellular-only networks (another major European operator told me last week that aside from 'adjunct' fixed-VoIP, they couldn't see any major revenue opportunity or compelling new services).
Instead, lets think about different radio networks and their support for VoIP.
- CDMA: The specifications for EV-DO Revision A were approved in April 2004, with the earlier intention to create a separate voice/video technology EV-DV essentially having been sidelined. Subsequently, there has been a fairly concerted effort to support VoIP in Rev A, with Qualcomm & various other vendors and their top operators ensuring an end-to-end voice proposition is viable more-or-less from the start of Rev A deployment.
- 3GPP: Clearly, the future all-IP LTE (long term evolution) technology will need to support VoIP. However, the radio networks won't start to be deployed until (optimistically) 2010, with further dependencies on the upcoming SAE architecture and of course IMS. In the meantime, we have HSPA networks being deployed now (HSDPA plus HSUPA is just starting), with probably the enhanced HSPA+ coming down the line as well. HSDPA is part of 3GPP Release 5, and full HSPA (ie including HSUPA as well) is part of Release 6. Rel 5 was finalised in 2002, and Rel 6 in early 2005.
So it's not as though HSPA has been developed in a vacuum, without awareness and even early deployment of some forms of wireless VoIP. Which makes this line in the book's preface even more startling:
"it never occurred to me that there would be any interest in providing a high capacity voice channel over the HSPA channels we had created.... The outcome was surprising, when designing HSPA we had accidentally designed an air interface that was capable of supporting voice applications with higher efficiency than existing circuit-switched bearers"
Now lets ponder... what usually happens when a technology "accidentally" supports an unanticipated application? More on my thoughts on this over coming weeks.....
[If this topic is of urgent commercial interest to you, please contact me via email@example.com]
Thursday, April 19, 2007
And then I saw a link on ForumOxford mentioning this - it appears that some operator-specific variants (Orange & Voda have been named and shamed) have the native VoIP capability crippled, and also apparently don't work with downloaded 3rd-party VoIP apps like Truphone's.
This is very interesting as I had a conversation last week with a senior devices honcho at one of Europe's main operators. He actually made some slightly opaque references to removing some of the native VoIP capabilities from smartphones, but he described it more about stopping Nokia (or whoever) from putting Skype or similar services preloaded onto the phone when it ships. Basically he said he didn't want users to be able to make out-of-the-box VoIP calls with a competing provider on a phone he'd subsidised, and that all VoIP calls from the phone would initially be routed via the operator's own VoIP servers. When I asked him whether he was talking about disabling the underlying VoIP capability down in the operating system, he said that no, that wouldn't happen. Advanced users would still be able to download Truphone or Fring or whatever - these "clever" users, he recognised, would always be able to use VoIP if they chose, and alienating them was stupid, as they'd just churn - not ideal, as these are exactly the sort of high-end users who use data and other interesting new services if they're pitched right.
What's not clear is whether the Orange & Voda folk have been so ham-fisted that they've blocked all "naked SIP" capabilities or just the VoIP. Personally, I think they're being particularly stupid to cripple a phone and not be completely up-front about it. Face it, the customer base for N95's is likely to be pretty tech-savvy - if you lie to them about the device's capabilities, or don't ensure that your sales staff & customer service reps know exactly what the modified functions & policies are, then you're going to irk an awful lot of customers.
I also remember asking the 3 folk at the time of X-series launching whether they'd block "real" VoIP running alongside the circuit-switched Skype/iSkoot service. No, they replied, if you wanted to download the packet version of Skype (assuming a Symbian one ever launches...) they wouldn't stop you or interfere with it.
Separately, I got an email yesterday from a senior exec at a major mobile software firm. He'd just bought an N95 (a "vanilla" version) and had been using it on a business trip to make VoIP calls from his company's US office, and his hotel. "So far I’ve spent 137 minutes on SIP calls using the N95. Setup was trivial, dialling is as simple as pressing “internet call” on a contact. Call quality is indistinguishable from GSM roaming call..... I've saved $292 so far, so that's payback in 9 days [for the phone purchase price]"
I foresee high-end users switching over to vanilla phones (especially businesses), or churning to operators like 3 which publicly state they don't screw around with the software too much. While this may have the long hoped-for effect of weaning many of us off of our addiction to subsidy, it will have the corollary effect of making us want proper ex-factory vanilla phones which work "to spec". I can't see anyone wanting an unsubsidised operator-custom handset that clearly has a risk that the software has been crudely hacked for "revenue protection" reasons.
In theory I have no problem with subsidised devices being limited to certain types of usage. I also have no problem with T's and C's being restrictive if all parties enter into the contract with open eyes. But I think that there needs to be increasing transparency about all types of "policy" with both mobile & fixed services. If you get a subsidised phone, you should be made to sign a form which says "I understand & agree that the operator can delete X Y & Z capabilities from the device's published specifications". If you sign up to an ISP, they should have similar transparency concerning any bandwidth management / port-blocking / throttling. I met someone recently planning to take this type of suggestion to Ofcom & other regulators: more power to you.
Truphone has posted a clip on YouTube showing an Orange-ised N95 with its VoIP capability amputated and unable to work with aftermarket applications which use the native dialler & menu integration.
Friday, April 13, 2007
Now, I haven't delved into the details of that spectrum award, but I wonder if this is a similar pitch to Truphone's in the UK - get recognised as a "mobile operator", get a cellular number range.... but don't build a cellular network. Instead, just use WiFi wherever possible, and benefit from the inbound interconnect fees levied on other operators for terminating calls on those mobile numbers.
Obviously this would only work if there was some pretty lax definitions of both the coverage requirements of the licence, and the interconnect regime for calls to mobile numbers terminating via non-cellular mechanisms.
On the other hand, maybe they do want to deploy a proper cellular network, or a femto/picocell-based one.
Wednesday, April 11, 2007
Weirdly, I've had both Google.com and Blogger appear in German-language variants, and I've had to reset the language to English manually on both sites. I guess T-Mo must funnel all its traffic through a centralised egress point in Germany with a particular IP address, or else Google's making some weird assumptions that T-Mo = German company = German langage. . Thankfully it doesn't go via China or Hungary, where I probably wouldn't have even recognised the link for alternate languages....
This is one example of why any form of so-called intelligent, context-aware function, on a PC or a mobile phone, needs to be 100% accurate, tested continually & rigorously - or not exist at all. Services which guess your context wrongly (status, location, device, whatever...) are worse than useless - they make the providers look like idiots, as well as wasting your time.
The full spec gives more details, suggesting that it could allow phones which use Symbian or Linux as the "Operator OS", with a separate and switchable domain for an "Enterprise OS" for Windows Mobile, using virtualisation technology in the hardware.
This could enable DoCoMo to provide corporates with phones that do a full range of enterprise apps including VoWLAN, for example with a WiFi access available solely to the enterprise OS and with the specific demand that the underlying platform "not impose any restrictions on its use".
It seems to me that DoCoMo has come up with a clever way of ensuring that:
- Enterprises can do what they want with their handsets
- DoCoMo retains control of the overall handset value chain & architecture
- Consumers may not be able to buy fully-open phones even if businesses can
Now obviously there are going to be issues with the "switching" process, especially if the operator part of the phone can pre-empt the enterprise OS while it's in the middle of something important like a phone call. But I suspect that for many users, a hybrid "two personality" device should go a long way to creating an acceptable blend of IT/Internet openness and operator-optimisation on the same platform.
Tuesday, April 10, 2007
When I published my report on SIP- and IMS-capable handsets last year, one of my underlying assumptions in the forecasts was that "Naked SIP" capabilities would start to extend beyond smartphones into the high-end featurephone arena during 2007. I anticipated that the pivotal enabler would be an extension to mobile Java called JSR-180, which gives developers access to a SIP API from within Java applets.
So it's nice to see that Sony Ericsson's newly-announced Z750 and indeed its new variant of its Java platform, supports MSA JSR-248, an "umbrella" Java extension intended to be a new standard, which includes JSR-180 as one of its mandatory components when implemented in its "full" rather than "subset" version. This line in the press release is quite telling when it comes to SIP-enabled applications "Java Platform 8 (JP-8), supporting a range of new Java programming features including instant messaging / chat and presence based functionality"
Two other things stand out:
- The inclusion of JSR-256 to give access to accelerometers for motion-sensing applications. As I mentioned a while back, I think this going to be a key inclusion in a lot of new handsets, enabling "multi-context" operation, which will be far more important than multimedia. To be honest, I hadn't even realised a Java API for sensors was on the cards, but this just adds to my conviction that sensors are the next "big thing" in terms of massmarket handset features.
- The apparent exclusion of JSR-281, the IMS Java API, although I guess that may be implemented on a case-by-case basis on specific phones.
Now, obviously that's still much less than the 2.5bn-odd mobile users (ie equating to around 3bn subs) - around 30% of the figure. But I'd guess in terms of many metrics like purchasing power, propensity to "generate content", sophistication of expertise and so on, that the numbers are much closer to parity. 800m isn't just "early adopters", either - it's early majority. And I strongly suspect it's also higher than the total sum of people who use anything more than voice & SMS on their mobiles.
In other words, pretty much everyone on the planet who's worth advertising at heavily, or who has sufficient disposable income for mobile "content", or is open-minded enough to experiment with new Web 2.0 community-type stuff, is already using PC-based broadband. Which sets expectations in terms of speed, latency and of course, price. As well as disaggregation of access and application. It also means that 800m people aren't that bothered about QoS for many activities.
One last thing - I guess we must be getting very close to 100m WiFi households, then. In other words, the same philosophy will also apply to future femto/in-home cellular deployments - almost every home installing a femto will already have WiFi, and business models & device/service strategies that ignore this will have problems.
[Side note: something I absolutely hate is "spurious accuracy". Given that most operators report figures rounded up/down to the nearest 10k/100k, citing 281,592,583 subs is mathematically unjustifiable. Even 3-sig-fig accuracy of 281m is questionable, given the definitional inconsistency of the data sources]
Sunday, April 08, 2007
I'll add in a couple of my own thoughts about this:
a) Microsoft seems completely and utterly disinterested in IMS. Yes, I'm sure there someone selling to carriers who is pitching LCS as a SIP app server, but in terms of an end-to-end story, this is all about turning voice and messaging into "another feature" in the general corporate IT domain. Certainly whenever I've asked about IMS-capable phones, I've got blank looks, or "Oh, you mean SIP? Windows Mobile's got that already"
b) Alec's post should be required reading for "mobile PBX" and centrex enthusiasts. About twice a week I have to counter the argument that all enterprises will just ditch their PBX-based phones (plastic or WiFi) and switches, and just start using mobiles with telephony as a "service". Normally I talk about higher-end IP-PBXs becoming part of corporations' IT infrastructure, and the fact that many companies like to retain control of their own voice systems for a variety of reasons. Migration stories are also important here - even if companies do want to be "all mobile", cellular operators aren't going to assist a huge 2-year migration towards that goal as they usually lack the integration and consulting expertise. I've also recently started talking about Asterisk and other server-based platforms dragging corporate voice even further away from network-based mobility solutions, but I hadn't really recognised the depth of movement towards embedding PBX capability in low-end boxes.
The argument that "SMEs will just buy a femtocell / WiFi router and use a hosted mobile PBX solution from the carrier, linked to mobile phones for the employees" starts to carry much less weight when you consider that the femtocell / WiFi router might just have a PBX built into it for peanuts.
Thursday, April 05, 2007
I presume this is particularly relevant for countries like the US where there are regional operators. For markets elsewhere with nationwide licences, I guess that the IP address of the broadband connection should be sufficient to ensure customers don't put the device in a suitcase and try & plug it in somewhere the provider isn't permitted to operate.
Interesting to see the real-world practicalities starting to come out, though. I suspect there's going to be a range of issues around security/authentication for femtocells that are only now being recognised.
This is of course total nonsense, on several grounds:
1) Some bearers only offer connectivity through an operator's network (eg cellular), while others also offer connectivity direct to the Internet or local resources owned by the end-user (eg WiFi, fixed broadband, LAN). Clearly it makes sense for some applications to be aware that, if the device is connected via WiFi for example, it may have access to IT or consumer-electronics capabilities outside the operator's control (eg a PC, printer, server, IP-PBX, TV, game console, hifi etc)
2) Different bearers have different characteristics - bandwidth, latency, quality, security, ownership, power consumption and obviously price. Applications (and sometimes the end user) should monitor bearers and make appropriate decisions. When Microsoft announces Service Pack 1 for Vista in a year's time, you'd rather have the download manager app know what network you're connected to. If it detects that you're roaming on GPRS at $10 per MB, it should wait until you're on a more sensible bearer before proceeding. Similarly, if the battery on a phone is really low, the telephony client might decide to "prefer" GSM to WiFi even if it's more expensive.
3) An operator or 3rd party may well decide to optimise for certain bearers, rather than rely on a lowest common denominator. If you're at home on an HSDPA femtocell, or WiFi, then you'll probably get more data throughput. This may mean reengineering the browser with a bigger cache or memory buffer to take advantage of it. It could mean the handset decides to use a higher-quality codec for better sound. It might switch on (or off) functions like advertising, or different sorts of messaging, or 101 other location-specific applications. The user interface might change automatically, or it could display location-dependent tariffs.
4) There may be more efficient routing through the network for a given application in certain locations/on a specific bearer. Take BT as an example. When a Fusion phone is at home on the WiFi connection, the browser would ideally send all web traffic straight out over the broadband connection direct to the Internet... and not first via Vodafone's cellular core network used as part of BT's MVNO relationship, as UMA would normally enforce. Even for an integrated operator like FT/Orange, there's no point unnecessarily taking up capacity in the MSCs and GGSNs for IP traffic that's then going straight to the Internet. (Potentially this function could be done in the home gateway rather than the phone itself).
A lot of people don't understand all this, particularly if they work at a mobile operator and still fervently believe that anything you do on a handset is "a service", rather than understanding that sometimes you want to do non-service activities as well.
Some handset software companies do get this. Most obviously, the enterprise-centric dual-mode clients from Avaya, Cisco, Divitas, Siemens etc have "multiple personalities", making the phone behave differently when it's in WiFi mode.
But I've also had discussions with Symbian (which has a thing called a Bearer Abstraction Layer, or something like that) which passes bearer information to the apps, so developers can embed the sort of intelligence I discuss above. Nokia's inclusion of UPnP technology in some of its WiFi handsets reflects the fact that it also"gets it" about making phones good citizens of the consumer-electronics ecosystem, as well as being operator-centric.
And this morning I had a discussion with a company called Abaxia, which is also completely on-message about the above. It has some dynamic UI technology that alters the handset idle screen and applications, depending on the network context. Interestingly, it's working on both bearer-aware (eg cellular vs WiFi) or location-aware (eg whether you're in a homezone) variants. On the homezone side, it's working with Orga on a SIM-based solution that works out if the user is in a given cell (or triangulates from a set of base stations), and enables the UI to adapt accordingly.
The Orga solution sounds a bit similar to the one from Seeker Wireless, albeit without the network-side location server element containing a map of base station locations. They both have the handset/SIM locate the network, rather than vice versa. I'll do another post about non-WiFi/non-femtocell FMC solutions at some point - they generally offer location-based tariffing discrimination but don't add any dedicated indoor wireless coverage or capacity.
I foresee a lot more work in this area, as operators & device vendors realise that optimising the user experience, for different bearers or locations, is an essential aspect of FMC. Different bearers are inherently different - don't treat this as inconvenient, treat it as an opportunity and exploit it.
Sunday, April 01, 2007
The FAQ & How it Works sections are just brilliant.... "on-site technical support in the event of backup problems, brownouts and data wipes"
Somehow, I just can't see BT, Vodafone, AT&T, Qualcomm or Cisco competing successfully in the "Telecom Toilet Humour" stakes, even on April 1.....
... or Microsoft, Yahoo or RIM in the "Email Humour" stakes either....