Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Winning and Retaining IPTV Subscribers: Why Performance Matters


Published on

  • Be the first to comment

Winning and Retaining IPTV Subscribers: Why Performance Matters

  1. 1. 1 espial white paper series 1 1 1 Winning and Retaining IPTV Subscribers: Why Performance Matters The accelerated growth of home DSL broadband connectivity and the continuing rollout of high-speed fiber networks to the home is pushing IPTV out of the Telco labs and into the living rooms of homes around the world. However, cable and satellite incumbents are not standing still; they are expanding their service offerings beyond traditional TV services to gain and retain more subscribers. In order to secure a competitive advantage over these incumbent TV leaders, Telco IPTV offerings will need to include a rich portfolio of applications including EPG, VOD, DVR and on-demand interactive TV services such as shopping, messaging, PC media sharing, converged fixed mobile services and games. It is these unique IPTV services that will provide a major competitive differentiator over cable and satellite offerings. The consumer user experience will be critical to the success of these offerings and help to overcome the many challenges that are foreseen for Telcos to attract and maintain a large IPTV subscriber base. Services such as EPG and shopping will increasingly require higher volumes of data which can slow networks and set-top boxes (STB) down. In parallel to this, the consumer electronics market is creating an expectation of visually stimulating UIs. This means that low-cost, resource-constrained STBs must now bear the brunt of dedicating more CPU cycles to manage the increased UI demands along with the ever-increasing data load required. There is a limit to the resources available on any of these set-top boxes so application performance, and the consumer user experience could suffer if operators do not evolve their middleware to meet the tougher demands posed by these new services and new feature-rich UIs. Espial Evo® Client is a next-generation client-side middleware solution that is designed to address and exceed these evolving IPTV data and UI requirements. This whitepaper contrasts two client-side IPTV middleware architecture models: the original 1st generation IPTV model versus the Evo Client data-driven model. By evaluating response times of two common user experience scenarios (EPG load time and EPG navigation response), this paper shows how adopting Espial’s next-generation Evo Client client- side middleware architecture results in significant performance gains, which translate into greater customer satisfaction. 1st Generation IPTV architecture A majority of current lab trials and commercial deployments utilize a browser-based client-side architecture. This is a customized web browser on the client STB that acts as a framework for key IPTV applications such as EPG, VOD, as well as other interactive web-based TV services such as news and weather. These applications are written in HTML and JavaScript, the markup and scripting languages of the Web. The advantage to writing applications in these languages is that they are dynamic and relatively easy to develop, customize and update by third parties because of the open web standards that they support. However, there are also a number of significant disadvantages to writing applications in HTML and JavaScript that are often overlooked but need to be seriously considered. One of the largest problems for the browser-based model is its monolithic architecture, which tightly links the application’s UI with its data. The data needs to be either embedded in the HTML page or linked from it. The consequence of this is that additional data cannot be independently managed and updated without UI changes and vice versa. For data-intensive applications like EPG, this constraint leads to inefficient network load and poor application response. November 2006 1
  2. 2. Winning and Retaining IPTV Subscribers: Why Performance Matters 2 Secondly, this model demands dependencies external to the set-top box. Each time there is a user interaction (e.g. remote control button pressed), the browser must contact the server and download a new HTML page. To the user, this feels similar to a Web browsing experience: click, wait and then interact. This is cumbersome and does not match the typical consumer electronic experience, like watching TV, which is setting the user expectations that subscribers have come to expect. Finally, HTML and JavaScript both require heavy processing. Each HTML page needs to be parsed, processed and rendered every time it is requested. JavaScript also needs to be parsed, processed and then executed. Execution of JavaScript may also result in dynamic changes to the rendered HTML, which again will need to be parsed, processed and rendered. When displaying complex applications, like the EPG, this can lead to significant lag in performance and responsiveness to the subscriber. Why is the browser-model still so popular? This 1st generation model is still in use in IPTV deployments because it works well for simple applications that have limited data and UI requirements, which are precisely what early IPTV services offered. However, the browser still has an important place in current generation IPTV deployments. Instead of leveraging the browser as a framework for critical IPTV applications like EPG, the browser can more appropriately be focused on Internet-on-TV services and deploying simple new web applications that are less data intensive and supplementary to the TV viewing experience (such as news, weather and other portal applications). AJAX as an alternative Web standards are continually evolving and one technique in particular called AJAX warrants discussion here. AJAX (Asynchronous JavaScript and XML) is a web development technique for creating interactive web applications. AJAX uses a combination of HTML and JavaScript to allow dynamic display and interaction, while using XML, XSLT and XMLHttpRequestObject to interchange and manipulate data asynchronously with a web server. AJAX directly addresses the first two problems discussed in the previous section, namely decoupling data from the UI and improving the awkward “click, wait and interact” web application experience. The main problem that still exists, however, is performance. AJAX leverages HTML, JavaScript and XML heavily and does not solve the burden of parsing, processing, and executing these on CPU-sensitive STBs. Evolving IPTV service demands IPTV services are going through rapid evolution. Large scale IPTV deployments have channel lineups now that typically contain detailed programming information for over 300 channels, spanning a minimum of one week. Data for other interactive services is dramatically increasing as well. For example, VOD catalogs alone can typically exceed 5000 titles, each of which require a description that needs to be downloaded and displayed. Interactive on-demand services include data such as weekly weather, daily news stories and more. With advanced interactive content and services such as these, UIs need to be more functional to provide users with an intuitive and responsive way to access data. The most compelling consumer electronics user interfaces feature animations, transparency and other effects to support new services and engage customers. With advanced interactive content and services, UIs need to be more functional in order to provide users with more intuitive navigation and access to services. Easier navigation and scrolling are becoming important ways for operators to differentiate their services. Fancier, eye-catching animations require increased use of DHTML and JavaScript. This can mean parsing and processing hundreds (if not thousands) of lines of code on the STB each time a screen is rendered - all of which can result in extremely slow response times. After examining current and growing IPTV service demands, it is clear that continued use of the browser-based or 1st generation architecture model will introduce performance 2 November 2006
  3. 3. Winning and Retaining IPTV Subscribers: Why Performance Matters problems while using critical IPTV applications such as the EPG. These applications are complementary to the TV viewing experience and are often accessed by the subscriber during a viewing session. Do consumers who are used to fast response in their cable or satellite STB EPG program really want to wait five to six seconds every time they access their guide for EPG information to appear? Will they tolerate a painfully unresponsive scroll through hundreds of channels? The answer is most certainly, no. Achieving performance through a client-side data-driven architecture The key to ensuring that an IPTV experience is responsive is an evolved architecture that supports an efficient way to handle data and the user interface. Therefore, two main considerations in a next-generation architecture are: 1 A data-driven architecture that de-couples data management from the UI Generally speaking, this architecture is more efficient. It handles heavy data processing and caching at a lower-level by using native languages rather than scripting functions which need to be parsed and processed at run-time. 2 An advanced UI rendering engine With this architecture, UIs can be written with less markup and scripting code. They can then be processed through an intelligent rendering engine that requires fewer parsing and processing cycles to rapidly display dynamic UIs. The Evo Client data-driven model is an evolution from the monolithic browser-based model, where UI and data are intertwined. The Evo Client model essentially decouples data management on the STB from the presentation and interaction of that data by the user. By separating these two functions, the overall performance of the user experience improves significantly. The following sections explain how the architecture of Evo Client’s data-driven model and advanced UI rendering engine can significantly improve performance over 1st generation models. This portion of the paper will illustrate why large scale IPTV offerings require this next-generation architecture and will reference analytic comparisons of two current IPTV consumer use cases, in both the browser-based and Evo Client models. How the Evo Client data-driven model improves performance Evo Client is an open IPTV middleware platform. The Evo Client Application Platform is a modular framework containing an advanced data-driven application manager and UI engine for User Interfaces or Evo SkinTones™. Evo Client has several advanced applications that build on this application platform, including EPG, VOD, Subscriber Settings, DVR, Pay-Per-View, Walled-Garden Portal, Internet-on-TV, Caller ID, and Radio TV. The following points summarize the key advantages of the Evo Client data-driven model, where UI and data are decoupled: • less network activity required because data is cached, leading to improved end-user response time and reduced latency. • High performance data management that is done at native-C level, not at the HTML/ JavaScript level. • UIs and Evo SkinTones can present data in any visual representation that makes sense, and access data in a standard, well-defined manner. Separating data from UI allows for an Evo Client application to be coded in native-C language, ensuring superior performance. Each application can now be seen as having three main duties: • to input and manage data into its memory space from any external network data source, regardless of data format November 2006 3
  4. 4. Winning and Retaining IPTV Subscribers: Why Performance Matters 4 • to manage data and process business logic on that data-set in a memory-aware and performance-sensitive manner • to allow the user interface layer to retrieve and manipulate data for presentation via a JavaScript API. Figure 1-1: Browser architecture Figure 1-2: Evo Client data-driven architecture Let’s take a look at how these points apply to the Evo Client EPG data application. First, the Evo Client EPG data application module includes a driver interface for gathering raw data from any data source. This data can include numerous fields such as program name, ratings, categories, detailed programming information, and start/end times for current, future or even past time periods. Additionally, the Evo Client EPG data application can ingest service information (SI) data on channel line-ups, icons, etc. Best of all, this driver interface to the EPG data application is open and allows fast integration by customers. 4 November 2006
  5. 5. Winning and Retaining IPTV Subscribers: Why Performance Matters A second way the data-driven architecture shows superiority is within the Evo Client EPG data application code. It has logic in place to: • schedule and manage updates within the network service automatically • handle the caching of data on the STB • build indexes of data for faster searching • normalize data into a compressed binary representation requiring less network traffic • allow channels and programs to be marked as favorites, or flagged as blocked for parent control purposes • manage memory utilization by decompressing and releasing data in optimized virtual pages Since the application runs natively, processing these functions is highly efficient. Finally, as a service to the UI, the Evo Client EPG data application exposes a well-defined JavaScript API. Functions can provide the ability to retrieve a window of EPG data for a given a time period; query detailed programming information; block specific channels; set auto-tune reminders; filter EPG data for certain categories like PPV and favorites; and much, much more. How Evo Client’s advanced UI rendering engine improves the user experience Evo Client also provides an advanced UI rendering engine to complement its data-driven applications. This rendering engine completely defines the UI “look and feel” or Evo SkinTones for an Evo Client application, and handles all events and user interactions. The advanced UI rendering engine offers three main features which help to improve performance and the overall user experience: 1 Simplified markup and scripting language 2 Compilation 3 UI widget platform As you will learn in more detail below, these three main features offer the perfect balance between standards-based development, portability and performance of applications. 1. Simplified markup and scripting language Improper syntax and standards misuse are a common problem in web development and because of this, web browsers must perform a significant amount of work to render content as it is expected to look like. Unfortunately, this deductive work generally translates into lost performance due to extra cycles for validation and error checking. The more HTML elements and JavaScript code included in an application, the more parsing, processing and execution time is required by the middleware. By carefully selecting and then enabling HTML elements and JavaScript to a subset that provides key functionality, and by introducing specific extensions to aggregate commonly used functionality (like animation), it is possible to optimize both the content development time and the resulting user experience. Evo Client also introduces special optimized extensions for layers, animations and effects. These again result in development efficiency over what previously in other systems would have required development using HTML and/or JavaScript, or which would have required many hundred lines of code. 2. Compilation Evo Client UI code can be delivered to the Evo Client Application Platform in two ways. The first is as an HTML source code document and the second is as a compiled binary November 2006 5
  6. 6. Winning and Retaining IPTV Subscribers: Why Performance Matters 6 format file. The advantage of the compiled binary is performance. The UI can be rendered directly to the screen which means that the rendering engine has one less step to perform (parsing/processing), resulting in better performance. The compiled binary format is not platform dependent so all applications remain completely portable. 3. UI widget platform The Evo Client advanced UI rendering engine includes pre-built UI widget components called plug-ins. These special purpose application extensions simplify the creation of full UIs by offering components that provide a visual representation of a given data set. Examples of available widgets include sliders, channel lists, grid objects for the guide and much more. Also, because all processing is performed natively, interacting with data via a plug-in can be much faster than attempting to use markup and scripting. 1st Generation vs. Evo Client: use case comparisons There are two use cases that are commonly used to evaluate the subscriber experience in a TV environment. They are EPG load time and EPG navigation response time. Besides basic TV viewing, the EPG is arguably the killer STB application; therefore, these two use cases are extremely important to judge both the performance and usability of the IPTV offering. On average, the EPG is accessed by a user five times during every hour of TV viewing. For each use, the EPG is navigated through an average of 100 channels. Research has shown that the average acceptable response time for loading the EPG guide is one to two seconds, while navigating 100 channels is between ten and fifteen seconds. From a customer standpoint, response times that fall outside these ranges can lead to dissatisfaction, increased support calls and even cancelled services. 1. EPG load time use case EPG load time is the time it takes for the STB to display the EPG guide with fully populated data. It is calculated from the time the user presses the EPG or Guide button on the remote, to the time the EPG is displayed on the screen. In this case, the factors contributing to response time include rendering the EPG guide and collecting and processing the EPG guide data. Measuring the EPG load time in a browser-based model In a purely browser-based model, the following steps need to be completed before obtaining a fully populated EPG guide. NOTE Several steps makes this an onerous process! 1 The user presses the EPG key on the remote. 2 The browser’s JavaScript engine receives the command and processes it. 3 The browser creates a network connection to the EPG server. 4 The browser waits for the network to reach and connect to the EPG server. 5 The EPG server receives the request and accepts the connection. 6 The EPG server authenticates the request, processes the query, and verifies in the cache if it has the result. If so, the execution flow skips to step 13. 7 The EPG server requests the database server to get the appropriate information. 8 The EPG server waits for the network to reach and connect with the database server. 6 November 2006
  7. 7. Winning and Retaining IPTV Subscribers: Why Performance Matters 9 The database server processes and generates results for a query from data on disk, or in memory. 10The database server sends the results to the EPG server. 11 The EPG server downloads EPG data from the database server. 12The EPG server receives the information and generates the HTML/JavaScript to encapsulate it. 13The EPG server sends the result to the STB. 14The STB downloads the results from the EPG server over the network. 15The STB browser receives the result. 16The STB browser parses the resulting HTML and compiles the resulting JavaScript. 17The STB browser lays out the HTML and renders the page. It then executes the JavaScript and displays the guide. This process has an approximate elapsed time of 4.46 seconds* per request which is well above the average acceptable response time. The total time includes time taken for for downloading the visible window of data each time the EPG is accessed, plus time for rendering the resulting HTML/JavaScript code to display the EPG guide to the user. Figure 1-3 highlights the bottlenecks that are associated with this process. Figure 1-3: Browser EPG flow 1 Each time the EPG is loaded, a client-server connection must be managed to download the current data (which could subsequently require another network connection to query a database for the data). 2 Again, each time the EPG is loaded, the browser must download, parse and process the HTML/JavaScript for the EPG screen as well as the EPG data. Measuring EPG load time in the Evo Client data-driven model In Evo Client, EPG guide data is downloaded from a network server at the driver level. The downloaded data is then managed by the EPG application, where it is cached until the next update period. When the Evo Client EPG UI requests a time window of EPG data from the EPG application, the application retrieves the appropriate data from the cache and provides this back to the EPG UI. In Evo Client, the following steps need to occur in order to obtain a fully populated EPG guide: 1 The user presses the EPG key on the remote. 2 The Evo Client Application Platform receives the command. 3 The Evo Client Application Platform starts the local EPG application. 4 Evo Client makes a call to the local EPG application to display current information. November 2006 7
  8. 8. Winning and Retaining IPTV Subscribers: Why Performance Matters 8 5 EPG application retrieves the currently visible window of EPG information from the cache. 6 EPG application provides data to the EPG UI skin 7 The EPG UI skin renders the grid widget with only the visible window of data. This entire process has an elapsed time of less than one second* - a considerable difference from the browser-based model’s 4.46 seconds* load time! Figure 1-4: Evo Client EPG data-driven flow 2. EPG navigation response use cases For comparison purposes, the EPG navigation scenario is comprised of three separate but related use cases, namely: 1 Navigating within visible EPG guide program cells on the same page 2 Navigating to EPG guide program cells on an adjacent page 3 Fast scrolling through 100 channels. Measuring the navigation times in the browser UI framework The browser-based model displays the EPG guide in a web page where an HTML table element serves as the grid. Rather than displaying all 100 channels (rows) on the screen at once, a subset (or page) of channels is displayed and a scrolling mechanism is implemented. Each time the browser receives a navigational command, it must: • process the JavaScript to navigate to the next program cell in the table • re-render certain HTML elements to change their look and feel (i.e. update the background color and font of the new program cell, the newly highlighted program cell, update the background color and font of the old program cell, update the program information text, etc.) • update and refresh the web page to display new rows of data when scrolling has occurred In the browser-based model, once a user navigates past the visible window of the guide, the browser must communicate with the server and return back new data within the new visible range. The worst case scenario would be to have to do this for every new row, requiring the page to be refreshed each time. However, many implementations now handle this scrolling feature more efficiently. They do this by caching information on 20-30 channels in the JavaScript code. This situation also reduces the number of times the browser needs to refresh the entire screen. Assuming that some sort of order for the user to navigate to a channel that requires scrolling: 8 November 2006
  9. 9. Winning and Retaining IPTV Subscribers: Why Performance Matters 1 The user presses the appropriate up/down/left/right arrow key on the remote. 2 The application receives the command. 3 The browser processes the JavaScript and renders certain HTML elements to paint the screen with the newly highlighted grid program cell, the new visual cues, and returns the formerly highlighted program cell to a “normal” view. 4 When the user navigates to a channel that is not in the visible grid, but requires a scroll to an adjacent page, the browser makes a call to the network for the EPG server. 5 The network forwards the request to the EPG server. 6 The EPG server receives the request. 7 The EPG server verifies in the cache if it has the result. If so, the execution flow skips to The EPG server sends the result to the STB. 8 The EPG server requests the database server to get the appropriate info. 9 The network forwards the request to the database server. 10The database server collects the information on disk or in memory. 11 The database server sends the results to the EPG server. 12The network forwards the request to the EPG server. 13The EPG server receives the information and wraps it around the appropriate HTML/ JavaScript code. 14The EPG server sends the result to the STB. 15The network forwards the result to the STB. 16The STB browser receives the result. 17The STB browser parses the result. 18The STB browser lays out the results and displays the grid. Measuring the navigation time in the Evo Client widget UI platform In the Evo Client model, an advanced UI rendering engine is used to significantly improve both UI display and interaction. In addition to the simplified markup and compilation features mentioned in section one (EPG load time use case), the advanced UI rendering engine also offers UI widgets to display data-intensive components on screen. For example, even though the Evo Client EPG guide is an HTML-based page, the actual grid of the EPG is a widget component that is defined in native-C code. As soon as a navigational command is received, the grid component takes control and all processing and display is performed natively. This saves valuable processing time. The required steps are primarily the same as those outlined in browser UI framework with the exception of two elements: 1 All data is cached on the STB - there are no requirements to obtain further information from the EPG network server. 2 The processing overhead is drastically reduced since there is no need for parsing, interpreting and executing HTML and JavaScript through a browser engine. Because Evo Client already caches the data on the STB, Evo Client is able to present a significantly improved EPG navigation response to many of the previously mentioned sub-use cases. November 2006 9
  10. 10. Winning and Retaining IPTV Subscribers: Why Performance Matters 10 Comparing More Navigation Uses Cases The browser-based model is unable to offer a navigational experience that utilizes a fast scroll, where a user can navigate through the EPG guide in turbo-mode in order to get to a desired channel or time slot. The Fast Scroll mechanism provided by the Evo Client EPG grid widget however, allows the user to navigate to 100 channels in 12 seconds*, 6 hours ahead in 2.6 seconds*, 12 hours ahead in 3.7 seconds* and 18 hours ahead in 5.1 seconds*. Figure 1-2 on page 4 shows that the widget UI platform works at the application level and is called from the UI. The widgets interact with platform drivers to provide the visual elements native to them. 1 The user presses the appropriate up/down/left/right arrow key on the remote. 2 The Evo Client Application Platform receives the command. 3 The Evo Client Application Platform sends the command to the EPG grid widget. 4 The Evo Client EPG grid paints the screen with the newly highlighted program cell, the new visual cues, and returns the old program cell to a “normal” view. 5 If the user is on the edge of the EPG grid window, the EPG grid window updates with new EPG data from the cache and renders the new data. 6 Therefore, benchmarking of the Evo Client widget UI platform, compared to the browser-based UI has shown the following results for each of the three sub-use cases: 7 Navigating between visible EPG guide program cells with Evo Client takes an average of 55 milliseconds*, versus the browser-based model at 220 milliseconds*. 8 Navigating from a visible EPG guide cell to a cell on an adjacent page (scrolling) with Evo Client takes an average of 0.165 seconds*, versus the browser-based model at 1.94 seconds*. 9 Fast-scrolling through 100 channels with Evo Client takes an average of 12 seconds*, versus scrolling 100 channels in the browser based model at 3 minutes, 1 second*. Table 1-1: Summary of Evo Client versus 1st Generation performance Evo Client 1st Generation user experience performance performance (in seconds) (in seconds) EPG load time 0.09 4.46 Navigating between visible EPG cells 0.055 0.22 Scrolling to a non-visible EPG cell 0.165 1.94 Scrolling 100 channels in EPG guide 12 181 So what does this tell us? By walking through two common user scenarios, EPG load time and EPG navigation response, this paper highlights the principle differences between two client-side IPTV middleware architecture models. It is these differences which help the Evo Client data- driven model provide a significantly faster user experience than the browser-based model. The Evo Client data-driven model separates UI from data-management which can drastically improve user response times. Additionally, Evo Client’s advanced UI rendering engine, through its simplified markup language, compiled skins and UI widgets, can turbo-charge a UI/SkinTone and provide users with a rich, animated and responsive experience. 10 November 2006
  11. 11. Winning and Retaining IPTV Subscribers: Why Performance Matters First and second generation IPTV deployments may have been able to satisfy the user experience by leveraging a browser-based middleware with HTML/JavaScript-based applications. However, this is because subscribers were limited, data demands were relatively low, applications were basic, and UIs were simple. As the next generation of IPTV services deploy to large subscriber markets, requirements for new services and more engaging user experiences will drive up data volume and graphical richness of the UI. © 2006 Espial Group Inc. Espial is a registered trademark, and the Espial logo, and all Espial product names are trademarks of Espial Group Inc. All other trademarks belong to their respective owners. All rights reserved. Evo Client is the only standards-based, open middleware architecture that can meet those requirements while maintaining a rich and responsive user experience in a cost- controlled environment * All time details have been obtained using the AminoNet 110 with a data set that includes 100 channels and 7 days worth of data. November 2006 11