Cisco Model 6109 6 MHz Off-Air Reference (NTSC) Guide De Montage
Chapter 5 Advanced Operations
354
4039132 Rev B
Adding and Deleting USRM Service Groups Using
Configuration Files
Configuration Files
Overview
As Cisco SDV sites transition from using the original SDV Server to a USRM, there is
a change in the management and control aspects of SDV Resources. Whereas the
original SDV Server was totally dependent on the DNCS for all bandwidth and
resource management, in the SDV 3.0 architecture, control of these parameters has
transitioned to the USRM. Shell sessions and bandwidth/resource borrowing are
out. The USRM now has control of all SDV QAM resources and their associated
bandwidth.
a change in the management and control aspects of SDV Resources. Whereas the
original SDV Server was totally dependent on the DNCS for all bandwidth and
resource management, in the SDV 3.0 architecture, control of these parameters has
transitioned to the USRM. Shell sessions and bandwidth/resource borrowing are
out. The USRM now has control of all SDV QAM resources and their associated
bandwidth.
Implementing SDV 3.0 in a DNCS 4.2 environment is possible and is being
successfully done in the field. However, it must be noted that the DNCS interfaces to
the USRM have not changed. Thus, the USRM has adapted the information from the
original SDV MIB and uses it for initial provisioning. Included in this are Offered
Programs, Service Group name, Mini-Carousel IP address, and Min/Max mode. A
major component that is missing is QAM information. In the original SDV, the server
did not learn about its resources until after it requested service group bandwidth.
Consequently, there is no mechanism present for the DNCS to provision the USRM
with this information on startup. Hence, this information must be entered by the
operator.
successfully done in the field. However, it must be noted that the DNCS interfaces to
the USRM have not changed. Thus, the USRM has adapted the information from the
original SDV MIB and uses it for initial provisioning. Included in this are Offered
Programs, Service Group name, Mini-Carousel IP address, and Min/Max mode. A
major component that is missing is QAM information. In the original SDV, the server
did not learn about its resources until after it requested service group bandwidth.
Consequently, there is no mechanism present for the DNCS to provision the USRM
with this information on startup. Hence, this information must be entered by the
operator.
During the initial SDV Server-to-USRM upgrade, a script was written which read the
DNCS database and gathered all QAM/Service Group information for each server.
This information was captured as a configuration file and written into the USRM
database. Going forward, the Cisco USRM team recommends using configuration
files to manage QAMs. This approach will work for GQAMs, RFGW QAMs, or
third-party QAMs (TPQs). With the future release of USRM 2.0, Cisco will introduce
an admin console which will be a single machine where administration of all USRMs
can take place.
DNCS database and gathered all QAM/Service Group information for each server.
This information was captured as a configuration file and written into the USRM
database. Going forward, the Cisco USRM team recommends using configuration
files to manage QAMs. This approach will work for GQAMs, RFGW QAMs, or
third-party QAMs (TPQs). With the future release of USRM 2.0, Cisco will introduce
an admin console which will be a single machine where administration of all USRMs
can take place.
We also envision at this time that the USRM will only require and use Offered
Program Table information from the DNCS. For USRM 1.x releases, we will continue
to offer support in a "hybrid" manner: some control by the DNCS, some control by
the USRM. This interim approach is necessary to get the required USRM
functionality to the field in a timely manner.
Program Table information from the DNCS. For USRM 1.x releases, we will continue
to offer support in a "hybrid" manner: some control by the DNCS, some control by
the USRM. This interim approach is necessary to get the required USRM
functionality to the field in a timely manner.