Cisco Headend System Release 2.7 Release Notes
SR 4.2 at a Glance
4012157 Rev B
9
Support for Persistent QPSK Database Reduces DHCT Sign-On Time
The QPSK software maintains a database that contains various parameters for each
of the up to 16K DHCTs that can be signed on to a single QPSK modulator (QPSK) at
any one time. These parameters include such things as IP Address, MAC Address,
Signon State, Power Level, and various counters that are used to track each DHCT.
When a QPSK reboot occurs, the current software clears this database and requires
the DHCTs to sign on again. Although the reboot itself takes approximately 30
seconds, the process of signing on up to 16K DHCTs to a single QPSK can take an
appreciable period of time.
of the up to 16K DHCTs that can be signed on to a single QPSK modulator (QPSK) at
any one time. These parameters include such things as IP Address, MAC Address,
Signon State, Power Level, and various counters that are used to track each DHCT.
When a QPSK reboot occurs, the current software clears this database and requires
the DHCTs to sign on again. Although the reboot itself takes approximately 30
seconds, the process of signing on up to 16K DHCTs to a single QPSK can take an
appreciable period of time.
SR 4.2 provides support for a new persistent DHCT database module in the D9482
QPSK Modulator software subsystem. This enhancement saves relevant DHCT data
in RAM and restores it after a QPSK reboots, thereby decreasing the amount of time
necessary to recover from a QPSK reboot.
QPSK Modulator software subsystem. This enhancement saves relevant DHCT data
in RAM and restores it after a QPSK reboots, thereby decreasing the amount of time
necessary to recover from a QPSK reboot.
Therefore, instead of requiring the DHCTs to sign on again, certain relevant data for
each DHCT such as IP Address, MAC Address, Channel number, etc., are stored in
space that is persistent across “short” reboots. Thus, during short reboots, the QPSK
uses this data to refurbish the DHCT database. This data in the DHCT database
provides an efficient method to shorten the previously lengthy sign-on process.
each DHCT such as IP Address, MAC Address, Channel number, etc., are stored in
space that is persistent across “short” reboots. Thus, during short reboots, the QPSK
uses this data to refurbish the DHCT database. This data in the DHCT database
provides an efficient method to shorten the previously lengthy sign-on process.
The following DNCS GUI changes support this new feature:
A Database Persistence selection on the Set Up QPSK Modulator screen
A Reset and Clear DB selection on the QPSK/CMTS File menu
What Standard Features Are Carried Forward in SR 4.2?
Support for Two-Way CableCARD Binding/Autobinding
SR 4.0 first provided support for two-way Multi-Stream CableCARD module
autobinding. Binding between the host and the CableCARD module is needed to
provision a cable host. Binding involves matching both host and CableCARD
module MAC addresses at the DNCS to associate the CableCARD module with the
host. With two-way hosts, binding can be accomplished manually, or it can be done
automatically (autobinding). Autobinding allows the automatic exchange of host-
and CableCARD-specific information (for example, MAC addresses) with the DNCS
for binding. With autobinding, two-way hosts automatically authorize CableCARD
modules, and subscribers do not need to telephone for authorization.
autobinding. Binding between the host and the CableCARD module is needed to
provision a cable host. Binding involves matching both host and CableCARD
module MAC addresses at the DNCS to associate the CableCARD module with the
host. With two-way hosts, binding can be accomplished manually, or it can be done
automatically (autobinding). Autobinding allows the automatic exchange of host-
and CableCARD-specific information (for example, MAC addresses) with the DNCS
for binding. With autobinding, two-way hosts automatically authorize CableCARD
modules, and subscribers do not need to telephone for authorization.