Interest in how to adapt the hybrid fiber/coaxial (HFC) network for the delivery of Internet protocol television (IPTV) is as keen as it ever has been.

This article addresses that question from the 15,000-foot level. It begins by defining key terms, pointing to technical challenges and establishing several broad trends. Those who want to cut to the chase can skip ahead to the discussion of architecture and scenarios. (See page 24).

Several more granular topics not addressed here — which could be the subjects of a later treatment — are listed at the conclusion of the article.

Basic terms

In its simplest form, Internet protocol television (IPTV) is defined as multimedia services — television, video, audio, text, graphics and data — delivered over IP networks.

IPTV is sometimes confused with the delivery of Internet TV. Although both environments rely on the same core base of technologies, their approaches in delivering IP based video services differ according to platforms (public vs. private secure), geographical reach, ownership of networking infrastructure, quality of service, access mechanism and content generation methods.

Hence, IPTV can be broadly categorized as a "managed" or "un-managed" service. A managed IPTV service provides TV-like quality of service delivered over a managed network in which there is control and predictability of data throughput allocation, contention and content. An un-managed IPTV service (e.g. Internet TV) has no guaranteed quality of service and is delivered via the open-Internet or an un-managed network.

While sometimes overdrawn, IPTV’s growth drivers for IPTV are not insignificant, and include the following:

  • Digitization of television

  • Enhancements in compression technology

  • Competition among service providers

  • Growth in broadband usage

  • Emergence of integrated digital homes

  • Wider range of companies deploying IPTV

  • Initiatives to standardize IPTV

Telco challenges

Growth drivers notwithstanding, there are significant obstacles to introducing any new technology. Scaling to several thousand and millions of subscribers is an even bigger challenge.

IPTV initially had technology hurdles to overcome, mostly related to stability and scalability. However, the biggest hurdle has been limited capacity on copper-based telco infrastructure. Telcos accordingly have been investing in plant upgrades and adopting newer technologies, such as ADSL2+, VDSL and fiber to the home or wherever (FTTH, FTTx).

Other obstacles remain. These include high infrastructure costs to the home, end-to-end service reliability and availability, expertise outside of a provider’s core competence and successful business models. Then there are new business relationships with content providers and unexploited interactive aspects of service.

Finally, there is the question of effective and scalable service architectures in a market where all the technologies are still pioneering and no de facto standard exists — although that lack of a common ground is not for want of effort. (For more on standards, see sidebar, page 25.)

Evolving experience

Although IPTV has been widely deployed for many years outside of North America, the recent convergence of Web services, traditional TV and home media networking is building a stronger case for it in this part of the world.

The flexibility of IP technology enhances that proposition, as it facilitates service enrichment and blending.

Proprietary systems, legacy infrastructure and the lack of applications have made service blending a relatively challenging proposition; although enhanced binary interchange format (EBIF) and tru2way-based technologies will certainly help to change this.

Current TV 2.0 IPTV solutions have brought the Web and TV together as a unified experience for the consumer. This is the evolution of the digital TV experience with increased user interactivity. Another recognized value proposition for TV 2.0 is the rapid time to market for an application developed on an IPTV platform that is based on a scalable and well-understood Internet model.

The evolution to TV 3.0 will bring about the benefits of content-sharing technology, creating smaller communities and/or niches of interest that may be driven by demographics, culture, age, or other interests. (See Figure 1.) User behavior will change to "my device on any network," and "my content anywhere I am and anytime I want to access it."

These user behaviors must be translated to platform characteristics, and at the same time technology platforms must be designed to adapt to changing user behaviors in the future. (See TV 3.0 sidebar, page 26.)

Service blending

Creating new architectures and platforms that are designed to evolve with ever-increasing user expectations will need integration of new processes, web services, and require support of interactive applications across all devices and networks.

These kinds of service blends increasingly involve user experience that can be described as:

  • social — content, messages, friends, recommendations;

  • interactive — widgets, chats, voting, gaming;

  • nomadic — location-based services, remote content access; and

  • multi-device — adaptive screens, variable resolution, firmware and OS.

TABLE 1: Push Today, Pull Tomorrow
Push Model Push Model
Characteristics
  • Network to Cosumer
  • Capacity is driven by number of video services
  • End devices are provided and managed by the Service Provider (e.g. STB)
  • Large Service Group size
  • Majority of RF spectrum allocated to Broadcast services
  • Consumer to Network
  • Capacity is driven by number of active devices requesting video services
  • End device may be provided by the Service Provider or directly by CE manufactures
  • Small Service Group size
  • Majority of RF spectrum allocated to Unicast services (e.g. VoD)
Efficiencies gained from Compression, Statistical Multiplexing and Oversubscription (SDV) Compression, VBR multiplexing, Channel Bonding and Oversubscription (SDV)

How does one deliver a TV 3.0 user experience? At a high level, by evolving to network and device-agnostic frameworks that are friendly to the development of applications and the management of content, conditional access (CA) and digital rights, customers and networks themselves.

Reaching this objective has many prerequisites. It calls for adopting new technologies; creating and following openly defined standards; setting reasonable business terms between service providers and CE manufacturers; establishing standardized interoperability testing and certification processes; simplifying network architectures; and evolving existing network platforms while reducing capital and operational expenditures.

FIGURE 1: Evolution to TV 3.0

Transition to unicast

Alongside the move toward personalization among consumers is the fundamental technology shift from broadcast to unicast.

Delivering digital television in a broadcast medium is the most efficient usage of precious HFC spectrum, but the trend to unicast-on-demand will see a shift in the allocation of that spectrum.

The trend will change the model from push-to-consumer to pull-from-network. (See Table 1.)

Network-based personal video recorder (n-PVR) is a clear example of the impact of a unicast service on network resources. Take rates for VOD will grow, leading to scaling of storage, streaming, edge-QAM device capacity, reduction in VOD service group size, and allocation of more HFC spectrum to narrowcast services. Growth in HD and the introduction of new services such as 3DTV and virtual reality will accelerate this trend.

TABLE 2: Comparison of Different Scenarios
SCENARIO 1 > Hybrid SCENARIO 2 > DOCSIS SCENARIO 3 > Fiber
Scenario HybridCPE characteristics HG (with DOCSIS termination) + IP STBs (with MoCA connectivity to HG) ONT + HG (with Ethernet termination) + IP STBs (with MoCA connectivity to HG)

Conditional Access (CPE)

Conditional Access (Network)

Cablecard in HG & Software based in IP STB

Existing (for CableCARD); New for IP STB

Software based in IP STB

Bulk Encryptor or ECM–G

Software based in IP STB

Bulk Encryptor

Delivery path IP Network > Edge QAM and CMTS > HFC > HG > IP–STB
  1. IP Network > CMTS > HFC > HG > IP–STB or
  2. IP Network > CMTS Bypass (UEQ) > HFC > HG > IP–STB
IP Network > OLT > FTTH > ONT > HG > IP–STB
New Infrastructure components
  • IPTV Back office (Middleware & Mgmt)
  • HG & STB Control system
  • CA/DRM system for IP–STB
  • IPTV Bulk Encryptor or ECM–G
  • Video processing equipment (MPEG4)
  • IPTV Back office (Middleware & Mgmt)
  • HG & STB Control system
  • CA/DRM system for IP–STB
  • CMTS capacity
  • IPTV Bulk Encryptor
  • Video processing equipment (MPEG4)
  • IPTV Back office (Middleware & Mgmt)
  • HG & STB Control System
  • CA/DRM system for IP–STB
PROs
  • Lowest upfront CapEx
  • Leverages existing video processing platform, VOD platform & Edge QAM investment
  • Additional HFC spectrum is not required
  • No rewiring required in the home (leverages MoCA for connectivity from HG to IP STBs)
  • Can leverage tru2way middleware & applications or third party IPTV middleware
  • No rewiring required in the home (leverages MoCA)
  • Can leverage Tru2way middleware & applications or third party IPTV middleware
  • Leverages existing VOD platform
  • No rewiring required in the home (leverages MoCA)
  • Can leverage tru2way middleware & applications or third party IPTV middleware
  • Leverages existing VOD platform
  • Cost of HG on low end
CONs
  • Cost of HG on the high end
  • High upfront CapEx
  • New MPEG4 processing equipment is required
  • Additional HFC spectrum is required
  • Cost of HG is in the mid to high range
  • Highest upfront CapEx
  • New MPEG4 processing equipment
  • Cost of FTTH can be prohibitive
Commonalities
  • Common IP Transport Network, VOD platform, IPTV Back office, Application development frameworks and video quality measurement tools
  • IT integration for new systems
CPE characteristics
  • HG = Video QAM tuners + CableCARD + DOCSIS + MoCA + Ethernet + RJ11 + WLAN + DLNA + HDD + UPnP + SNMP/TR69 + DTCP/IP + HNAP + SIP + SDV client + FEMTO + Remote UI (RUI)
  • IP STB = MoCA + Ethernet + DLNA + UPnP + SNMP/TR69 + DTCP/IP + SIP + Memory + Middleware + RUI
  • HG = DOCSIS + MoCA + Ethernet + RJ11 + WLAN + DLNA +HDD + UPnP + SNMP/TR69 + DTCP/IP + HNAP + SIP + FEMTO + Remote UI
  • IP STB = MoCA + Ethernet + DLNA + UPnP + SNMP/TR69 + DTCP/IP + SIP + Memory + Middleware + RUI
  • HG = Ethernet + MoCA + RJ11 + WLAN + DLNA + HDD + UPnP + SNMP/TR69 + DTCP/IP + HNAP + SIP + FEMTO + Remote UI
  • IP STB = Ethernet + MoCA + DLNA + UPnP + SNMP/TR69 + DTCP/IP + SIP + Memory + Middleware + RUI

Switched digital video technology (SDV) is a combination of a push/pull model. It is a pull model when a user’s channel change message makes a network request for a video service that is not being switched in that service group. SDV also behaves as a push model when a video service is already being switched in the service group (i.e., when the tuning information in the mini-carousal is leveraged to join an existing switched service.)

SDV technology is, therefore, a useful tool that assists in this transition from switched broadcast to switched unicast.

SDP, architecture

At a high level, services delivered to an end customer pass through different providers that own and operate different aspects of the end-to-end service delivery platform (SDP).

Interaction between the different providers is enforced through mutual business agreements. In some situations, an end-to-end service provider will own all aspects of the SDP, thus serving as content provider, service provider, and network provider.

A cable operator often owns and operates the SDP, including the content source, the service management or control plane aspect; the access network; and the customer premise equipment.

TABLE 3: Packet Encapsulation Layers
Video Coding Layer Audio and video elementary streams form the basis for this layer. The format of the streams employed at this layer depends on the compression algorithm used by the encoder (typically MPEG4/AVC)
Video Packetizing layer Creates a stream of time-stamped PES packets
Transport stream construction Packetizes audio and video bit-streams into 188 bytes packets
RTP layer (optional) Although UDP is the preferred transport layer protocol for delivering IPTV content across a broadband network, it is not a reliable protocol and does not support error correction or dealing with packets that arrive out of order. RTP can be used to address these deficiencies.
Transport layer Ensures that IPTV packets arrive at their destination point. (TCP and UDP operate at this layer). Because of its low overhead, UDP is a better choice over TCP when it comes to communications services like multicasts and broadcast delivery.
IP layer Deals with routing IP packets over the network (handles addressing and congestion control).
Data link layer Handles the mechanisms used to access the network media (Error correction, synchronization and flow control)
Physical layer Defines the physical attributes of the network media

New types of providers that offer un-managed IPTV services directly to the end consumer makes the network provider a bit-pipe provider. This is not a long-term, sustainable business model in a market where margins for delivering capacity are decreasing due to competitive pressure and the effect of commoditization.

So what would a cable IPTV solution would look like beginning from the headend and terminating at the customer premise? How does one develop a solution that helps evolve the existing assets and platforms while maintaining the principles of flexibility, scalability, reliability and manageability?

Accompanying this article is end-to-end architectural view that addresses those questions. (See enclosed wall chart.) Table 2 also identifies three related options, with their pros and cons. Since the comparison is purely technical, readers should analyze the cost aspects, as well. Cost models — not addressed in this article — must include the capital and operational aspects of managing and maintaining the SDP.

In the enclosed wall chart diagram, the functions in cream-colored boxes represent the existing cable interactive services delivery platform for broadcast video, VOD and SDV services. This can be considered as a network baseline, built upon with additional components as new services are delivered to the end customers.

With the introduction of tru2way (functions represented in green), additional interactive services are delivered with the addition of client/server components on both legacy and next-generation tru2way capable set-top boxes. Existing DOCSIS infrastructure is leveraged with the addition of DOCSIS Set-top Gateway (DSG) technology (mostly a software upgrade to existing CMTSs).

IPTV is one step further; however, it leverages all of the existing and tru2way investments. The IPTV functions (represented in the gold boxes) are built upon existing infrastructure assets. Commonalities are the IP transport network, SDV infrastructure components (video processing and distribution), the VOD platform and electronic program guide (EPG) application data.

This architectural diagram posits several options for the delivery of IPTV services at the home.

A hybrid home gateway combines video quadrature amplitude modulation (QAM) tuners and DOCSIS QAM tuners. CableCARDs help leverage the existing CA system. This option does not require additional HFC spectrum allocation — a significant advantage. IPTV set-tops communicate with the home gateway over Multimedia over Coaxial Alliance (MoCA), so as to leverage the existing in-home wiring. These set-tops can have a new CA/DRM system.

A DOCSIS-based home gateway has multiple DOCSIS QAM tuners. This approach requires additional HFC spectrum. In both of these options, tru2way middleware or a thin browser-based middleware can be the basis of service application development.

A third approach involves an optical network terminal (ONT) with Ethernet-based home gateway. Table 2 provides a detailed comparison of these three scenarios Wireless is yet a fourth way to deliver IPTV services to the home — or wherever. Coming to a conclusion on which approach should be taken can only be made once the cost implications are quantified.

The final section of this article addresses additional elements within the IPTV architecture, first taking another look at the gateway.

Home gateway

In general terms, the home gateway terminates the network side interface and provides LAN side connectivity to the various devices through which managed services are provided.

It is a single termination device for voice, video and data services provided by the service provider. It is also a service policy enforcement and management point in the home. In the case of IPTV service, IPTV set-tops are physically connected to the gateway via coaxial cable or Ethernet. Since residential coax typically spans multiple rooms in the home, multi-room connectivity can be provided by MoCA-based technology.

As for MoCA, it operates in the 1.1 — 1.5 GHz band, so does not interfere with cable services below 1 GHz; version 1.1 can provide up to 175 Mbps of net throughput; it offers a prioritized QoS mechanism; and enables up to 16 devices to operate on a channel

The gateway can also provide other forms of connectivity such as WLAN and femtocell (fixed mobile convergence) to allow for blending of wireless and wireline services. (For schematic, see Figure 2.)

FIGURE 2: Residential Home Gateway and IPTV Set-Top Box

Encoding to distribution

Elementary audio and video streams combine to form MPEG transport streams.

The H.264/advanced video coding (AVC) specification defines two sublayers for this transport layer. The video coding layer (VCL) compresses the video content. The output from this layer is a series of picture slices. The bitstream at the network abstraction layer (NAL) is organized into a number of discrete packets called NAL units. (See Table 3, page 25.)

There are two options available to encrypt broadcast video services. One option is through an IPTV bulk-encryptor (similar to approach used in SDV architectures). The second option is to use an external key generator (such as ECM-G) interfacing with the edge-QAM modulator. In that case, the edge-QAM modulator itself does the encryption (similar to how VOD handles it today).

Although both approaches are viable, use of an IPTV bulk-encryptor is preferable because of cost implications. However, the bulk encryptor’s potential as a single point of failure calls for considering an active redundancy mechanism.

Because VOD services are inherently session-based, bulk-encryption is not preferable, due to scalability and cost implications. Other options are pre-encryption of VOD content, where content stored on VOD server is already encrypted; and edge-QAM modulator-based encryption.

IPTV backoffice

Supporting these network elements is a backoffice containing these elements:

Subscriber management system. The SMS is used in conjunction with other IPTV network elements to activate, fulfill, and provide IPTV services in real time to meet customer requirements.

Information processed by the SMS during the provisioning of a new service can include the subscriber’s name and address; billing and payment details; IPTV multicast programs required; IP-VOD assets required; network throughput usage required to provide a new service; IP address allocation for a new service; and the subscriber’s desired time for installation and provisioning of new services.

Customer relationship management. The CRM system provides visibility into the sales of particular packages of services. A typical CRM may be classified into three different modules that entail interfacing wih the customer, marketing of products and services, and selling products and services.

CA/DRM. The output from the encoding system is fed into a security system for content protection. The purpose of the IPTV security system is to restrict access to subscribers and protect against the theft of IPTV content. The security system consists of CA and DRM.

Middleware/application servers. Middleware falls into two defined categories: client and server software. The middleware server software is implemented on a series of application servers that are running at the IPTV data center.

IPTV headend middleware and application servers interact with the backend OSS/BSS and CA systems, help to manage the provisioning of new subscribers, billing, and overall management of video assets, hosting software applications, support the user interface for both IPTV multicast and on-demand services.

Adopting industry standards leads to competitive pricing from multiple suppliers and helps to reduce overall IPTV deployment costs. There is no common middleware standard defined for the overall global IPTV industry. There are however a number of middleware standards that are been adapted to provide IPTV functionality. (See sidebar.) Many IPTV vendors have proprietary middleware solutions.

The cable industry has already made a significant contribution to standardize the middleware technology via tru2way. Additional functions can be added to tru2way that enhance IPTV services.

Closing remarks

In its basic form, IPTV is delivery of video services using IP technology. Coupled with its interactive nature, cross blending of services and low-cost set-tops, IPTV is a compelling service delivery platform.

That said, cable network architectures could evolve to this new platform with the addition of new functions. This is a technology evolution, not a revolution.

The goal here was to illustrate that larger evolutionary theme. Left unaddressed are some of the following topics:

  • Throughput/capacity estimation and optimization process

  • Service group combining and node segmentation

  • Strategies for creating HFC spectrum

  • CMTS and bypass

  • Video quality measurement

  • Common control plane and signaling

  • Application development framework

  • Cost model creation

Stay tuned for a possible follow up that addresses those topics in more detail.

Sandip Singh is architect, video technology, at Rogers Communications. This article represents the views of the author.

Standards Initiatives

Numerous groups are working to develop common IPTV architecture frameworks. They including the following:

  • DSL forum

  • Moving Picture Experts Group

  • ETSI

  • Open IPTV Forum

  • Broadband Services Forum

  • ITU-T FG IPTV

  • ATIS

  • IPDR Organization

  • Internet Streaming Media Alliance

  • DVB-IPI

What is TV 3.0?

Shaping up to be a blend of social communities and TV 2.0 (itself a combination of Web television and first-gen IPTV), TV 3.0 includes the following charactertistics:

  • Non-linear, personalized user experience

  • Advanced content search functionalities

  • Unlimited access to content

  • Platform Independent

  • Device independent

  • Location independent

As a concept, TV 3.0 has been around for several years, with cross-industry events now being organized around the theme.

Middleware standards

Existing interactive television middleware standards adapted to provide IPTV functionality include the following:

  • Multimedia Home Platform (MHP)

  • Globally Executable MHP (GEM)

  • OCAP (aka tru2way)

  • Advanced Common Platform for Interactive Television (ACAP)

  • Association of Radio Industries and Businesses (ARIB) B23.

The Daily

Subscribe

Comcast Entering Carriage Renewals With Open Mind

Comcast ’s domestic video customer net losses were 487,000 during 1Q24. Leadership didn’t have much to say when it came to the Xumo streaming platform, but President/CEO, Connectivity & Platforms Dave

Read the Full Issue
The Skinny is delivered on Tuesday and focuses on the cable profession. You'll stay in the know on the headlines, topics and special issues you value most. Sign Up

Calendar

Jun 13
2024 American Broadband Congress Conference Registration is Open!
Jun 26
2024 FAXIES Awards Nominations Are Open!
Full Calendar

Jobs

Seeking an INDUSTRY JOB?
VIEW JOBS

Hiring? In conjunction with our sister brand, Cynopsis, we are offering hiring managers a deep pool of media-savvy, skilled candidates at a range of experience levels and sectors, The result will be an even more robust industry job board, to help both employers and job seekers.

Contact Rob Hudgins, [email protected], for more information.