IPTV This Time Around
Yet another reason why it’s always good to ask someone what they mean by “IPTV:” At least seven international standards-setting bodies are working on it. One has eight sub-categories.
Perhaps not surprisingly, all hail from different industry sectors. The European over-the-air broadcasters do IPTV via the DVB (Digital Video Broadcast). Wireless carriers work through the OMA (Open Mobile Alliance).
And then there’s the standards workhorse known as the IETF (Internet Engineering Task Force.) It’s the one with eight subcategories.
NOT JUST FOR TELCOS NOW
The first time this column looked in on Internet Protocol Television was in late August of 2005. At the time, it was mostly a telco thing. It remains AT&T’s not-so-secret sauce.
Then, we defined IPTV as “an amorphous term describing the delivery of digitized video over the passageway used by devices that ‘speak’ in Internet Protocol (IP), such as cable and DSL modems, and anything with an Ethernet connector.”
Here’s how the International Telecommunications Union (ITU) defines IPTV: “Multimedia services, such as television/video/audio/text/graphics/data, delivered over IP-based networks managed to provide the required level of QoS/QoE, security, interactivity, and reliability via intelligent terminals such as PCs, STBs, handhelds, TVs, and other terminals.”
Translation into cable-speak: It’s about sending additional video formats, through the cable modem (or set-top with embedded cable modem), to screens that move (phones, handhelds) and screens that stay where they are (TVs.)
The “QoS/QoE” stands for “quality of service / quality of experience,” which, in cable’s engine rooms, happens within the PacketCable Multimedia (PCMM) specifications at CableLabs.
“Security” will mean a morph to DRM (digital rights management), from conditional access. “Interactivity” is up for grabs.
NOW FOR SOME COMIC RELIEF
Speaking of security, let us also heed Dilbert. The boss asks about a standards-setting meeting: “Did you convince 83 companies to adopt standards that only benefit us, while dooming the rest of the industry in the long term - or are you a complete failure?”
Dilbert: “Can I hear those choices again?”
Stumped by gibberish? Visit Leslie Ellis@www.translation-please.com.
Ian-I-Am commented:
IPTV to really be TeeVee (Tele-Vision) needs to run ubiquitously and beyond the ISP’s network (walled garden). But right now IP Multicast lacks the elements to create the business model.
The missing elements:
::Backbone Security:: Television networks and system integrators must have the extra assurance they need. They need assurance that goes beyond point-to-point encryption and decryption. Their critical multipoint backbone must be impervious to attack. Without enhanced backbone security (Multicast Repeating) there is no profit motive for broadcasters or system integrators. Currently, only one company provides a method for Public Multicast repeating. There needs to be more.
::Enanced Reliability:: Native Multicast lacks a mechanism to enable a solid picture on wireless networks without overly bloating the backbone signal with redundant data (FEC or Forward Error Correction) - Without an enhanced “no bloat” reliability feature, high definition TV (HDTV) signals would become to bandwidth intensive for transmission without expensive equipment upgrades. A reliability mechanism that doesn’t bloat the signal is needed in order to enable legacy equipment.
::Multipoint Bi-Directionality:: Multicast needs a protocol that addresses high speed channel surfing (dynamic accelerated buffering). Such a bi-directional protocol could also offer Increased revenue opportunity (targeted commercial insertion), a database log of who’s watching, AND of course quality of signal reporting.
::Automated Environment Testing:: A self implementing multicast level escalation mechanism is needed to establish the best method of multi-point connectivity and, where none exists, a 4th level (US model) protocol to create a tunnel to the NEAREST (think TCP latency limitations) multi-point enabled network.
::Source Discovery for IPV6:: SSM must have IGMPV3 in order to work, yet IGMPV3 has been absent from the MAC OS and most Universities use IGMPV2 at the IPV4 edge. The IPV6 community doesn’t want another flooding discovery protocol (like MSDP), so IPV6 Multicast needs an elegant discovery protocol that doesn’t add to Internet Message Processor (router) overhead. Vint Cerf, Paul Vixie, Kevin Almeroth, Joe Breen, Brian Billadeau and Ian A. Stewart have proposed to address this problem as a test bed for the “Directory of Persistant Objects”.
In our opinion, these tools at a minimum are needed for a Public Multicast business model.
Ian-I-Am