Verizon Wireless picks Nortel for EV-DO RevA

Verizon Wireless announced that they have selected Nortel Networks to supply EV-DO RevA (see also, their previous statement regarding Lucent). Both Lucent and Nortel supplied Verizon Wireless with EV-DO Rev0, so neither of these announcements is a great surprise.

The announcement continues on to say that:

Verizon Wireless is currently trialing new, low-latency applications with Nortel EV-DO Rev. A technology, including push-to-talk, fixed mobile convergence, VoIP and messaging services. -VZW

I'll be keeping an eye out for when these low-latency applications move from trial status to commercial deployment. It's well-known that EV-DO RevA includes sophisticated QoS features intended to support real-time applications. I expect, however, that EV-DO RevA products will be rolled out in phases. These initial EV-DO roll-outs (expected later this year or early in the next) aren't likely to support the fancy QoS features that are defined in the 3GPP2 specs (nor, by extension, the low-latency applications that rely on them). Instead, RevA will initially support the same broadband wireless connections that Rev0 supports today, albeit with a slightly fatter, faster pipe.

Categories: Verizon, Nortel, EVDO, RevA, QoS, Wireless, VoIP, 3GPP2

IMS & IPTV

This article caught my attention today. Specifically, this line:

Ericsson is looking to leverage its strengths in IP Multimedia Subsystem (IMS) technology to succeed in the IPTV market ... [Their vision] encompasses PCs mobile and television as client devices, working off IMS within operator networks ... You would be able to access your favourite services and content wherever you are, whenever you want and with whatever device you are using.

When I teach IMS classes, I tell my students to be wary of statements like this. It sounds suspiciously like someone's playing a game of buzzword bingo.

IMS may well be a useful architecture in which to develop applications and services, but it doesn't necessarily lend itself to all applications. The control plane is based on the Session Initiation Protocol (SIP), and SIP, by definition, addresses session-oriented applications. So SIP is fine for doing things like telephony, push-to-talk, conferencing, gaming, and instant messaging. You wouldn't, however, want to use it for basic web surfing, sharing files, or downloading emails. And since the IPTV control plane is based on IGRP and RTSP, it's not at all clear that you'd want SIP to control your IPTV application.

So ... what are they getting at? Will the IPTV client send an INVITE request to change the channel? Will the CSCF route RTSP messages to the IPTV application server? Well, not exactly. Some further digging on Ericsson's website yields this press release.

It also includes guidelines for integration with IP Multimedia Subsystem (IMS) functions, such as charging and end-user authentication

So the IMS and IPTV systems can share a common authentication and billing function. Why didn't they say so in the first place?


Categories: IMS, IPTV, Ericsson, SIP, RTSP, IGRP

IMS Handsets

I came across Dean Bubley's "Disruptive Wireless" blog today. In a recent entry, he argues that lack of handsets may slow IMS adoption. I'll admit infrastructure solutions get the bulk of my attention. Judging from his "Google search terms" exercise, I'm not alone.

He further argues that standards organizations have focused on enabling technologies, but have failed to adequately define applications and services.

Now try & find anywhere that says how these phones should actually work in the hands of the user. How does the "IMS client framework" work with all the other applications on the phone? What are the standards for the user interface - telling the other presence user that your videocamera is switched off, or that the phone's in your pocket & you're using a Bluetooth headset? Does the phone need to be multi-tasking capable if you want several IM sessions, video-sharing and a buddy list working simultaneously? While listening to the MP3 player too? How should it behave differently if it's got WiFi in it? Should the applications be "bearer aware"? - Dean Bubley, May 2006

I'd have to disagree with him here. It's true that nobody defines how IMS phones should work or whether they should support multitasking, and that's as it should be. Standards should foster interoperability. They shouldn't promote uniformity of user experience. Innovative developers will differentiate themselves through their user interfaces and software architectures. Consider the iPod or Blackberry as an example of the former, and the Symbian OS as an example of the latter. Each of them set itself apart from a sea of otherwise commodity devices. The industry doesn't need standards to tell it how to integrate presence into their applications' user interfaces. Some applications will do it well and will prosper, others won't and will fail. We'll all benefit from the competitive process.

At any rate, Dean's blog has good stuff. I'll be checking it out from now on.


Categories: IMS, handset

All IPTV solutions are not alike

A recent EETimes article reports that a panel of cable executives have concluded that they have little to fear from telcos' forays into video services. The crux of the argument goes like this:

1. Most telcos (SBC's Project Lightspeed, for example) are deploying systems wherein they don't actually run fiber to the home, but rather just to your neighborhood distribution node. The final hop still has to traverse the existing copper telephone line running to your house.
2. That final hop won't be able to support the bandwidth necessary to run high definition video services.
   
3. The cable plant does, obviously, support HDTV, so they'll continue to have a significant competitive advantage.

The article points to one notable exception, however: Verizon's FiOS video service.

"HD channels are the ultimate weapon against IPTV, because most of the PON architectures being talked about right now can't handle multiple HD streams," [Richard Green, president and chief executive of cable consortium CableLabs,] said. "Verizon is the toughest competitor because it duplicates the cable plant."

That part about Verizon duplicating the cable plant reminded me of something else I came across a while back. While Verizon's FiOS architecture may support high-speed Internet access, and they may be using VoIP to provide telephony service, they have thus far shied away from IPTV. According to this article, Verizon uses two wavelengths on the fiber connection: one for VoIP and Internet data; and the other for video. They use traditional RF broadcast technology over that video wavelength and not, as one might otherwise assume, IPTV.

Categories: IPTV, Verizon, FiOS, Uverse, SBC, AT&T, FTTP, FTTN

Verizon Wireless picks Lucent for EV-DO Rev A

Verizon announced that they will deploy Lucent's EV-DO Rev-A solution. No word, as yet, on when the roll-outs will occur.

[Lucent's EV-DO Revision A] will enable Verizon Wireless to introduce a range of new services such as enhanced push-to-talk, messaging, and Voice over Internet Protocol (VoIP).

According to past press reports, Verizon deployed both Lucent and Nortel EV-DO solutions. They've also trialed Nortel's Revision A solution. So ... will Verizon be announcing upgrades to their Nortel sites, or has Lucent managed to displace their rival?

Categories: EVDO, EV-DO, Lucent, Nortel, Verizon