STB Middleware provides a common framework for operator branded UI and feature implementation for a given operator network. This article delves into middleware basics and recommends basic minimum feature and functional requirement for a cost effective middleware solution.
An economical middleware needs to be thin and should be deployable on low cost zapper STBs with minimal CPU and memory requirement. While being light-weight in terms of resource consumption, middleware still needs to meet functional, architectural and regulatory specification as mandated by TRAI and MIB. So, the solution can be low in cost but not in quality or compliance. The article gives an insight into this cost-quality trade-off. It’s not a question of “Why” but “How” middleware is to be integrated on CATV network that needs deeper technical understanding of Digital CATV network and new business model analysis. This paper brainstorms on some of these fundamental knowledge points for the understanding of the big picture in small steps.
System Integration with Middleware- An Operator prerogative
First things first. A sneak peek into the anatomy of a Digital CATV System. As depicted in the figure, Digital Headend, Content, CAS, STB, Middleware, Apps and SMS constitute the functional blocks of the system. The jigsaw puzzle is solved by integrating these components in particular order through well defined interfaces. Apart fr0m the technicalities of choosing the right component for the type of network, size of deployment, number of channels and type of STBs, one must consider features and services that need to be rolled out in a phased manner. This explains how middleware becomes the heart of the system functioning as the instrument for the operator to control the feature and services roll-out based on evolving business model. The basic planning process usually begins with selection of Content, Headend, CAS, SMS and STB hardware and it is followed up with advance planning to address some of the following questions:
How many subscribers need to be considered now and in future?
What content plan I need to roll out? Will it be tiered based on customer segment?
How many types of STBs do I need to deploy and what will be the ratio of STBs?
How do I create differentiation in my service offering by giving choice to subscribers?
How do I provide VFM (Value For Money) to my subscribers and partners?
Digital CATV System Integration
It is when we dig deep into these questions, it becomes evident that middleware becomes central to the advanced planning and System Integration process. It is the technical solution for network scaling, service differentiation, multiple STB integration and substantiating VFM. It is also the reason why most of the middleware companies also provide system integration services by default. On the DVB-C networks, many kinds of incremental services will be offered. Realization of those services will require enhancement of traditional CATV system including head end, network, and the STB software. One-way network will still exist together with the two-way network for a certain long period, so we must take the subscribers of one-way network into consideration all along the planning process. DVB-C system together with the Middleware system, NMS system (Network Management System) will form an integrated service delivery platform, which can provide core DVB service, enhanced DVB service and VAS (Value Added Service) over both the one-way and two-way DVB-C network.
In this context, it is important to define middleware and categorize middleware type so that the operator and other business and technology stake-holders can make the right decision at the right time for their business requirement. Considering the phased approach in CATV Digitization, this paper describes the specification of the basic middleware and the “MUST HAVE” design and implementation requirement.
Minimalistic Middleware Feature, Design and Compliance Specification
The basic middleware includes the core DVB software of a digital TV receiver. The stack manages the reception of digital broadcast services, presents information on available channels and programmes via an Electronic Programme Guide (EPG) etc. Broadly it enables the following features on the STB.
Service scan & Service database
Dynamic SI engine, SI/PSI parser
Logical Channel Numbering
Third Party Service Inclusion (e.g., Free to Air channels bundled in a Pay TV system)
SD and HD Graphics and Color Management
EPG
Program banner with event information, synopsis, parental rating
Booking programs fr0m program guide and banner
Reminder Setting
User/system settings and diagnostics display
Favorite / blocked channels
UI language selection
Audio Language Selection
CAS/SMS integration
SI/PSI integration
While this is the specification for the most economical middleware, it must be highlighted that these features are implemented as software modules over different types of STB having different chipsets, memory and tuner configuration. So, the middleware implementation should be hardware independent so that the operator can always have the flexibility to choose hardware meeting its network and feature specification. Usually 4MB Flash and 32MB RAM is sufficient for basic SD(Standard Definition) middleware implementation and 16MB Flash and 256MB RAM for basic HD(High Definition) middleware implementation on standard chipsets like ST, Broadcom, MSTAR, Ali etc. Apart fr0m the basic feature set, middleware architecture need to be modularized as following for robustness, scalability and for being compliant to standards and regulatory bodies.
DVB Metadata Management: The SI/PSI Parser is basically used to parse & extract all SI/PSI table information (PAT, PMT, NIT, SDT, EIT, TDT, TOT, BAT etc) and this would provide SI table information to other components in the middleware stack to fetch and use the same. It monitors all message & events, which would sent fr0m middleware components. Middleware Database manager will provide the mechanism for storing and fetching all the program and service information. It is designed for PSI/SI data management. PSI parser will update PAT, PMT, CAT, TSDT, NIT table information for all available services in the current MPEG2 TS and the SI parser will update SDT, EIT, TDT, TOT, BAT table information for all available services in the current MPEG2 TS to the global database and all the table information will be maintained by the database manager. It also stores the PSI/SI information fr0m the other TS, by parsing the NIT, EIT and SDT of other networks.
A/V Control and Channel Management: It is responsible for controlling decoder settings for A/V Start/Stop function, Audio Mute/Unmute function, Channel Selection fr0m TS, Demultiplexer control etc.
Hardware Abstraction Layer (HAL): Hardware abstraction layer (HAL) acts as a glue layer between the platform (chipset) specific driver layer and the middleware stack that runs on it. Its main function is to provide platform independent functionality to the middleware, so that the middleware doesn’t needs to be changed to run on different platforms.
OS Abstraction Layer (OSAL): OS abstraction layer (OSAL) acts as a glue layer between the operating system and the middleware/application software that runs on top it. It provides operating system independent functionality to the middleware/application software, so that middleware/ application doesn’t needs to be changed to run on different operating systems.
Standards Compliance (TRAI, BIS etc.): STB middleware should be DVB-SI compliant as per ETSI EN 300 468 V1.7.1. Fingerprinting and CA OSD messages should be supported. STB software should be interoperable and open standards and architecture based. STB Software upgrade should be as per TS 102 006.
Conclusion
It is no longer a debate that middleware is the glue factor to hold together digital CATV system components like head end, STB, CAS etc. It is also not a question of “WHY” and “WHEN” but “HOW” to deploy a standard cost effective middleware to build the base framework and then enable growth by moving on to enhanced and VAS services through advanced middleware deployment step by step as part of a measured and sustainable journey. Middleware solution like Tornado Lite fr0m Corpus Media Labs can ideally fit into this roadmap driven deployment strategy as it provides a plug and play modular approach to enable only required and necessary features on a STB for an operator network.
Source: http://cablequest.org/articles/cas-and-content-security/item/2764-choosing-the-right-middleware.htmlSource: http://cablequest.org/articles/cas-and-content-security/item/2764-choosing-the-right-middleware.html
System Integration with Middleware- An Operator prerogative
First things first. A sneak peek into the anatomy of a Digital CATV System. As depicted in the figure, Digital Headend, Content, CAS, STB, Middleware, Apps and SMS constitute the functional blocks of the system. The jigsaw puzzle is solved by integrating these components in particular order through well defined interfaces. Apart fr0m the technicalities of choosing the right component for the type of network, size of deployment, number of channels and type of STBs, one must consider features and services that need to be rolled out in a phased manner. This explains how middleware becomes the heart of the system functioning as the instrument for the operator to control the feature and services roll-out based on evolving business model. The basic planning process usually begins with selection of Content, Headend, CAS, SMS and STB hardware and it is followed up with advance planning to address some of the following questions:
How many subscribers need to be considered now and in future?
What content plan I need to roll out? Will it be tiered based on customer segment?
How many types of STBs do I need to deploy and what will be the ratio of STBs?
How do I create differentiation in my service offering by giving choice to subscribers?
How do I provide VFM (Value For Money) to my subscribers and partners?
Digital CATV System Integration
It is when we dig deep into these questions, it becomes evident that middleware becomes central to the advanced planning and System Integration process. It is the technical solution for network scaling, service differentiation, multiple STB integration and substantiating VFM. It is also the reason why most of the middleware companies also provide system integration services by default. On the DVB-C networks, many kinds of incremental services will be offered. Realization of those services will require enhancement of traditional CATV system including head end, network, and the STB software. One-way network will still exist together with the two-way network for a certain long period, so we must take the subscribers of one-way network into consideration all along the planning process. DVB-C system together with the Middleware system, NMS system (Network Management System) will form an integrated service delivery platform, which can provide core DVB service, enhanced DVB service and VAS (Value Added Service) over both the one-way and two-way DVB-C network.
In this context, it is important to define middleware and categorize middleware type so that the operator and other business and technology stake-holders can make the right decision at the right time for their business requirement. Considering the phased approach in CATV Digitization, this paper describes the specification of the basic middleware and the “MUST HAVE” design and implementation requirement.
Minimalistic Middleware Feature, Design and Compliance Specification
The basic middleware includes the core DVB software of a digital TV receiver. The stack manages the reception of digital broadcast services, presents information on available channels and programmes via an Electronic Programme Guide (EPG) etc. Broadly it enables the following features on the STB.
Service scan & Service database
Dynamic SI engine, SI/PSI parser
Logical Channel Numbering
Third Party Service Inclusion (e.g., Free to Air channels bundled in a Pay TV system)
SD and HD Graphics and Color Management
EPG
Program banner with event information, synopsis, parental rating
Booking programs fr0m program guide and banner
Reminder Setting
User/system settings and diagnostics display
Favorite / blocked channels
UI language selection
Audio Language Selection
CAS/SMS integration
SI/PSI integration
While this is the specification for the most economical middleware, it must be highlighted that these features are implemented as software modules over different types of STB having different chipsets, memory and tuner configuration. So, the middleware implementation should be hardware independent so that the operator can always have the flexibility to choose hardware meeting its network and feature specification. Usually 4MB Flash and 32MB RAM is sufficient for basic SD(Standard Definition) middleware implementation and 16MB Flash and 256MB RAM for basic HD(High Definition) middleware implementation on standard chipsets like ST, Broadcom, MSTAR, Ali etc. Apart fr0m the basic feature set, middleware architecture need to be modularized as following for robustness, scalability and for being compliant to standards and regulatory bodies.
DVB Metadata Management: The SI/PSI Parser is basically used to parse & extract all SI/PSI table information (PAT, PMT, NIT, SDT, EIT, TDT, TOT, BAT etc) and this would provide SI table information to other components in the middleware stack to fetch and use the same. It monitors all message & events, which would sent fr0m middleware components. Middleware Database manager will provide the mechanism for storing and fetching all the program and service information. It is designed for PSI/SI data management. PSI parser will update PAT, PMT, CAT, TSDT, NIT table information for all available services in the current MPEG2 TS and the SI parser will update SDT, EIT, TDT, TOT, BAT table information for all available services in the current MPEG2 TS to the global database and all the table information will be maintained by the database manager. It also stores the PSI/SI information fr0m the other TS, by parsing the NIT, EIT and SDT of other networks.
A/V Control and Channel Management: It is responsible for controlling decoder settings for A/V Start/Stop function, Audio Mute/Unmute function, Channel Selection fr0m TS, Demultiplexer control etc.
Hardware Abstraction Layer (HAL): Hardware abstraction layer (HAL) acts as a glue layer between the platform (chipset) specific driver layer and the middleware stack that runs on it. Its main function is to provide platform independent functionality to the middleware, so that the middleware doesn’t needs to be changed to run on different platforms.
OS Abstraction Layer (OSAL): OS abstraction layer (OSAL) acts as a glue layer between the operating system and the middleware/application software that runs on top it. It provides operating system independent functionality to the middleware/application software, so that middleware/ application doesn’t needs to be changed to run on different operating systems.
Standards Compliance (TRAI, BIS etc.): STB middleware should be DVB-SI compliant as per ETSI EN 300 468 V1.7.1. Fingerprinting and CA OSD messages should be supported. STB software should be interoperable and open standards and architecture based. STB Software upgrade should be as per TS 102 006.
Conclusion
It is no longer a debate that middleware is the glue factor to hold together digital CATV system components like head end, STB, CAS etc. It is also not a question of “WHY” and “WHEN” but “HOW” to deploy a standard cost effective middleware to build the base framework and then enable growth by moving on to enhanced and VAS services through advanced middleware deployment step by step as part of a measured and sustainable journey. Middleware solution like Tornado Lite fr0m Corpus Media Labs can ideally fit into this roadmap driven deployment strategy as it provides a plug and play modular approach to enable only required and necessary features on a STB for an operator network.
Source: http://cablequest.org/articles/cas-and-content-security/item/2764-choosing-the-right-middleware.htmlSource: http://cablequest.org/articles/cas-and-content-security/item/2764-choosing-the-right-middleware.html
No comments:
Post a Comment