Access Intelligence's BROADBAND GROUP
Communications Technology
Current Issue
Subscribe
Advertising Information
Meet the Editors
Advisory Board
Annual Awards
Custom Publishing
WebEvents
Show Dailies
Reprints
List Rentals
Archives
Search Career Center Contact Us Calendar Industry Partners Home

Archives

Communications Technology

Standards: Digital Video Standards Development
By

SCTE Digital Video Subcommittee (DVS) recently developed a step-by-step definition of its point-of-deployment (POD) module in DVS 266 revision 2 and DVS 267 revision 1, which together characterize the POD features and download.

DVS 266 revision 2, titled Point-of-Deployment (POD) Module Generic Feature Contribution: One function of the POD module is to provide communication and control between the headend and the host. One aspect of this involves the common features that may reside in many different host devices. These are called generic features. There are several parameters associated with these generic features; as a result, the cable operator may want to mandate certain features or potentially give the user total control. Upon this allowance, the user of the host may modify parameters within a generic feature that will influence the operation of the host and/or the POD module. This document defines the interface that is used to exchange the settings of the parameters for these generic features. Inclusion of a generic feature in this standards document in no way implies a requirement for either the host or the cable headend to support this feature.

The standard creates a new resource for the host, and is known as the Generic Feature Control. It enables the host and the POD module to exchange parameters belonging to a set of generic features. One use of this resource is to provide a mechanism in which generic feature parameters may be controlled by the headend to disable user control of these parameters.

DVS 267 revision 1, titled Point-of-Deployment (POD) Module Emergency Recovery and Firmware Upgrade Resource: This standard introduced that there is a small chance that the POD module’s firmware may become corrupted. There is currently no method in the POD interface to inform the host that the POD module has had such a catastrophic failure and is not able perform its operation, but it is capable of recovering from this state. This proposal is to provide a resource allowing the host to recognize this state, perform the necessary operations and allow the POD module to recover and operate correctly.

A POD module may be designed with the capability of having its firmware reprogrammed. Typically, this is implemented with flash memory or battery-backed-up RAM. On the rare occasion firmware is being reprogrammed, it is possible that an outside occurrence, such as a power failure, may cause the firmware to become corrupted. If this occurs, then the POD module is incapable of performing all of its functions. The design of devices with downloadable firmware generally provides some method of executing a minimum set of firmware to allow for recovery in the field. In flash memories, a special sector of code (often called Sector 0) is designed so that it cannot be reprogrammed. In systems with battery backup, this function can be implemented using ROM, which is also incapable of being reprogrammed. Generally, this memory is fairly small, and since it is not reprogrammable, it must be carefully designed and verified.

This special memory will contain a special program (in DVS 267 it is referred to as a boot-loader) that is called upon reset. It first performs basic initialization operations, and then tests the main program memory to ensure that it is valid. If it is valid, it starts executing out of the main firmware memory. If the main program memory is not valid, then a mechanism needs to be implemented allowing for the recovery of the main firmware. For this rare, emergency condition, the boot-loader will contain firmware that will allow the POD module to not only inform the host of the situation, but also will allow for recovery. If the user activates the host, then the host will inform the user that the POD module is not available.

Ted Woo is the SCTE’s director of standards. He may reached at .


 Back to December Issue


Access Intelligence's CABLE GROUP

Communications Technology | CableFAX Daily | CableFAX's CableWORLD | CT's Pipeline
CableFAX Magazine | CableFAX databriefs | Broadband Leaders Retreat | CableFAX Leaders Retreat

Access Intelligence, LLC Copyright © 2005 Access Intelligence, LLC. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Access Intelligence, LLC is prohibited.