IPTV Middleware interface: the two approaches

The interactive TV technology is well known to the vast majority of professionals in the field of communications and entertainment. This article is intended to cover the most vital question concerning the principles of STB's interaction with the Middleware server: what are the basic paradygms of the user interface representation on the TV screen, and how do they compare?

There are two fundamentally different approaches to implementation of Middleware system. The first one is based on web technologies. In this case, a web browser (provided by the manufacturer, possibly for a special price) runs on an STB and represents the server-generated web page of user interface, while interacting with the player via Javascript. Within the alternative approach, the interactive TV is controlled by the native standalone GUI application installed on the STB in place of the original firmware. Let us now discuss the pro and contra of each approach in more detail.

Web-based Middleware
First generation

Within this approach, the graphical interface is merely a set of web templates. The templates are stored on the server and sent over network to each of the client STBs with each request. On the client side, a browser renders the page. Each interface section, e.g. the list of channels, VoD content list, or the account information, requires its own web template.

At first glance, an interface like that is fairly easy to develop and modify. In practice, however, its use is hampered by a number of issues that tend to arise. To name just a few:

1. Cross-STB incompatibility inside one network. Various STBs may possess various browsers, which render web pages in their unique ways. Each browser also contains a unique Javascript engine. Thus the interface requires laborious tuning to match all browsers.
2. Sluggish interface rendering due to the lengthy command chain. First, a request is sent to the server, which in turn generates the corresponding web page. Then the page is downloaded and rendered by the browser. High network load may add delays on each transmission step. The browser itself is a very ineffective consumer of the STB's limited resources, thus slowing things down even more.
3. Extra load on the server part. The Middleware server has hard time returning a complete web page to each user on each request.

In short, the operator using this approach ends up with an inferior system which is also hard to update. As technology progresses, new better STBs come to market at competitive prices. But the first-generation Middleware is likely to make their use less fruitful, if possible at all. The end user, on the other hand, is stuck with slow interface of questionable functionality, probably enough to give up the whole idea of using IPTV.

Examples: Microsoft IPTV middleware (Microsoft Mediaroom), Minerva, Netris, Orca, Nordija, SeaChange, Dreampark, Northport and others

Low-level native Middleware
Second generation

NetUP was among the first companies to employ the second-generation approach, i.e. to use native applications, of "rich clients". Typically, the low-level integration with the STB requires close ties with its manufacturer, since only native SDK allows the complete utilisation of the STB's resources.

Within the "rich client" approach, the GUI tasks are completely handed over to the client part. A Linux operating system running on the STB hosts the special application which operates the interface. In this way, all GUI, modules, and plugins run on the STB without bothering the server at each redrawing of the screen.

Besides decreasing the server workload, this approach provides a number of advantages, including:

1. Potential for different STBs in one network. One application is compiled for each STB using its own native API. The client-server protocol, however, is the same for all versions. When a new kind of STB emerges on the market, it may join the network as soon as its firmware is assembled.
2. Quick interface. Since the graphics and scripts are not loaded with each page, there are also no delays with page turning on access to different services.
3. Ability to work offline. Even when the Middleware server is down, the client STB may continue to receive the media content during the whole paid time span.
4. Unlimited graphics and functionality. Since the application is not confined to the browser model of graphics rendering and standard interface components, it can perform just about anything on the screen.
5. Automatic updates. Whenever the IPTV complex is updated to include some new services, an automatic update software distributes the new version among all STBs.

As a result, the operator of second-generation Middleware systems comes up with the solution with virtually unlimited capabilities. New STB models and new services may be hot-plugged in to the complex. The end user will also appreciate the high-speed interface and sheer simplicity of addition of the new services.

Examples: NetUP, Cubiware (ex Sentivision).