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?
Friday, March 05, 2010
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.
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.
Thursday, March 04, 2010
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.
Thanks.
Tuesday, March 02, 2010
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.
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.
Subscribe to:
Posts (Atom)
Posts
