WiFi offload will not always win out over femtocells

There seems to be an undercurrent of skepticism about some of the usage scenarios for femtos - in particular, the notion of why anyone should bother with femto offload, if an increasing set of devices all have WiFi anyway.

The Femto Forum has released a study on femto/WiFi coexistence which highlights some reasons it sees for combined deployment, but I think a couple of additional ideas are also useful.

One important factor is the difference between laptop PCs and smartphones:

- In a 3G-enabled laptop, WiFi is almost always switched on, but 3G is usually only on part of the time (not least because most users will only plug in the dongle when needed)
- In a 3G-enabled smartphone, 3G is almost always switched on, but WiFi is usually only on part of the time

And for both, 3G (or at least data access on the phone) is likely to be switched off when roaming internationally.

This will mean that laptop 3G data offload is probably best done via WiFi, but smartphones may be more femto-centric - especially as smartphones are more likely to have operator-branded services that make it advantageous to keep the traffic on-net. Laptop data is 99.999% straight to and from the web, with almost zero operator value-add, so it makes sense to dump it to the cheapest connection as often as possible.

But even that overlooks yet more layers of subtlety in terms of user behaviour.

I've been using an iPhone 3GS the last few weeks, and the battery life is atrocious. So I've done the usual power-management tricks of turning down screen brightness, turning off GPS, and manually switching off WiFi when I leave my house, only switching it back on when I know I have access to free WiFi elsewhere such as a hotel or certain cafes.

So although it's not hitting the cellular network all the time, and my home WiFi certainly takes quite a lot of the strain, it's certainly not able to offload everywhere where the operator might like, or might have WiFi offload deals with hotspot providers.

My two local branches of Starbucks gives me a real sense of the paradox:

- I know I can get access to the BT Openzone WiFi for free with my Vodafone iPhone contract.... but I've got the WiFi switched off by default, it requires me to do some sort of registration process with my account number (which is at home) and 3G coverage works fine in both cafes, so I don't bother.
- For my 3UK dongle for my laptop, one cafe has good HSPA signal and the other is lousy. In the one which is lousy, I use the WiFi, which I can again get for free with a Starbucks loyalty card (there's no offload deal in place with 3). In the other, I always use the dongle as the WiFi access controller seems to have a 20-second setup time before hitting the splash page, and another 20 seconds before I get authenticated. And if I'm using the 3G, I'll switch off WiFi to save battery.

Now re-imagine these scenarios with a femtocell viewpoint. At home, I'd probably still use WiFi rather than a femto, as I'd expect it to be faster - and some pretty innocuous websites I visit fall foul of Vodafone's over-zealous content filter and get blocked. VoIP provider Fring's website is censored, for example. I can't be bothered to phone up for "adult access" permission, and anyway I'm sure there are other things in the T's and C's about fair usage that I can obviously ignore when I'm on my own WiFi. I obviously never use the 3UK dongle when I'm at home within range of WiFi, as my laptop just connects and authenticates immediately and without extra intervention.

The cafes are different - if there was a Vodafone femto and the iPhone switched onto it, I'd probably notice an improved performance and likely lower power consumption. Same thing with the 3UK dongle in the branch where I currently don't have coverage - I'd probably switch back from the WiFi with its more-cumbersome login process with passwords and splash screens.

But you've probably already spotted the problem - does Starbucks want 4 or 5 femtos in every branch, from different operators? Who would pay for them? The cafes already have "sufficient" connectivity for everyone with WiFi - it's unlikely to want to bear the cost of just making it marginally more convenient for a select group of its customers.

The point here is that the neat idea of a monoculture of WiFi offload everywhere, or 3G offload to femtocells do not fit with the annoying peculiarities of consumer behaviour. People very quickly find the most convenient / cheapest / fastest / best battery-saving strategies for their personal circumstances. It's very difficult for operators wanting to conduct offload to work their way around those optimisations - unless they use either very smart connection-management software, or very brute-force ways of ignoring the subtleties.

One other thing occurs to me: I wonder if it's possible to get the presence of a WiFi SSID to trigger a device to switch on 3G and look for a femto in that location. Or for the presence of a specific femto (on any carrier's network) to trigger a client to power up smartphone WiFi if it's switched off, and use that instead.

Read More

The right way to sell mobile broadband....

Just seen at London's Victoria station - a (Sandisk-branded) vending machine selling memory cards, phone acessories... and mobile broadband USB dongles. Shrink-wrapped, no cumbersome sales or registration process, no annoying salesperson trying to upsell you.

Just data connectivity, on a stick.
Like memory, on a stick.

Yes, there's still absolutely a role for contracts, retail stores, expert sales executives and so on. But solely going that route leaves money on the table when someone wants a quick transactional purchase. When I get to Victoria, I want to hail a taxi, not sign up for a cab account. Same thing for if I was dashing to catch a train and needed Internet connection for my trip.

Read More

"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 can overlay all sorts of data and images onto our field of view.

There's a plethora of micropayment systems available, accessible via APIs to any developer with the right tools.

There are open and closed appstores. Any app you can imagine is available for unlocked devices.

Operators are starting to monetise contextual advertising - there are digital posters, sponsorship of content, location-based coupons.

And then there's the sudden backlash.

"You can't use my eyes for free"
"My visual cortex isn't a dumb pipe"
"I spend lots of money on contact lenses & eyetests"
"Let's prioritise certain aspects of our visual input"
"We should charge advertisers for access to our retinas"

Until, finally, the inevitable:

"We've created a deep-photon inspection (DPI) application for your smart AR glasses, which uses new visual-processing chips to recognise low-value-per-wavepacket images. It blocks or degrades incoming advertising traffic, unless the advertisers pay you a fee for guaranteed quality-of-sight (QoS) and delivery"

So there's the challenge for all of you marketeers talking about the future of personalised, contextual advertising, based on data-mining our phones and location and Internet usage. If you reckon you're so good.... well, let's see you pay us a deposit before you beam your messages to us. If it's relevant, informative or entertaining, we'll give you a refund and might even buy your product.

Read More

Will MIMO work indoors?

This post is more of a question than an answer.

Many larger buildings (airports, shopping malls etc) have various forms of indoor coverage - active and passive distributed antenna systems (DAS), in particular. These usually involve connecting small base stations - often from multiple network operators - to a network of antennas, splitters and other paraphernalia around the building.

All of which is fine.... until we get to technologies like LTE and some variants of WiMAX and HSPA+, which use MIMO technology. Multiple-in, multiple-out technology uses a number of antennas.

I've recently asked a few people the question "So, how does MIMO work with DAS systems installed historically in large buildings?"

The usual response has been "Errr...... that's a good question. Not sure".

I bounced this one off a DAS vendor this morning (Commscope's Andrew division), and got an answer that it *should* all work with their recently installed systems. Asked about whether older systems, or other vendors' installs will need upgrading got a less-clear answer.

So, a set of questions for anyone who might have looked at this already:

- Do older DAS installations work OK with MIMO?
- Does LTE (or WiMAX or HSPA+) work properly when MIMO doesn't do what it's supposed to? What are the side-effects? (Slower speeds? Lower aggregate capacity?)
- Are the effects made worse when you go to 4x4 or more complex versions?
- How do you test all this?
- If certain installations don't work OK, how much will it cost to fix them?
- And while we're on the in-building topic, will the older implementations support new bands like 700MHz and 2600MHz OK as well?

Read More

Netbooks - a skewed view on mobile broadband

In recent months, I've noticed an interesting misconception.

Some observers - notably from North America - seem to be under the impression that netbooks are, by default, mobile-connected. And, in particular, that they are major contributors to 3G data traffic.

As far as I know, this is not really true. Yes, in the US (and, I think, Japan), a fairly decent proportion of netbooks are sold through mobile carrier channels, with embedded or bundled 3G modems, usually on monthly plans.

Elsewhere, although that model exists, it is far from the most important. The majority of netbooks are sold through ordinary PC retail, corporate or online channels. And these generally do not have in-built wireless modules. Yes, some get used with USB 3G dongles (such as the one I'm writing this post on, from my local cafe), but many are just used with WiFi or even ethernet.

In 2010, there will probably be around 40m netbooks shipped. I'd be surprised if more than 10% are sold with built-in 3G, with maybe another 10-15% used with separate dongles. Ordinary retail netbooks rarely ship with 3G modules, as the cost is a very large % of the manufacturer gross margin - so the OEM won't wear the cost unless they're certain of either getting a higher retail price (unlikely as dongles are cheap), or some form of bounty from operators when/if customers sign up (rare).

The majority of PC-based mobile broadband traffic is generated by ordinary, larger *notebooks*, not netbooks, as both the installed base and new shipments are far higher than those for netbooks.

Read More

CTIA....

... I'm not going to be there, so please don't bother inviting me to events or meetings. (If it's like MWC, for which I got about 250 invites, I probably won't get a chance to write individual "no thanks" replies)

Thanks.

Read More

Mobile traffic management - video confusion

A lot of my meetings at MWC two weeks ago were about managing mobile broadband traffic - by offload, by compression, by policy and various other means.

There is a total lack of agreement on where the emphasis should be. Everyone has a solution - and it's far from obvious that they are not pulling in opposite directions. Dump most traffic to WiFi, and it becomes much harder to justify restrictive policies when the phone is "on net". Offer "premium" or "platinum" connectivity - and get let down by poor coverage. Put femtocells in place - and then try to distinguish femto vs. macro traffic in the policy engine, because throttling someone's 3G access *on their own cell & broadband* is a recipe for disaster.

And all this is before we get to the fun-and-games which will ensue in a world with widespread connection-sharing.

The starkest choices seem to be around "what to do about mobile video". Endless copies of Cisco's Visual Networking Index charts were trotted out (or other large vendors' inhouse equivalents) showing terrifying increases in forecast mobile video traffic, swamping all other types. Even leaving aside that other new apps might be even more traffic-generative (maybe augmented reality, for example), there are still huge issues about how to treat video.

First off, let's be clear - there is no single application called "video". There's a mix of downloads and streaming, one-way and two-way, embedded and standalone, numerous codec and frame rate options and so on.

In the eyes of a user, clicking "I like" for a YouTube clip shared on Facebook by a friend, is a very different application to watching the same thing on YouTube.com in a separate window. Context is very difficult manage in a policy engine, especially if it's a web mash-up.

One theme that I heard repeated a few times was the idea that some sort of server or gateway would intercept inbound video traffic on an MNO's main Internet connection, spot who/what was requesting it, and (let's be polite here) "mess about with it" in order to reduce the impact on the network.

It's a very similar idea to the various Web messing-about-with engines ("transcoders" or "content adaptation") we've seen before from the likes of Novarra, ByteMobile and Flash Networks. Yes, they sometimes reduce load, but when first introduced they mangled content and advertising, caused problems with mobile commerce and did some horrible things to sites that were *already* mobile-optimised by the original website owner. Over time, the worst effects of these seem to have been ameliorated, with some sort of grudging consensus now almost attained.

The same set companies, as well as a group of new ones like Acision and Ericsson, are now talking up the idea of compressing video traffic on the fly to protect the network. One comment made was that the network could choose to buffer video traffic itself, rather than let the phone/PC buffer fill up quickly, over the air. YouTube was cited as being "aggressive" in encouraging users to download whole videos upfront, when sometimes they closed the video window and "wasted" a lot of bandwidth, because they hadn't watched the whole thing.

To punish this sort of profligate downloading behaviour, it's envisaged that the network could either compress the video traffic, or "drip feed" the buffer.

Cue consternation from other people they haven't yet spoken to.

First up are the radio guys, who, paradoxically, would much *rather* whole videos downloaded fast rather than being drip-fed. It's more efficient for base stations to blast as much traffic as possible at a user, in a short space of time, if it's not actually congested. And it's also much better for the user's battery to download a big gulp of data in one go, and then switch the radio off. Keeping the connection up for longer may also increase the signalling load even if the actual traffic is reduced.

There is also an interesting regulatory angle here - if mobile broadband speeds have to be advertised on the basis of average actual speeds, rather than theoretical peaks, then the drip-feed approach could have serious marketing consequences.

The compression side of the equation is also likely to be extremely controversial. There's an interesting set of issues of liability if you've paid for HD video (or an advertiser has), and the network arbitrarily steps in and mangles it for you during delivery. There's another interesting set of questions of whether the network can work out exactly what video stream to compress, if it's sent via a CDN like Akamai, which might peer at various points in the network.

But all of these are minor compared to the likely outrage from various video content and aggregation companies that have their content "messed about with".

Put simply, any attempts to "optimise" video in the core of the network are likely to be very ham-fisted, especially if they attempt to compress or transcode. The core is unlikely to be able to know how best to compress a video as it will vary immensely on a genre-by-genre or even scene-by-scene basis.

Content can be delivery-optimised in various ways: frame rate, frame size, key frame rate, audio rate, etc. all can affect bandwidth, however the best encoding recipe may be influenced by the type of content: sport, talking heads, music video, being genres of content that could be argued to have opposing views as to what's the best encoding recipe. Think of an interviewer static in a chair with a fixed background, versus a live-streamed F1 race. Applying a single policy to both videos is likely to be very crude, and result in a very poor user experience.

Some policies are already causing consternation - for example, by blocking overhead-light delivery protocols such as RTSP/RTP over UDP, forcing publishers to more inefficient alternatives.

Other side-effects of network-centralised video policy management may be to push a greater processing burden down onto the handsets (and hence their batteries) - for example, re-coding video in formats like H.264. As well as requiring a lot of network-side processing power to do this in real time, we could end up with the interesting situation of power consumption differing on a per-network basis. That could make for some interesting marketing angles for operators "Get your XYZ handset on the network that gives you 3 hours longer between recharges!"

(Hat-tip here to input from my friend David Springall, CTO of Yospace, which provides platforms to mobile video content publishers).

One answer seems to be to optimise mobile video through a balanced combination of editorial control and network technology. If operators (or their network partners) provide adequate guidelines on making mobile-friendly video, it may be that providers all the way back through the value chain can help - for example, content can be editorially controlled to be more compressable, such as by avoiding unnecessarily moving cameras during production. This is similar to attempts by operators and device vendors to encourage their app developers to follow "network friendly" approaches like fewer server pings.

It seems unlikely that video publishers will pay operators "cold hard cash" for QoS (or even an SLA) on mobile broadband, despite the rhetoric around DPI / policy management boxes. It's simply too difficult to control end-to-end quality as far as the device UI - and *prove* it to the content provider. But publishers would likely respond to doing what they can with their video content to make it 'work better' on mobile networks. Although they don't have the technical ability to do this, they are using third-party platform providers to deliver their video and it is these third parties that can implement whatever is considered best practice by the networks.

Operators could publish clear guidelines to help third parties optimise video on their networks; platform providers should work to these guidelines in the interests of delivering a better user experience (assuming some measure of consistency across operators, of course - it's unlikely that they would wish to see 800 different sets of rules across the world - or, worse, 2400 if they vary for 2G, 3G and pseudo-4G networks). It would also help video content publishers if MNOs provided APIs that provided more information about the network quality in realtime, allowing platform providers to be more sympathetic to the network. While this may also be feasible via handset-side APIs, the network may enable a more consolidated view to be provided. Over time, this could even evolve to cell-by-cell "traffic reports" allowing video to be delivered differentially to those in the best/worst radio or backhaul congestion conditions.

Depending on the laws in each country, well-behaving video traffic (however that is measured and defined) could be prioritised in some circumstances.

One issue that is likely to crop up is how to deal with PC-based video traffic transiting mobile broadband networks via 3G dongles. This is a little more problematic than smartphone video, as it is usually marketed as being a direct alternative to ADSL or cable broadband. Nevertheless, some form of in-application smarts could still allow optimisation - it's been pretty common for years to have a choice of different broadband speeds / types before starting a video "Are you watching on: ADSL, LAN, 3G, WiFi etc" might put the user back in their normal state of control. There's also a very strong argument to prefer outright offload for PC-Internet traffic to WiFi (or femto) and avoid the core network and compression argument altogether.

Overall, I definitely think that the question of how to deal with mobile video is still at very early stages. Although various solutions are emerging, it seems probable that the initial knee-jerk attempts to reduce network load will have some fairly nasty unintended consequences in terms of user experience, device battery life, radio performance and content-mangling - and hence generate support calls and dissatisfaction. The idea that the network can somehow magically reduce the impact of video traffic, without any input from video publishers or aggregators / platforms, seems misguided.

Read More