Bringing U-Verse to the iPhone

Here's an issue I’ve been puzzling over for some time.

U-Verse, AT&T’s slick new IP TV service, is available in my neighborhood. Unfortunately, I’m too far from the distribution point to get it at my house. But many of my neighbors have and love it.

And like in many suburban neighborhoods, iPhones are sprouting up like crazy.

So, I have often puzzled: why can’t one watch U-Verse TV on one's iPhone?

This is the one mobile TV service that makes sense to me. Not random programming at random times, and not 'video shorts;' actual content I select, available to me, when I want.

Let’s look at the problems and what the answers might be.

First, if there ever was a phone for watching TV, it’s the iPhone. It’s got a great screen with brilliant colors, and the landscape display with 16:9 aspect ratio is ideal for HD TV.

Next, if there ever was a service provider to deliver on the ‘three screen’ vision, it’s AT&T. They are the sole quad-play provider in my neighborhood, delivering voice, broadband, mobile and now TV via U-Verse. And it’s not just any TV. It’s a full streaming IP TV service.

AT&T is particularly proud of its ‘whole house’ DVR, where a single box can stream video to different TVs throughout the home. Surely with this advanced capability, it would be possible to stream the shows stored on the DVR to a ‘third screen’ (e.g. an iPhone).

So what’s the hold up?

I don’t work for Apple or AT&T, so I have no inside knowledge. But clearly the iPhone is capable of displaying a TV service. So perhaps the problem is getting the service to the iPhone. I refer to a paragraph in this article on Digital Trends:

“AT&T does say that, due to network congestion concerns, it does not want television signals traversing its cellular network to iPhones…”

Given the trouble AT&T has had with network congestion, this makes a lot of sense. But this is a paid TV service, not YouTube. There is distinct value in bringing the three screen vision to life for AT&T subscribers.

So what if the U-Verse service was delivered to the iPhone over Wi-Fi?

The U-Verse controller has built-in Wi-Fi, so by definition, homes with U-Verse are homes with Wi-Fi. Plus, using Wi-Fi would keep the TV congestion off the 3G network. Finally, people are likely to watch TV when they are stationary (at least in the US), so that covers places like the home, office and hotspots.

It’s probably more complicated that simply ‘streaming U-Verse over Wi-Fi.’ So what are some of the likely requirements for AT&T to deliver the U-Verse service over Wi-Fi?

• User authentication. Just setting a ‘user name/password’ over the Wi-Fi network doesn’t provide enough authentication for a service as valuable as streaming TV. An ideal solution would validate the user based on the SIM credentials of the iPhone against AT&T’s database of U-Verse subscribers to ensure that members of a specific U-Verse household are actually the ones accessing the service.
• Security. Delivering U-Verse over Wi-Fi means delivering it over the public Internet. Therefore, a true security solution must be employed.
• Location. Undoubtedly there are would be location restrictions on where a user could actually watch their U-Verse service, probably within the US. Thus the service must be able to accurately identify the iPhone’s location (not too hard).

Well, as you might have guessed, there is already a 3GPP approved specification for solving this problem. The GAN specification was designed by mobile operators specifically to address the problems associated with delivering services over the public internet.

The 3GPP GAN standard provides:

• SIM-based user authentication over Wi-Fi. A GAN client in the iPhone would use the iPhone’s SIM credentials to authenticate the device against AT&T’s HLR and establish a secure connection over the Internet (nice transition …).

• IPSec VPN secure tunnel. GAN transports voice and packet (U-Verse) services between the iPhone and the AT&T network encapsulated in an IPSec VPN to ensure a secure connection.

• Operator managed location access. With the iPhone, there are many ways to access and monitor the location, via cellular, Wi-Fi and GPS. When establishing the GAN connection, the operator (AT&T) is presented with all the data needed to decide to enable (or reject) service based on the current location of the handset.

There are so many datapoints, it’s absolutely a no-brainer for AT&T to add GAN to the iPhone.

There is no doubt that other operators with iPhones and their own streaming IP TV service (actually nearly any incumbent mobile/video provider) would benefit as well. If we get started now, maybe we can have it in time for Christmas.

PS - I blatantly copied an image and imitated prose from Dr. Suess's "How the Grinch Stole Christmas." This is one of my family's favorite Christmas books. I can identify with it because I often find that "...my puzzler is sore..." too.

UMA Jumps Into LTE

On Monday, the UMA/GAN standard moved into its next phase with the announcement that the ‘VoLGA Forum’ is basing its work on the spec . The forum states that it is “comprised of leaders in the wireless industry seeking to enable mobile operators to deliver mobile voice and messaging services over LTE access networks based on the existing 3GPP GAN standard.”

I say GAN has moved into its next phase because, as a technology, this is nothing new. GAN has been delivering ‘voice and messaging services’ (and more) over fixed-line IP access networks for some time. The forum’s announcement simply acknowledges that there is a viable mobile IP access network in the form of LTE requiring a similar service.

While the technology is similar, the actual application is quite different. Whereas traditional UMA services like dual-mode phones and femtocells address the FMC segment of the market, the concept of VoLGA is to have a VoLGA client on every LTE phone.

Basically VoLGA is the enabler for making phone calls over LTE.

Based on posts by Martin Sauter and my good buddy Dean Bubley, it’s clear there is a problem with the ‘status quo’ approach for voice over LTE. Martin Sauter’s comment:

Over the past two years I've written numerous posts about different proposed options on how to do voice calls over LTE and the lack of a simple and straight voice solution. This is, in my opinion, a serious threat to the success of LTE if not resolved soon.

I’m sure we have not heard the last of the VoLGA Forum.

UMA + RCS

In the early days of the UMA Today blog, there was much time and energy spent on articulating how IMS for applications other than telephony is actually complementary to UMA.

IMS, of course, means a lot of things to a lot of people, but for mobile operators today (UMA’s target audience), IMS is typically viewed as a means to deliver new revenue generating services above and beyond standard voice and SMS.

In response to this, leading operators and vendors intent on IMS tried to pare down the ‘Immense Menacing Squid’ as some used to refer to it, into pre-packaged set of applications that could be quickly and easily digested by a mobile operator.

The result is RCS, or the Rich Communications Suite. Announced about 6 months ago, RCS looks to wrap up IMS-based ‘rich call’ services, ‘rich’ instant messaging and enhanced address book services together into a single client that can be used on handsets today.

The implication of *today* is that it must be able to run over today’s 3G network, which in turn implies that it will use the existing circuit services network for voice, not a new IMS/SIP based telephony (a la MMTel). It stands to reason that if RCS works with standard 3G telephony, then it should work fine with UMA.

So what does all this pre-amble lead too?

I was on the GSMA site checking out the RCS section, when I happened across the release 1 specifications. I downloaded the “Technical Realisation v1.0” document and was quite surprised to see this:

Along with this text in section 2:

Note about Generic Access Network (GAN)

Generic Access to A/Gb interface provides a secure mechanism, using the SIM credentials, to access the mobile operator core network (both packet and circuit switched) using any unlicensed spectrum technology via a generic IP network. In fact, access to mobile operator core network via GAN is fully transparent from RCS perspective, and as such it does not lead to any particular limitation or impact from service point of view.

As a consequence, from access network perspective, this [GAN] technology is fully part of the scope of RCS, whatever Release is addressed, irrespective of the release.

Hey! Someone has seen the light. There is now proof from the GSMA that UMA and IMS are complementary, not competitive, technologies, at least when it comes to new service delivery.

China Mobile: Voice over LTE... via UMA/GAN?

As covered by Michelle Donegan at Unstrung, China Mobile is prepping their network for LTE, and voice will be an important element.

Bill Huang, general manager of China Mobile Research Institute, said that the company is well prepared to move to LTE, and stressed the importance of supporting voice. Mr. Haung went on to say that one option for Voice over LTE was the UMA/GAN protocol.

“We could carry voice over UMA” said Mr. Huang. “We will have an LTE network that supports voice…”. To clarify, what Mr. Huang is referring to is not the traditional ‘home zone’ UMA deployment involving Wi-Fi or femtocells.

The 3GPP UMA/GAN (Generic Access Network) standard provides a generic method for extending 2G and 3G circuit (and packet) services over any broadband access network. Until now, the standard had been used to enable mobile operators to extend their services over fixed broadband networks (DSL, cable,…). However, now with a high-speed, low latency *mobile* broadband network, GAN can be used to extend existing mobile services (like telephony) over LTE.

Clearly for the mobile operator, this is a very low-risk, low-cost method of bringing their voice services (and revenues) to their LTE network deployments.

3GPP Selects Femtocell Standard, and it’s not (exactly) UMA/GAN

It was announced by multiple sources this week that 3GPP selected a reference architecture for femtocell-to-core network connectivity. This isn’t the completed standard, but sets the framework for the 3GPP RAN 3 working group to develop a full specification. The plan of record, per the 3GPP, is for the full stage 2 and stage 3 documents to be completed by Dec 2008 (in Release 8).

As has also been point out recently, the existing 3GPP UMA/GAN specification was one of a few architectures being considered as the basis for a formal 3GPP femtocell standard. The net result is that the UMA/GAN standard, as is, was not chosen. Sad but true. In order to reach an industry consensus on a HNB architecture there was a measure of compromise from all the participating companies. That’s the nature of standards: compromise.

However, while the HNB reference architecture is not full UMA/GAN, it adopts a number of key principles first introduced in the 3GPP GAN standard. For example, at the highest level, it follows an access-based (rather than core-based) approach, leveraging the existing Iu-cs/Iu-ps interfaces into the core service network. It also identifies the use of a specific protocol for solving a number of challenges associated with the ad-hoc deployment of devices over the internet.

Frankly, while the UMA community would have been delighted if 3GPP had adopted GAN lock-stock-and barrel (as they say in the US) as the formal femtocell standard, the likelihood has always been low. Fortunately, the agreed femtocell architecture builds on several core principles of GAN, which will help accelerate the market.

ThinkFemtocell has a good breakdown of different elements of the work.

For at least a little while longer, UMA/GAN remains the only 3GPP standard which supports femtocells today...

GAN Iu-Mode Stage 3 Complete

At the 3GPP meeting two weeks ago, the GAN/UMA working group ratified the Stage 3 requirements for Iu-mode support. It's done. Now... how to get the femtocell community to use an existing standard rather than creating something new from scratch...

UMA/GAN standards adds Iu-mode (3G) support

At last week’s 3GPP meeting in Vancouver, the GERAN working group approved the CR (change request) that adds Iu-mode support to the UMA/GAN Stage 2 specification.

The addition of Iu-mode support to the UMA/GAN specification now also enables the development of UMA-enabled devices (dual-mode handsets, femtocells) that can leverage the 3G (Iu-CS/Iu-PS) interfaces into the core mobile network.

UMA started as a 2G technology and now supports both native 3G and 2G interfaces. The standard continues to evolve with mobile RAN.

The Femtocell Conference

Avren, a boutique conference firm, hit a home run July 3-5 with the industry’s first femtocell event. Adding to the allure was the inaugural meeting of the new Femto Forum which resulted in a staggering 240 attendees all crammed into a hotel ball room at Heathrow to hear about femtocells.

I wanted to offer a couple of thoughts that we picked up from the event:

- The operators have consolidated around a 'RAN gateway' approach.

Early on there was talk of potentially using Iu-b or even SIP, but those have been largely dismissed by the operators. All major operators and vendors (NSN, Alcalu, Motorola, NEC, Ericsson) have proposed a RAN gateway (like a UNC) solution that provides an Iu connection to the mobile core.

This approach is low impact to the core and ensures full service transparency (all GSM/3G services are delivered over the femtocell), the same reasons why UMA defined a RAN gateway approach 2+ years ago. What's interesting is that rather than rallying around UMA, vendors are each defining their own proprietary approaches. Motorola and NEC are following the UMA path.

- Operators are *insisting* on an open interface

This makes sense. They want a robust, competitive market for femtocells, with many suppliers delivering products that meet a single, standardized interface. This achieves the economies of scale for femto manufacturers to drive costs down. Of course, UMA is already an open/published specification. NSN took the unusual step of stating they will publish their ‘vendor specific’ protocol for other femto vendors to build too. I’m sure the other vendors (ip.Access, Ericsson, Alcalu, NEC, Motorola, ...) can’t wait to build a femto that conforms to the Nokia/Siemens specification (or vice versa).

- The hype is high, but reality is starting to set in.

It was clear from the tone of the operators that femtocells are an exciting opportunity. But all realize there is a LOT of work to be done before the promise/hype meets up with the shelves of consumer electronics stores.

- A word on UMA

In all of this, UMA continues to be the only published, industry recognized standard for femtocell backhaul. The minor work to extend the current UMA specification to support Iu was kicked off in Oct 06 at the 3GPP.

Through its work with Dual-Mode Handsets, UMA already has the ability to integrate millions of devices into the mobile core, has the access control mechanisms to support consumer grade products, and a robust handover procedure. These capabilities are yet to be defined by the vendors scrambling to come up with their own RAN gateway protocols. UMA is the standardized RAN gateway approach.

Two other things UMA has going for it versus these ‘vendor specific’ approaches. One is that UMA supports dual-mode handset services as well as femtocells. While an operator may not be interested in a DMH service today, the future protection offered by a UMA infrastructure, with no price premium (UNCs are already deployed in volume around the world for DMH), is very compelling.

Second is that UMA supports 2G femtocells as well as 3G femtocells. If an operator is going to deploy a ‘combo’ AP, or is interested in 2G femtos, UMA is the only choice.

All in all, UMA is really proving why it is known as ‘GAN’, it is a generic access network technology, easily adaptable to new applications.