A properly engineered network decreases customer churn.
OTT video, or streaming media, is an evolving set of technologies that deliver multimedia content over the Internet and private networks. A number of online media platforms are dedicated to streaming media delivery, including YouTube, Brightcove, Vimeo, Metacafe, BBC and Hulu. Streaming video delivery is growing dramatically. According to the comScore 2009 U.S. Digital Year in Review Video Metrix, Americans viewed a significantly higher number of videos in 2009 than in 2008 (up by 19 percent) because of both increased content consumption and the growing number of video ads delivered. (See Figure 1.) In January 2010, more than 170 million viewers watched videos online. The average online viewer consumed 187 videos in December 2009, up 95 percent over the previous year, and the average video duration grew from 3.2 to 4.1 minutes. Hulu, for example, in that same month delivered more than 1 billion streams for a total of 97 million hours. According to comScore, the character of video viewing is changing as well, with more people watching longer content.
There is a growing effort by broadcasters to make regular TV content available online. For example, the BBC has developed the BBC iPlayer and the bbc.co.uk website to support replication of most BBC broadcast material. The service has been outstandingly successful: 79.3 million requests were serviced in October 2009. NBC coverage of the 2010 Winter Olympics included live and recently recorded content, complete with commercials.
Whenever there is the possibility of a large or dynamic viewer audience, a reliable CDN is required. CDNs once only used to replicate website content around the world. Now, they have expanded dramatically to handle streaming media. Research and markets estimated the value of CDN services for 2008 at $1.25 billion, up 32 percent from 2007. Top CDNs include Akamai, Mirror Image Internet, Limelight Networks, CDNetworks and Level 3. Streaming media services must deal with content collected from disparate sources and distributed to a growing number of devices. (See Figure 2.)
The most common network protocol used to transport video over IP networks is the Real Time Streaming Protocol (RTSP). RTSP is a stateful protocol used to establish and control media sessions between a media server and client viewer. RTSP clients issue VCR-like commands to control media playback. The transmission of the audio/video stream itself is most often handled by the Real-time Transport Protocol (RTP), although some vendors have implemented their own transport protocol. RTSP and RTP are almost universally used to implement VOD features.
Most video players, such as the Adobe Flash Player, use proprietary protocols that provide additional functionality and flexibility. Flash Player has an almost total presence on PCs and Macs, and is used to deliver more than 80 percent of online videos. The Adobe Flash Player is a lightweight client embedded in Web browsers. Adobe uses the Real Time Messaging Protocol (RTMP) to deliver streaming content, providing multiple independent channels, which are used to control and deliver content. RTMPT is an RTMP variant that encapsulates RTMP packets in HTTP.
First released in 2007, Microsoft's Silverlight player is growing in popularity within the player market. The Silverlight player uses HTTP as its top-level transport mechanism and for media streaming. Using HTTP as a single transport mechanism can result in significant internal cost reduction for end-to-end delivery. Silverlight includes digital rights management (DRM) features similar to those available in Adobe Flash.
HTTP Live Streaming (HLS) is a media streaming specification that is developed by Apple that uses HTTP as the transport. Devices such as the iPhone, iPad and Apple-compatible platforms support this streaming technology. The “Live” is misleading in the name, as this technology works for on-demand and live streaming. HLS supports streaming media that is segmented into smaller chunks of data, to improve delivery and user experience. An Extended M3U Playlist format file is used that contains the media segments to download.
Modern streaming media technologies adapt to changing network conditions, especially those related to mobile devices. As conditions degrade or improve, the player requests an alternate lower or higher bit rate media stream. Multiple flows are prebuilt or constructed at multiple bit rates and divided into chunks so that a player can seamlessly switch different flows. The ability for a video player to adapt to varying network conditions is termed differently across players. In the Silverlight player, it is called smooth streaming; Adobe Flash 10.1 terms it dynamic streaming; and Apple iPhone's HLS refers to it as adaptive streaming.
Delivery of video to the consumer has undergone rapid change in recent years and is guaranteed to continue to do so in the future. Cable TV networks deliver a large range of content, and the ability to provide user interactive features, including VOD. Carrying the most promise for the future is delivery of video over multiservice IP networks. This is commonly referred to as IPTV. It is delivered as a triple-play service to consumers that include high-speed Internet (HSI) and VoIP.
The major components and data flow in IPTV networks consists of media and control flowing between content servers and home networks.
The two types of video services delivered are linear broadcast and VOD. Both have dramatically different characteristics that affect the networks that handle them. Broadcasts are regularly scheduled programs sent to large numbers of subscribers. It is sent efficiently over multicast IP routes. (See Figure 3.)
VOD service delivery exhibits an entirely different behavior from linear broadcast service. Stored videos are sent to the subscriber on demand. Each subscriber receives his or her own video flow, which they can control with VCR-like controls. (See Figure 4.)
The differences are responsible for the complexity of the delivery network. Broadcast TV over IP is primarily a one-way channel, using well-understood multicast protocols. The home network is responsible for multicast messages and image display. VOD adds another level of complexity. Requests for and control of video content are transmitted upstream from the subscriber to the service provider using RTSP. Video content is returned to the subscriber through RTP.
Until differentiating services are developed for IP-based video-voice-data networks, IPTV services will continue to be compared with traditional TV, cable and satellite service. As such, the IP delivery network must remain transparent to customers. Customers expect video quality and service availability to be on par or better to make the switch. With multiple choices available to consumers, there is little tolerance for poor quality and operational problems. A poorly engineered network can lead to substantial customer churn.
To successfully deploy IPTV, the following end-user requirements must be addressed:
Video quality: Subscribers' perception of quality must be the same or better than other alternatives;
Minimal channel change delay: Because instant response is expected; and
Assured service delivery and availability for an always-on service.
Service providers must systematically test and verify network devices in each of the video transport architectures, including video content servers, core and edge routers, access devices, and customer premises equipment. Such testing provides an understanding of individual device performance and may determine how much impact each has on the overall system. System-level tests that incorporate more than one demarcation point in the transport architecture are required. In this way, a clear understanding of how well the individual systems play with each other is determined. Finally, the network must be tested end-to-end. Most standard routing and forwarding performance tests should be performed, looking at packet loss or latency under different load conditions.
All types of video testing, both OTT and IPTV, require testing through large-scale subscriber emulation. That is, large user communities must be simulated performing “normal” activities in order to exercise video components, subsystems and end-to-end delivery. “Normal” activity is directly related to the type of video delivery.
Broadcast IPTV delivery is highly dependent on multicast operation. In order to avoid sending individual programs to individual users, all viewed channels are broadcast to all users wishing to view particular channels. It is up to the STB and all routers between the source(s) and the subscriber(s) to join and leave multicast groups that correspond to a particular broadcast stream.
Broadcast IPTV testing requires emulation of subscribers engaged in two types of behavior:
Requesting a channel (joining a multicast group), watching for a period of time and then requesting an alternate channel (leaving one group and joining another); and
Rapidly changing channels, often called “channel zapping”.
During this type of testing, the critical measurements are:
Video quality, largely related to jitter and drop outs. Several types of quality of experience metrics, including VMOS and VQMon, produce values that are closely related to how viewers “feel” about their experience;
Channel change latency — that is, the time between channel change request and response.
VOD stream delivery is point-to-point, as opposed to multicast. VOD users have VCR-like buttons at their disposal: play, pause, fast forward, rewind and stop. VOD testing requires emulation of subscribers engaged mostly in viewing and occasionally in VCR-like control activities.
During this type of testing, the critical measurements are:
Video quality, as described above; and
Command latency — that is, response to VCR-like control activities.
OTT delivery is also point-to-point, and testing requires emulation of large audiences of users accessing a larger set of possible sources than with VOD. The same VCR-like controls are available, but due to the generally short nature of OTT content, are generally used less often.
What differentiates OTT from VOD and makes it much more difficult to test is changing connection rates. OTT content is saved many times over at the source for delivery at many different connection rates — for example, high resolution for broadband connections and low resolution for mobile devices. OTT delivery must quickly and transparently switch between streams based on conditions dictated by the consumer.
OTT testing, therefore, must emulate frequent bandwidth changes from a large community of users accessing many possible streams. During this type of testing, the critical measurements are:
Video quality, as described above. Empirically, one's expectations of quality for this OTT delivery are much less than broadcast TV;
Smooth presentation. As bandwidth availability changes, consumers must not be aware of the changeover of streams. That is, there should be no noticeable pauses.
Dave Schneider is senior market development manager at Ixia.